[Intel-gfx] [PATCH] drm: Provide a driver hook for drm_dev_release()
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing down its state and then releasing a
reference to the drm device) and yet touch driver private state when
destroyed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_drv.c | 3 +++
include/drm/drm_drv.h | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f74b7d06ec01..f945bbcc8eb3 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -595,6 +595,9 @@ static void drm_dev_release(struct kref *ref)
{
struct drm_device *dev = container_of(ref, struct drm_device, ref);
+ if (dev->driver->release)
+ dev->driver->release(dev);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_destroy(dev);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index c4fc49583dc0..554104ccb939 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -71,6 +71,14 @@ struct drm_driver {
void (*postclose) (struct drm_device *, struct drm_file *);
void (*lastclose) (struct drm_device *);
int (*unload) (struct drm_device *);
+ /**
+* @release:
+*
+* Optional callback for destroying device state after the final
+* reference is released, i.e. the device is being destroyed.
+*/
+ void (*release) (struct drm_device *);
+
int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file
*file_priv);
int (*dma_quiescent) (struct drm_device *);
int (*context_dtor) (struct drm_device *dev, int context);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: Kill intel_panel_fitter_pipe()
On Wed, Dec 07, 2016 at 07:28:08PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Check pipe config gmch_pfit.control instead of using intel_panel_fitter_pipe() > to figure out if the pipe for the overlay is using the panel fitter. > > Signed-off-by: Ville Syrjälä 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 05/11] drm/i915: Use pipe_src_w in overlay code
On Wed, Dec 07, 2016 at 07:28:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace the use of crtc->mode.h/vdisplay with the more appropriate > config->pipe_src_w/h. I'll ask the dumb question: wouldn't pipe_src be the fb dimensions? It doesn't seem obvious to be they are the CRTC dimensions. Yes, they make sense from the pov this is the source rectangle that the CRTC is pulling pixels from. Hmm, hopefully I've answered my own question. 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 07/11] drm/i915: Simplify SWIDTHSW calculation
On Wed, Dec 07, 2016 at 07:28:09PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The formula in Bspec for computing the overlay SWIDTHSW is overly > obfuscated. Simplify the formula to something that's easily parsed by > humans. > > Signed-off-by: Ville Syrjälä Ok, I've stared at it long enough to agree that they are indeed the same. 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 08/11] drm/i915: Reorganize overlay filter coeffs into a nicer form
On Wed, Dec 07, 2016 at 07:28:10PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Use two-dimensional arrays and named initializers to make the > overlay filter coefficient tables easier to parse for humans. > > Signed-off-by: Ville Syrjälä Spot checking didn't reveal any typos. I presume that since they are u16 array of arrays, gcc is not adding any padding between rows? 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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Provide a driver hook for drm_dev_release()
== Series Details == Series: drm: Provide a driver hook for drm_dev_release() URL : https://patchwork.freedesktop.org/series/16538/ State : success == Summary == Series 16538v1 drm: Provide a driver hook for drm_dev_release() https://patchwork.freedesktop.org/api/1.0/series/16538/revisions/1/mbox/ fi-bdw-5557u total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-bsw-n3050 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 fi-bxt-t5700 total:247 pass:206 dwarn:0 dfail:0 fail:0 skip:41 fi-byt-j1900 total:247 pass:206 dwarn:0 dfail:0 fail:0 skip:41 fi-byt-n2820 total:247 pass:202 dwarn:0 dfail:0 fail:0 skip:45 fi-hsw-4770 total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-hsw-4770r total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-ilk-650 total:247 pass:181 dwarn:0 dfail:0 fail:0 skip:66 fi-ivb-3520m total:247 pass:213 dwarn:0 dfail:0 fail:0 skip:34 fi-ivb-3770 total:247 pass:212 dwarn:0 dfail:0 fail:0 skip:35 fi-kbl-7500u total:247 pass:212 dwarn:0 dfail:0 fail:0 skip:35 fi-skl-6260u total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-skl-6700hqtotal:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-skl-6700k total:247 pass:210 dwarn:3 dfail:0 fail:0 skip:34 fi-skl-6770hqtotal:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-snb-2520m total:247 pass:202 dwarn:0 dfail:0 fail:0 skip:45 fi-snb-2600 total:247 pass:201 dwarn:0 dfail:0 fail:0 skip:46 ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-45m-40s UTC integration manifest c859a1e drm: Provide a driver hook for drm_dev_release() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3230/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/i915: Use primary plane->state for overlay ckey setup
On Wed, Dec 07, 2016 at 07:28:11PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Extract the primary plane pixel format via plane state when setting up > the overlay colorkey. > > Signed-off-by: Ville Syrjälä Minor stylistic differences aside (I would rearrange the code a bit more to try and avoid having to initialise the locals, with the claim that it keeps the code deciding upon the value together), 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
[Intel-gfx] [GLK MIPI DSI V1 1/9] drm/i915/glk: Add new bit fields in MIPI CTRL register
From: Deepak M
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..6bd68bf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8658,6 +8658,21 @@ enum {
#define _MIPIA_CTRL(dev_priv->mipi_mmio_base + 0xb104)
#define _MIPIC_CTRL(dev_priv->mipi_mmio_base + 0xb904)
#define MIPI_CTRL(port)_MMIO_MIPI(port, _MIPIA_CTRL,
_MIPIC_CTRL)
+#define PHY_STATUS(1 << 31) /* RO */
+#define ULPS_NOT_ACTIVE (1 << 30) /* RO */
+#define MIPIIO_RESET (1 << 28)
+#define CLOCK_LANE_STOP_STATE (1 << 27) /* RO */
+#define DATA_LANE_STOP_STATE (1 << 26) /* RO */
+#define LP_WAKE (1 << 22)
+#define LP11_LOW_PWR_MODE (1 << 21)
+#define LP00_LOW_PWR_MODE (1 << 20)
+#define FIREWALL_ENABLE (1 << 16)
+#define BXT_PIXEL_OVERLAP_CNT_MASK(0xf << 10)
+#define BXT_PIXEL_OVERLAP_CNT_SHIFT 10
+#define DSC_ENABLE(1 << 3)
+#define RGB_FLIP (1 << 2)
+#define PWR_ACK (1 << 1) /* RO */
+#define MIPI_MODE (1 << 0)
#define ESCAPE_CLOCK_DIVIDER_SHIFT5 /* A only */
#define ESCAPE_CLOCK_DIVIDER_MASK (3 << 5)
#define ESCAPE_CLOCK_DIVIDER_1(0 << 5)
--
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 V1 0/9] GLK MIPI DSI VIDEO MODE PATCHES
The patches in this list enable MIPI DSI video mode support for GLK platform. Tesed locally. 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 | 157 - 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, 318 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 V1 6/9] drm/i915/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 V1 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 V1 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.
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 | 10 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6bd68bf..cc6bb18 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 DPHY_TLPX_TIME_CNT_SHIFT 0
+#define 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 MIPI_CLK_LANE_HS_PREP_SHIFT 0
+#define MIPI_CLK_LANE_HS_PREP_MASK(0xff << 0)
+#define MIPI_CLK_LANE_HS_ZERO_SHIFT 8
+#define MIPI_CLK_LANE_HS_ZERO_MASK(0xff00 << 0)
+#define MIPI_CLK_LANE_HS_TRAIL_SHIFT 16
+#define MIPI_CLK_LANE_HS_TRAIL_MASK (0xff << 0)
+#define MIPI_CLK_LANE_HS_EXIT_SHIFT 24
+#define 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..34bbdc2 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,15 @@ 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 <<
MIPI_CLK_LANE_HS_PREP_SHIFT) |
+ (mipi_config->ths_prepare_hszero <<
MIPI_CLK_LANE_HS_ZERO_SHIFT) |
+ (mipi_config->ths_trail <<
MIPI_CLK_LANE_HS_TRAIL_SHIFT) |
+ (mipi_config->ths_exit <<
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 V1 3/9] drm/i915/glk: Add MIPIIO Enable/disable sequence
From: Deepak M
Signed-off-by: Deepak M
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 130 +++
1 file changed, 130 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 34bbdc2..729fcc9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -357,6 +357,130 @@ 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 &= ~MIPIIO_RESET;
+ 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), PHY_STATUS, 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 &= ~MIPI_MODE;
+ 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 &= ~MIPIIO_RESET;
+ 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 &= ~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 | MIPI_MODE);
+ }
+
+ /* Wait for Pwr ACK */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port), PWR_ACK, PWR_ACK, 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), PHY_STATUS, PHY_STATUS, 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 | MIPIIO_RESET);
+
+ /* 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), ULPS_NOT_ACTIVE, 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 &= ~LP_WAKE;
+ I915_WRITE(MIPI_CTRL(port), tmp);
+ }
+
+ /* Wait for Stop state */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ if (intel_wait_for_register(dev_priv,
+ MIPI_CTRL(port), DATA_LANE_STOP_STATE,
+ DATA_LANE_STOP_STATE, 20))
+ DRM_ERROR("Date lane not in STOP state\n");
+ }
+
+ /* Wait for AFE LATCH */
+ for_each_dsi_port(
[Intel-gfx] [GLK MIPI DSI V1 7/9] drm/i915/glk: Program txesc clock divider for GLK
From: Deepak M
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 e83482b..3d7483e 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 TX_ESC_CLK_DIV1_MASK 0x3FF
+#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
+#define 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..94ba8157 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 & TX_ESC_CLK_DIV1_MASK);
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, txesc2_div & 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 &= ~TX_ESC_CLK_DIV1_MASK;
+ I915_WRITE(MIPIO_TXESC_CLK_DIV1, tmp);
+
+ tmp = I915_READ(MIPIO_TXESC_CLK_DIV2);
+ tmp &= ~TX_ESC_CLK_DIV2_MASK;
+ I915_WRITE(MIPIO_TXESC_CLK_DIV2, tmp)
[Intel-gfx] [GLK MIPI DSI V1 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 cc6bb18..e83482b 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 V1 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 V1 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 729fcc9..27a0e73 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -579,12 +579,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
Re: [Intel-gfx] [PATCH] drm: Allow CAP_PRIME on !MODESET
On Thu, Dec 08, 2016 at 12:05:48AM +0900, Michel Dänzer wrote:
> On 07/12/16 11:49 PM, Daniel Vetter wrote:
> > vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> > fare similarly.
> >
> > v2. Make it build. Oops.
> >
> > Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
> > non-KMS driver")
> > Cc: Michel Dänzer
> > Cc: Alex Deucher
> > Cc: Chris Wilson
> > Reviewed-by: Chris Wilson
> > Signed-off-by: Daniel Vetter
>
> Thanks Daniel, and sorry I missed this, guess I was thinking of !MODESET
> too much in terms of UMS and too little in terms of render-only drivers.
>
> Reviewed-by: Michel Dänzer
Thanks for the review, applied to drm-misc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info
On Thu, 08 Dec 2016, Jani Nikula wrote:
> On Thu, 08 Dec 2016, Jani Nikula wrote:
>> This lets us use IS_MOBILE() for distinguishing the desktop and mobile
>> parts instead of duplicating PCI IDs in Pineview specific checks.
>
> This probably needs more thorough review of the !IS_MOBILE() paths in
> parts not touched by this patch.
And Daniel says,
11:06 danvet j4ni, pnv is_mobile, even for the desktop version
11:06 danvet iirc
11:07 danvet because is_mobile has nothing to do with whether the
chip is for laptops or not
so better just forget about these two patches I guess.
BR,
Jani.
>
> For example this one in i915_gem_detect_bit_6_swizzle() which was pretty
> weird already before the Pineview device info patches:
>
> } else if (IS_MOBILE(dev_priv) ||
> (IS_GEN3(dev_priv) &&
> !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv))) {
>
> BR,
> Jani.
>
>
>>
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>> ---
>> arch/x86/kernel/early-quirks.c | 3 ++-
>> drivers/gpu/drm/i915/i915_drv.h | 2 --
>> drivers/gpu/drm/i915/i915_pci.c | 12 ++--
>> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
>> include/drm/i915_pciids.h | 6 --
>> 5 files changed, 18 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
>> index 6a08e25a48d8..34af418d88cc 100644
>> --- a/arch/x86/kernel/early-quirks.c
>> +++ b/arch/x86/kernel/early-quirks.c
>> @@ -508,7 +508,8 @@ static const struct pci_device_id intel_early_ids[]
>> __initconst = {
>> INTEL_I945G_IDS(&gen3_early_ops),
>> INTEL_I945GM_IDS(&gen3_early_ops),
>> INTEL_VLV_IDS(&gen6_early_ops),
>> -INTEL_PINEVIEW_IDS(&gen3_early_ops),
>> +INTEL_PINEVIEW_D_IDS(&gen3_early_ops),
>> +INTEL_PINEVIEW_M_IDS(&gen3_early_ops),
>> INTEL_I965G_IDS(&gen3_early_ops),
>> INTEL_G33_IDS(&gen3_early_ops),
>> INTEL_I965GM_IDS(&gen3_early_ops),
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 1480e733312a..ee1726b28b82 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2616,8 +2616,6 @@ intel_info(const struct drm_i915_private *dev_priv)
>> #define IS_G45(dev_priv)((dev_priv)->info.platform == INTEL_G45)
>> #define IS_GM45(dev_priv) ((dev_priv)->info.platform == INTEL_GM45)
>> #define IS_G4X(dev_priv)(IS_G45(dev_priv) || IS_GM45(dev_priv))
>> -#define IS_PINEVIEW_G(dev_priv) (INTEL_DEVID(dev_priv) == 0xa001)
>> -#define IS_PINEVIEW_M(dev_priv) (INTEL_DEVID(dev_priv) == 0xa011)
>> #define IS_PINEVIEW(dev_priv) ((dev_priv)->info.platform ==
>> INTEL_PINEVIEW)
>> #define IS_G33(dev_priv)((dev_priv)->info.platform == INTEL_G33)
>> #define IS_IRONLAKE_M(dev_priv) (INTEL_DEVID(dev_priv) == 0x0046)
>> diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> b/drivers/gpu/drm/i915/i915_pci.c
>> index 93f50ef2a309..451113f79499 100644
>> --- a/drivers/gpu/drm/i915/i915_pci.c
>> +++ b/drivers/gpu/drm/i915/i915_pci.c
>> @@ -139,7 +139,14 @@ static const struct intel_device_info intel_g33_info = {
>> .has_overlay = 1,
>> };
>>
>> -static const struct intel_device_info intel_pineview_info = {
>> +static const struct intel_device_info intel_pineview_d_info = {
>> +GEN3_FEATURES,
>> +.platform = INTEL_PINEVIEW,
>> +.has_hotplug = 1,
>> +.has_overlay = 1,
>> +};
>> +
>> +static const struct intel_device_info intel_pineview_m_info = {
>> GEN3_FEATURES,
>> .platform = INTEL_PINEVIEW, .is_mobile = 1,
>> .has_hotplug = 1,
>> @@ -444,7 +451,8 @@ static const struct pci_device_id pciidlist[] = {
>> INTEL_I965GM_IDS(&intel_i965gm_info),
>> INTEL_GM45_IDS(&intel_gm45_info),
>> INTEL_G45_IDS(&intel_g45_info),
>> -INTEL_PINEVIEW_IDS(&intel_pineview_info),
>> +INTEL_PINEVIEW_D_IDS(&intel_pineview_d_info),
>> +INTEL_PINEVIEW_M_IDS(&intel_pineview_m_info),
>> INTEL_IRONLAKE_D_IDS(&intel_ironlake_d_info),
>> INTEL_IRONLAKE_M_IDS(&intel_ironlake_m_info),
>> INTEL_SNB_D_IDS(&intel_sandybridge_d_info),
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 9171431558a3..afe07947e51c 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -659,7 +659,7 @@ static void pineview_update_wm(struct intel_crtc
>> *unused_crtc)
>> u32 reg;
>> unsigned long wm;
>>
>> -latency = intel_get_cxsr_latency(IS_PINEVIEW_G(dev_priv),
>> +latency = intel_get_cxsr_latency(!IS_MOBILE(dev_priv),
>> dev_priv->is_ddr3,
>> dev_priv->fsb_freq,
>> dev_priv->mem_freq);
>> @@ -7730,7 +7730,7 @@ void intel_init_pm(struct drm_i915_private *dev_priv)
>> vlv_setup_wm_latency(dev_priv);
>> dev_priv->displa
Re: [Intel-gfx] Does display engine read contents from LLC of scanout buffer?
I'm interesting in how mesa set related cache ability. Take kmscube(https://github.com/robclark/kmscube.git) as an example, mesa and drm do similar things: gbm_surface_create to create gbm_surface eglCreateWindowSurface to create EGLSurface eglMakeCurrent to bind context to EGLSurface do rendering using glsl eglSwapBuffers drmModePageFlip to do page flip Because mesa use Render Cache Data Port to render to framebuffer, so the cache path is: Render Cache -> LLC -> Memory. How can we control cache ability of render cache (MOCS can control L3 & LLC, but not render cache)? Or just flush render cache before display by kernel or mesa? Thanks, Chuanbo Weng -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Wednesday, December 7, 2016 10:10 PM To: Weng, Chuanbo Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Does display engine read contents from LLC of scanout buffer? On Wed, Dec 07, 2016 at 11:30:37AM +, Weng, Chuanbo wrote: > Hi Ville, > Thanks for your useful info. > How about L3 cache? In my scenario, Beignet will use Read Write Data > Port to write data (typed write) to bo. > So the cache path is L3 -> LLC -> memory. So only leave LLC cache ability the > same as PTEs is not enough. > In order to make data access efficient, I set L3 to WB. So is there a > way to flush L3 cache to memory? I don't recall. But actually caching in L3 is dangerous anyway since IIRC L3 evictions can land in LLC despite the LLC cacheability being set to UC/WT. Or at least there was a note stating that in bspec at some point. So to be totally correct you should not use L3 either. Well, I suppose you could use L3 as a RO cache, but sounds like you want to write as well. > > Thanks, > Chuanbo Weng > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, November 25, 2016 3:07 AM > To: Weng, Chuanbo > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] Does display engine read contents from LLC of > scanout buffer? > > On Thu, Nov 24, 2016 at 06:20:22PM +, Weng, Chuanbo wrote: > > Hi all, > >I have a question of display (forgive me if it's too simple > > because I'm not familiar with display): > > > >My scenario is as below: > > gbm_bo_create to create gbm_bo > > Get its handle > > drmModeAddFB to specify this bo as scanout > > buffer > > do rendering to this bo by OpenCL(Beignet) > > drmModePageFlip to do page flip > > > >Does display engine directly read contents from > > scanout buffer or read contents from LLC of this scanout buffer? > > The display engine sits between the LLC and main memory effectively, so the > answer is that it always reads directly from memory. When you make a bo a > scanout buffer the kernel will flush the caches and reconfigure the PTEs to > UC/WC so that subsequent rendering will hit memory directly. > And that also means you should never override potential scanout buffers to WB > via MOCS, and instead you should leave the choice up to the PTEs. > > -- > Ville Syrjälä > Intel OTC -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GLK MIPI DSI VIDEO MODE PATCHES
== Series Details == Series: GLK MIPI DSI VIDEO MODE PATCHES URL : https://patchwork.freedesktop.org/series/16542/ State : success == Summary == Series 16542v1 GLK MIPI DSI VIDEO MODE PATCHES https://patchwork.freedesktop.org/api/1.0/series/16542/revisions/1/mbox/ fi-bdw-5557u total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-bsw-n3050 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52 fi-bxt-t5700 total:247 pass:206 dwarn:0 dfail:0 fail:0 skip:41 fi-byt-j1900 total:247 pass:206 dwarn:0 dfail:0 fail:0 skip:41 fi-byt-n2820 total:247 pass:202 dwarn:0 dfail:0 fail:0 skip:45 fi-hsw-4770 total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-hsw-4770r total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-ilk-650 total:247 pass:181 dwarn:0 dfail:0 fail:0 skip:66 fi-ivb-3520m total:247 pass:213 dwarn:0 dfail:0 fail:0 skip:34 fi-ivb-3770 total:247 pass:212 dwarn:0 dfail:0 fail:0 skip:35 fi-kbl-7500u total:247 pass:212 dwarn:0 dfail:0 fail:0 skip:35 fi-skl-6260u total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-skl-6700hqtotal:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 fi-skl-6700k total:247 pass:210 dwarn:3 dfail:0 fail:0 skip:34 fi-skl-6770hqtotal:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-snb-2520m total:247 pass:202 dwarn:0 dfail:0 fail:0 skip:45 fi-snb-2600 total:247 pass:201 dwarn:0 dfail:0 fail:0 skip:46 ffcd96e45b3b3e4ca57d4879405d02b7b1b58946 drm-tip: 2016y-12m-07d-21h-45m-40s UTC integration manifest 1dc936f drm/915: Parsing the missed out DTD fields from the VBT d8e70e0 drm/i915/glk: Program dphy param reg for GLK aef354d drm/i915/glk: Program txesc clock divider for GLK e1142a4 drm/i915/glk: Program MIPI_CLOCK_CTRL only for BXT 6d35420 drm/i915/glk: Add DSI PLL divider range for glk f8c63e3 drm/i915: Set the Z inversion overlap field a5f966d drm/i915/glk: Add MIPIIO Enable/disable sequence e2032f6 drm/i915/glk: Program new MIPI DSI PHY registers for GLK 7672e79 drm/i915/glk: Add new bit fields in MIPI CTRL register == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3231/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Parse panel backlight controller from VBT
From: Vidya Srinivas
Currently the backlight controller is taken as 0. It needs to derive
value from the VBT. Adding the necessary changes.
v2 by Jani:
- drop obsolete comments, drop redundant initialization (Bob)
- merge debug logging into one
Signed-off-by: Uma Shankar
Signed-off-by: Vidya Srinivas
Reviewed-by: Bob Paauwe
Tested-by: Bob Paauwe
Tested-by: Mika Kahola
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_bios.c | 6 --
drivers/gpu/drm/i915/intel_panel.c | 17 +++--
3 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1480e733312a..786e3bb8eecf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1716,6 +1716,7 @@ struct intel_vbt_data {
bool present;
bool active_low_pwm;
u8 min_brightness; /* min_brightness/255 of max */
+ u8 controller; /* brightness controller number */
enum intel_backlight_type type;
} backlight;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index eaade27af386..1cf2fa6ec28f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -330,17 +330,19 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
method = &backlight_data->backlight_control[panel_type];
dev_priv->vbt.backlight.type = method->type;
+ dev_priv->vbt.backlight.controller = method->controller;
}
dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
DRM_DEBUG_KMS("VBT backlight PWM modulation frequency %u Hz, "
- "active %s, min brightness %u, level %u\n",
+ "active %s, min brightness %u, level %u, controller %u\n",
dev_priv->vbt.backlight.pwm_freq_hz,
dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
dev_priv->vbt.backlight.min_brightness,
- backlight_data->level[panel_type]);
+ backlight_data->level[panel_type],
+ dev_priv->vbt.backlight.controller);
}
/* Try to find sdvo panel data */
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 3578b402d412..b01edceac650 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1039,10 +1039,7 @@ static void bxt_enable_backlight(struct intel_connector
*connector)
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 pwm_ctl, val;
- /* To use 2nd set of backlight registers, utility pin has to be
-* enabled with PWM mode.
-* The field should only be changed when the utility pin is disabled
-*/
+ /* Controller 1 uses the utility pin. */
if (panel->backlight.controller == 1) {
val = I915_READ(UTIL_PIN_CTL);
if (val & UTIL_PIN_ENABLE) {
@@ -1608,19 +1605,11 @@ bxt_setup_backlight(struct intel_connector *connector,
enum pipe unused)
struct intel_panel *panel = &connector->panel;
u32 pwm_ctl, val;
- /*
-* For BXT hard coding the Backlight controller to 0.
-* TODO : Read the controller value from VBT and generalize
-*/
- panel->backlight.controller = 0;
+ panel->backlight.controller = dev_priv->vbt.backlight.controller;
pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
- /* Keeping the check if controller 1 is to be programmed.
-* This will come into affect once the VBT parsing
-* is fixed for controller selection, and controller 1 is used
-* for a prticular display configuration.
-*/
+ /* Controller 1 uses the utility pin. */
if (panel->backlight.controller == 1) {
val = I915_READ(UTIL_PIN_CTL);
panel->backlight.util_pin_active_low =
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/i915: Disable L2 cache clock gating on 830 when using the overlay
On Wed, Dec 07, 2016 at 07:28:12PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > BSpec says: > "Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating > must be disabled in order to prevent device hangs when turning off overlay.SW > must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)." > > We only turned off the overlay clock gating (due to lack of docs I > presume). After a bit of experimentation it looks like the the magic > C8h register lives in the PCI config space of device 0, and the magic > bit appears to be bit 2. Or at the very least this eliminates the GPU > death after MI_OVERLAY_OFF. > > L2 clock gating seems to save ~80mW, so let's keep it on unless we need > to actually use the overlay. > > Also let's move the OVRUNIT clock gating to the same place since we can, > and 845 supposedly doesn't need it. > > Signed-off-by: Ville Syrjälä Acked-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 04/11] drm/i915: Fix the overlay frontbuffer tracking
On Wed, Dec 07, 2016 at 07:28:06PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Do the overlay frontbuffer tracking properly so that it matches > the state of the overlay on/off/continue requests. > > One slight problem is that intel_frontbuffer_flip_complete() > may get delayed by an arbitrarily liong time due to the fact that > the overlay code likes to bail out when a signal occurs. So the > flip may not get completed until the ioctl is restarted. But fixing > that would require bigger surgery, so I decided to ignore it for now. Bigger surgery than conversion to spite planes? ;-) > Signed-off-by: Ville Syrjälä Nothing to complain about, traced the new ref and found it freed. 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
[Intel-gfx] [PATCH 0/3] Claw back the IS_ optimisation
From: Tvrtko Ursulin Reorganise the IS_ code a bit inspired by the pre-processor code generation as used by Chris in the self test patches. This avoids some source code duplication and makes maintenance easier. In the last patch try to claw back the multiple IS_ optimisation, as the commit message says: If we use only power of two values for the platform enum values we can let the compiler optimize some common checks to a single conditional. For example code like this: if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) Goes from this: 5c3c5: 8b 83 d8 06 00 00 mov0x6d8(%rbx),%eax 5c3cb: 83 f8 12cmp$0x12,%eax 5c3ce: 0f 84 f3 00 00 00 je 5c4c7 5c3d4: 83 f8 15cmp$0x15,%eax 5c3d7: 0f 84 ea 00 00 00 je 5c4c7 To this: 5c1d5: f7 83 d8 06 00 00 00testl $0x24,0x6d8(%rbx) 5c1dc: 00 24 00 5c1df: 0f 85 da 00 00 00 jne5c2bf It is not much but there is value in this that as long as we have to have conditions like the above sprinkled troughout the code, we can at least have the generate binary a bit smarter. Until we get to more than 32 platforms there is no downside to this approach. Patch series saves 1890 bytes of binary: textdata bss dec hex filename 1103970 26273 580 1130823 114147 i915.ko.0 1102080 26273 580 1128933 1139e5 i915.ko.1 Tvrtko Ursulin (3): drm/i915: Introduct i915_platforms.h drm/i915: Generate all IS_ macros drm/i915: Number the platform enum strategically drivers/gpu/drm/i915/i915_drv.h | 69 +--- drivers/gpu/drm/i915/i915_platforms.h| 34 drivers/gpu/drm/i915/intel_device_info.c | 38 -- 3 files changed, 61 insertions(+), 80 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_platforms.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Introduct i915_platforms.h
From: Tvrtko Ursulin
Inspired by the same approach used by Chris Wilson in the self
test patches.
We add a separate header file containing the list of our
platforms and then use the pre-processor to generate all
other places which use that list. This avoids having to
list them multiple times and avoids the maintenance
burden.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 30 +++-
drivers/gpu/drm/i915/i915_platforms.h| 34
drivers/gpu/drm/i915/intel_device_info.c | 30 +++-
3 files changed, 40 insertions(+), 54 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_platforms.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1480e733312a..ea06d3ff59da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -825,34 +825,10 @@ static inline unsigned int sseu_subslice_total(const
struct sseu_dev_info *sseu)
return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
}
-/* Keep in gen based order, and chronological order within a gen */
enum intel_platform {
- INTEL_PLATFORM_UNINITIALIZED = 0,
- INTEL_I830,
- INTEL_I845G,
- INTEL_I85X,
- INTEL_I865G,
- INTEL_I915G,
- INTEL_I915GM,
- INTEL_I945G,
- INTEL_I945GM,
- INTEL_G33,
- INTEL_PINEVIEW,
- INTEL_I965G,
- INTEL_I965GM,
- INTEL_G45,
- INTEL_GM45,
- INTEL_IRONLAKE,
- INTEL_SANDYBRIDGE,
- INTEL_IVYBRIDGE,
- INTEL_VALLEYVIEW,
- INTEL_HASWELL,
- INTEL_BROADWELL,
- INTEL_CHERRYVIEW,
- INTEL_SKYLAKE,
- INTEL_BROXTON,
- INTEL_KABYLAKE,
- INTEL_GEMINILAKE,
+#define i915_platform(name, value) INTEL_##name = value,
+#include "i915_platforms.h"
+#undef i915_platform
};
struct intel_device_info {
diff --git a/drivers/gpu/drm/i915/i915_platforms.h
b/drivers/gpu/drm/i915/i915_platforms.h
new file mode 100644
index ..b44ea1dd9c15
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_platforms.h
@@ -0,0 +1,34 @@
+/*
+ * List each platform as i915_platform(name, id).
+ *
+ * Names must be legal C identifiers and the ids must be unique integers.
+ *
+ * Keep in gen based order, and chronological order within a gen.
+ */
+
+i915_platform(UNINITIALIZED, 0)
+i915_platform(I830, 1)
+i915_platform(I845G, 2)
+i915_platform(I85X, 3)
+i915_platform(I865G, 4)
+i915_platform(I915G, 5)
+i915_platform(I915GM,6)
+i915_platform(I945G, 7)
+i915_platform(I945GM,8)
+i915_platform(G33, 9)
+i915_platform(PINEVIEW, 10)
+i915_platform(I965G,11)
+i915_platform(I965GM, 12)
+i915_platform(G45, 13)
+i915_platform(GM45, 14)
+i915_platform(IRONLAKE, 15)
+i915_platform(SANDYBRIDGE, 16)
+i915_platform(IVYBRIDGE, 17)
+i915_platform(VALLEYVIEW,18)
+i915_platform(HASWELL, 19)
+i915_platform(BROADWELL, 20)
+i915_platform(CHERRYVIEW,21)
+i915_platform(SKYLAKE, 22)
+i915_platform(BROXTON, 23)
+i915_platform(KABYLAKE, 24)
+i915_platform(GEMINILAKE,25)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index c46415b8c1b9..5192d388d10e 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -24,35 +24,11 @@
#include "i915_drv.h"
-#define PLATFORM_NAME(x) [INTEL_##x] = #x
static const char * const platform_names[] = {
- PLATFORM_NAME(I830),
- PLATFORM_NAME(I845G),
- PLATFORM_NAME(I85X),
- PLATFORM_NAME(I865G),
- PLATFORM_NAME(I915G),
- PLATFORM_NAME(I915GM),
- PLATFORM_NAME(I945G),
- PLATFORM_NAME(I945GM),
- PLATFORM_NAME(G33),
- PLATFORM_NAME(PINEVIEW),
- PLATFORM_NAME(I965G),
- PLATFORM_NAME(I965GM),
- PLATFORM_NAME(G45),
- PLATFORM_NAME(GM45),
- PLATFORM_NAME(IRONLAKE),
- PLATFORM_NAME(SANDYBRIDGE),
- PLATFORM_NAME(IVYBRIDGE),
- PLATFORM_NAME(VALLEYVIEW),
- PLATFORM_NAME(HASWELL),
- PLATFORM_NAME(BROADWELL),
- PLATFORM_NAME(CHERRYVIEW),
- PLATFORM_NAME(SKYLAKE),
- PLATFORM_NAME(BROXTON),
- PLATFORM_NAME(KABYLAKE),
- PLATFORM_NAME(GEMINILAKE),
+#define i915_platform(name, id) [id] = #name,
+#include "i915_platforms.h"
+#undef i915_platform
};
-#undef PLATFORM_NAME
const char *intel_platform_name(enum intel_platform platform)
{
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
From: Tvrtko Ursulin
Instead of listing them individually we can generate them
using the new i915_platforms.h header.
Also convert them to a static inline function which
interestingly makes the code smaller as well.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 39 ---
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea06d3ff59da..fb8f4b7cd1ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2579,36 +2579,29 @@ intel_info(const struct drm_i915_private *dev_priv)
#define IS_REVID(p, since, until) \
(INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
-#define IS_I830(dev_priv) ((dev_priv)->info.platform == INTEL_I830)
-#define IS_I845G(dev_priv) ((dev_priv)->info.platform == INTEL_I845G)
-#define IS_I85X(dev_priv) ((dev_priv)->info.platform == INTEL_I85X)
-#define IS_I865G(dev_priv) ((dev_priv)->info.platform == INTEL_I865G)
-#define IS_I915G(dev_priv) ((dev_priv)->info.platform == INTEL_I915G)
-#define IS_I915GM(dev_priv)((dev_priv)->info.platform == INTEL_I915GM)
-#define IS_I945G(dev_priv) ((dev_priv)->info.platform == INTEL_I945G)
-#define IS_I945GM(dev_priv)((dev_priv)->info.platform == INTEL_I945GM)
-#define IS_I965G(dev_priv) ((dev_priv)->info.platform == INTEL_I965G)
-#define IS_I965GM(dev_priv)((dev_priv)->info.platform == INTEL_I965GM)
-#define IS_G45(dev_priv) ((dev_priv)->info.platform == INTEL_G45)
-#define IS_GM45(dev_priv) ((dev_priv)->info.platform == INTEL_GM45)
+/*
+ * This block generates the IS_ helper functions in the format of:
+ *
+ * static inline bool IS_SKYLAKE(const struct drm_i915_private *dev_priv);
+ * ...
+ *
+ * One for each platform listed in i915_platforms.h is generated.
+ */
+#define i915_platform(name, id) \
+static inline bool IS_##name(const struct drm_i915_private *dev_priv) \
+{ \
+ return (dev_priv)->info.platform == INTEL_##name; \
+}
+#include "i915_platforms.h"
+#undef i915_platform
+
#define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv))
#define IS_PINEVIEW_G(dev_priv)(INTEL_DEVID(dev_priv) == 0xa001)
#define IS_PINEVIEW_M(dev_priv)(INTEL_DEVID(dev_priv) == 0xa011)
-#define IS_PINEVIEW(dev_priv) ((dev_priv)->info.platform == INTEL_PINEVIEW)
-#define IS_G33(dev_priv) ((dev_priv)->info.platform == INTEL_G33)
#define IS_IRONLAKE_M(dev_priv)(INTEL_DEVID(dev_priv) == 0x0046)
-#define IS_IVYBRIDGE(dev_priv) ((dev_priv)->info.platform == INTEL_IVYBRIDGE)
#define IS_IVB_GT1(dev_priv) (INTEL_DEVID(dev_priv) == 0x0156 || \
INTEL_DEVID(dev_priv) == 0x0152 || \
INTEL_DEVID(dev_priv) == 0x015a)
-#define IS_VALLEYVIEW(dev_priv)((dev_priv)->info.platform ==
INTEL_VALLEYVIEW)
-#define IS_CHERRYVIEW(dev_priv)((dev_priv)->info.platform ==
INTEL_CHERRYVIEW)
-#define IS_HASWELL(dev_priv) ((dev_priv)->info.platform == INTEL_HASWELL)
-#define IS_BROADWELL(dev_priv) ((dev_priv)->info.platform == INTEL_BROADWELL)
-#define IS_SKYLAKE(dev_priv) ((dev_priv)->info.platform == INTEL_SKYLAKE)
-#define IS_BROXTON(dev_priv) ((dev_priv)->info.platform == INTEL_BROXTON)
-#define IS_KABYLAKE(dev_priv) ((dev_priv)->info.platform == INTEL_KABYLAKE)
-#define IS_GEMINILAKE(dev_priv)((dev_priv)->info.platform ==
INTEL_GEMINILAKE)
#define IS_MOBILE(dev_priv)((dev_priv)->info.is_mobile)
#define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Number the platform enum strategically
From: Tvrtko Ursulin
If we use only power of two values for the platform enum
values we can let the compiler optimize some common
checks to a single conditional.
For example code like this:
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
Goes from this:
5c3c5: 8b 83 d8 06 00 00 mov0x6d8(%rbx),%eax
5c3cb: 83 f8 12cmp$0x12,%eax
5c3ce: 0f 84 f3 00 00 00 je 5c4c7
5c3d4: 83 f8 15cmp$0x15,%eax
5c3d7: 0f 84 ea 00 00 00 je 5c4c7
To this:
5c1d5: f7 83 d8 06 00 00 00testl $0x24,0x6d8(%rbx)
5c1dc: 00 24 00
5c1df: 0f 85 da 00 00 00 jne5c2bf
It is not much but there is value in this that as long as we
have to have conditions like the above sprinkled troughout the
code, we can at least have the generate binary a bit smarter.
Until we get to more than 32 platforms there is no downside
to this approach.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_platforms.h| 50
drivers/gpu/drm/i915/intel_device_info.c | 10 ---
3 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fb8f4b7cd1ae..347d5c6ffc1b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2590,7 +2590,7 @@ intel_info(const struct drm_i915_private *dev_priv)
#define i915_platform(name, id) \
static inline bool IS_##name(const struct drm_i915_private *dev_priv) \
{ \
- return (dev_priv)->info.platform == INTEL_##name; \
+ return !!((dev_priv)->info.platform & INTEL_##name); \
}
#include "i915_platforms.h"
#undef i915_platform
diff --git a/drivers/gpu/drm/i915/i915_platforms.h
b/drivers/gpu/drm/i915/i915_platforms.h
index b44ea1dd9c15..4118f152eac9 100644
--- a/drivers/gpu/drm/i915/i915_platforms.h
+++ b/drivers/gpu/drm/i915/i915_platforms.h
@@ -7,28 +7,28 @@
*/
i915_platform(UNINITIALIZED, 0)
-i915_platform(I830, 1)
-i915_platform(I845G, 2)
-i915_platform(I85X, 3)
-i915_platform(I865G, 4)
-i915_platform(I915G, 5)
-i915_platform(I915GM,6)
-i915_platform(I945G, 7)
-i915_platform(I945GM,8)
-i915_platform(G33, 9)
-i915_platform(PINEVIEW, 10)
-i915_platform(I965G,11)
-i915_platform(I965GM, 12)
-i915_platform(G45, 13)
-i915_platform(GM45, 14)
-i915_platform(IRONLAKE, 15)
-i915_platform(SANDYBRIDGE, 16)
-i915_platform(IVYBRIDGE, 17)
-i915_platform(VALLEYVIEW,18)
-i915_platform(HASWELL, 19)
-i915_platform(BROADWELL, 20)
-i915_platform(CHERRYVIEW,21)
-i915_platform(SKYLAKE, 22)
-i915_platform(BROXTON, 23)
-i915_platform(KABYLAKE, 24)
-i915_platform(GEMINILAKE,25)
+i915_platform(I830, BIT(1))
+i915_platform(I845G, BIT(2))
+i915_platform(I85X, BIT(3))
+i915_platform(I865G, BIT(4))
+i915_platform(I915G, BIT(5))
+i915_platform(I915GM,BIT(6))
+i915_platform(I945G, BIT(7))
+i915_platform(I945GM,BIT(8))
+i915_platform(G33, BIT(9))
+i915_platform(PINEVIEW, BIT(10))
+i915_platform(I965G,BIT(11))
+i915_platform(I965GM, BIT(12))
+i915_platform(G45, BIT(13))
+i915_platform(GM45, BIT(14))
+i915_platform(IRONLAKE, BIT(15))
+i915_platform(SANDYBRIDGE, BIT(16))
+i915_platform(IVYBRIDGE, BIT(17))
+i915_platform(VALLEYVIEW,BIT(18))
+i915_platform(HASWELL, BIT(19))
+i915_platform(BROADWELL, BIT(20))
+i915_platform(CHERRYVIEW,BIT(21))
+i915_platform(SKYLAKE, BIT(22))
+i915_platform(BROXTON, BIT(23))
+i915_platform(KABYLAKE, BIT(24))
+i915_platform(GEMINILAKE,BIT(25))
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 5192d388d10e..26df6363e265 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -25,18 +25,20 @@
#include "i915_drv.h"
static const char * const platform_names[] = {
-#define i915_platform(name, id) [id] = #name,
+#define i915_platform(name, id) [__builtin_ffs(id)] = #name,
#include "i915_platforms.h"
#undef i915_platform
};
const char *intel_platform_name(enum intel_platform platform)
{
- if (WARN_ON_ONCE(platform >= ARRAY_SIZE(platform_names) ||
-platform_names[platform] == NULL))
+ unsigned int idx = ffs(platform);
+
+ if (WARN_ON_ONCE(idx >= ARRAY_SIZE(platform_names) ||
+platform_names[idx] == NULL))
return "";
- return platform_names[platform];
+ return platform_names[idx];
}
void intel_device_info_dump(struct drm_i915_privat
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Number the platform enum strategically
On Thu, Dec 08, 2016 at 09:49:59AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> If we use only power of two values for the platform enum
> values we can let the compiler optimize some common
> checks to a single conditional.
>
> For example code like this:
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>
> Goes from this:
>
>5c3c5: 8b 83 d8 06 00 00 mov0x6d8(%rbx),%eax
>5c3cb: 83 f8 12cmp$0x12,%eax
>5c3ce: 0f 84 f3 00 00 00 je 5c4c7
>5c3d4: 83 f8 15cmp$0x15,%eax
>5c3d7: 0f 84 ea 00 00 00 je 5c4c7
>
> To this:
>
>5c1d5: f7 83 d8 06 00 00 00testl $0x24,0x6d8(%rbx)
>5c1dc: 00 24 00
>5c1df: 0f 85 da 00 00 00 jne5c2bf
>
> It is not much but there is value in this that as long as we
> have to have conditions like the above sprinkled troughout the
> code, we can at least have the generate binary a bit smarter.
>
> Until we get to more than 32 platforms there is no downside
> to this approach.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_platforms.h| 50
>
> drivers/gpu/drm/i915/intel_device_info.c | 10 ---
> 3 files changed, 32 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fb8f4b7cd1ae..347d5c6ffc1b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2590,7 +2590,7 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define i915_platform(name, id) \
> static inline bool IS_##name(const struct drm_i915_private *dev_priv) \
> { \
> - return (dev_priv)->info.platform == INTEL_##name; \
> + return !!((dev_priv)->info.platform & INTEL_##name); \
Redundant !!. It's an integer in a bool context, the !! are implied by
spec and gcc.
> }
> #include "i915_platforms.h"
> #undef i915_platform
> diff --git a/drivers/gpu/drm/i915/i915_platforms.h
> b/drivers/gpu/drm/i915/i915_platforms.h
> index b44ea1dd9c15..4118f152eac9 100644
> --- a/drivers/gpu/drm/i915/i915_platforms.h
> +++ b/drivers/gpu/drm/i915/i915_platforms.h
> @@ -7,28 +7,28 @@
> */
>
> i915_platform(UNINITIALIZED, 0)
> -i915_platform(I830,1)
> +i915_platform(I830,BIT(1))
Could start from BIT(0) or are we still anticipating support for i810?
And i740?
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 5192d388d10e..26df6363e265 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -25,18 +25,20 @@
> #include "i915_drv.h"
>
> static const char * const platform_names[] = {
> -#define i915_platform(name, id) [id] = #name,
> +#define i915_platform(name, id) [__builtin_ffs(id)] = #name,
> #include "i915_platforms.h"
> #undef i915_platform
> };
>
> const char *intel_platform_name(enum intel_platform platform)
> {
> - if (WARN_ON_ONCE(platform >= ARRAY_SIZE(platform_names) ||
> - platform_names[platform] == NULL))
> + unsigned int idx = ffs(platform);
Ah, ffs() is offset by one, and our id's are offset by another 1.
Using i915_platforms.h for a single list is a good improvement. And I
think we can get the best of both worlds: a concise identifier in the
logs and error state; and concise code. Looks good with a few fixes.
-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] ✓ Fi.CI.BAT: success for drm/i915: Shrink pipe config checker (rev2)
On 06/12/2016 11:15, Patchwork wrote: == Series Details == Series: drm/i915: Shrink pipe config checker (rev2) URL : https://patchwork.freedesktop.org/series/16359/ State : success == Summary == Series 16359v2 drm/i915: Shrink pipe config checker https://patchwork.freedesktop.org/api/1.0/series/16359/revisions/2/mbox/ Test drv_module_reload: Subgroup basic-reload-inject: dmesg-warn -> PASS (fi-skl-6770hq) fi-bdw-5557u total:247 pass:232 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:247 pass:207 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:247 pass:219 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:247 pass:194 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7500u total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:247 pass:214 dwarn:0 dfail:0 fail:0 skip:33 9448ba081ec5f0b9a94d4c4e6206240097ec035e drm-tip: 2016y-12m-06d-09h-23m-53s UTC integration manifest 52c3d7b drm/i915: Shrink pipe config checker (r-b carried over to v2 on IRC) Pushed, thanks for the review! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Another pile of misc stuff, final one for 4.10. If there's some serious bugfix still I'll send you a pull for drm-misc-next-fixes (like we do with intel), otherwise this is it and next pull next year for 4.11. Most interesting bits are probably Chris' fb helper fixes against mst hotplug oopses. Note to drm-misc committers: From now on until the merge window closes drm-misc-next is _not_ included in linux-next. Which means you can already start landing stuff for 4.11 even while the merge window is not yet finished, without upsetting anyone. Cheers, Daniel The following changes since commit 197aa6ed522cc44710687d3b02dd4e4573991416: Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2016-12-06 11:09:21 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2016-12-08 for you to fetch changes up to 72a93e8dd52c9feea42f1258d555e6070680a347: drm: Take ownership of the dmabuf->obj when exporting (2016-12-08 10:29:22 +0100) Chris Wilson (6): drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs drm: Pull together probe + setup for drm_fb_helper drm: Protect fb_helper list manipulation with a mutex drm: Initialise drm_mm.head_node.allocated drm: Don't block the kworker waiting for mode_config.mutex in output_poll() drm: Take ownership of the dmabuf->obj when exporting Daniel Vetter (6): drm/doc: Fix indenting in drm_modeset_lock.c comment drm: Fix locking cargo-cult in encoder/plane init/cleanup drm/vmwgfx: Switch to mode_cmd2 drm/qxl: Don't register debugfs for control minors Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next drm: Allow CAP_PRIME on !MODESET Gustavo Padovan (2): drm/atomic: doc: remove old comment about nonblocking commits drm/fence: add drm_crtc_create_fence() Laurent Pinchart (1): drm: Make the connector .detect() callback optional Lucas Stach (1): drm/bridge: tc358767: don't warn if display side ASSR enable fails Marta Lofstedt (1): drm: allow changing DPMS mode Michel Dänzer (1): drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver Nicolai Hähnle (1): drm/vgem: Use ww_mutex_(un)lock even with a NULL context Nicolai Stange (2): drm/radeon: don't add files at control minor debugfs directory drm/amdgpu: don't add files at control minor debugfs directory Pan Bian (1): drm/qxl: fix use of uninitialized variable zain wang (1): drm/bridge: analogix: Don't return -EINVAL when panel doesn't support PSR drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 -- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 7 -- drivers/gpu/drm/arc/arcpgu_sim.c | 7 -- drivers/gpu/drm/ast/ast_mode.c | 7 -- drivers/gpu/drm/bochs/bochs_kms.c | 7 -- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 +- drivers/gpu/drm/bridge/nxp-ptn3460.c | 7 -- drivers/gpu/drm/bridge/parade-ps8622.c | 7 -- drivers/gpu/drm/bridge/tc358767.c | 9 +- drivers/gpu/drm/cirrus/cirrus_mode.c | 7 -- drivers/gpu/drm/drm_atomic.c | 16 +-- drivers/gpu/drm/drm_atomic_helper.c| 7 +- drivers/gpu/drm/drm_crtc.c | 18 +++- drivers/gpu/drm/drm_crtc_internal.h| 2 +- drivers/gpu/drm/drm_encoder.c | 9 +- drivers/gpu/drm/drm_fb_helper.c| 109 ++- drivers/gpu/drm/drm_ioctl.c| 33 +++--- drivers/gpu/drm/drm_mm.c | 1 + drivers/gpu/drm/drm_modeset_lock.c | 10 +- drivers/gpu/drm/drm_plane.c| 4 +- drivers/gpu/drm/drm_prime.c| 12 ++- drivers/gpu/drm/drm_probe_helper.c | 20 +++- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 7 -- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 14 --- drivers/gpu/drm/gma500/psb_intel_lvds.c| 14 --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 7 -- drivers/gpu/drm/i915/intel_dsi.c | 7 -- drivers/gpu/drm/imx/imx-ldb.c | 7 -- drivers/gpu/drm/imx/imx-tve.c | 7 -- drivers/gpu/drm/imx/parallel-display.c | 7 -- drivers/gpu/drm/mediatek/mtk_dsi.c | 7 -- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 -- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 -- drivers/gpu/drm/qxl/qxl_release.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 6 -- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 7 -- drivers/gpu/drm/r
[Intel-gfx] ✓ Fi.CI.BAT: success for FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT (rev4)
== Series Details == Series: FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT (rev4) URL : https://patchwork.freedesktop.org/series/16489/ State : success == Summary == Series 16489v4 FOR_UPSTREAM [VPG]: drm/i915: Parse panel BL controller from VBT https://patchwork.freedesktop.org/api/1.0/series/16489/revisions/4/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> FAIL (fi-ctg-l9400) UNSTABLE Subgroup read-crc-pipe-a-frame-sequence: fail -> PASS (fi-ctg-l9400) UNSTABLE 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-ctg-l9400 total:210 pass:165 dwarn:0 dfail:0 fail:1 skip:43 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 e705da1e357d4db0db0b21bc6a2ea96df4453e05 drm-tip: 2016y-12m-08d-09h-02m-15s UTC integration manifest 1a6fcb9 drm/i915: Parse panel backlight controller from VBT == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3232/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Update drm_device docs about embedding.
It's supported now! Spotted while reviewing Chris' patch to add a release hook. Cc: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index f74b7d06ec01..4ec61ac27477 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) * historical baggage. Hence use the reference counting provided by * drm_dev_ref() and drm_dev_unref() only carefully. * - * Also note that embedding of &drm_device is currently not (yet) supported (but - * it would be easy to add). Drivers can store driver-private data in the - * dev_priv field of &drm_device. + * It is recommended that drivers embed struct &drm_device into their own device + * structure, which is supported through drm_dev_init(). */ /** @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) * Note that for purely virtual devices @parent can be NULL. * * Drivers that do not want to allocate their own device struct - * embedding struct &drm_device can call drm_dev_alloc() instead. + * embedding struct &drm_device can call drm_dev_alloc() instead. For drivers + * that do embed struct &drm_device it must be placed first in the overall + * structure, and the overall structure must be allocated using kmalloc(): The + * drm core's release function unconditionally calls kfree() on the @dev pointer + * when the final reference is released. * * RETURNS: * 0 on success, or error code on failure. -- 2.10.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Provide a driver hook for drm_dev_release()
On Thu, Dec 08, 2016 at 08:18:40AM +, Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> module reference and may live longer than expected (i.e. the current
> pattern of the driver tearing down its state and then releasing a
> reference to the drm device) and yet touch driver private state when
> destroyed.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> include/drm/drm_drv.h | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index f74b7d06ec01..f945bbcc8eb3 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -595,6 +595,9 @@ static void drm_dev_release(struct kref *ref)
> {
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
>
> + if (dev->driver->release)
> + dev->driver->release(dev);
> +
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index c4fc49583dc0..554104ccb939 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -71,6 +71,14 @@ struct drm_driver {
> void (*postclose) (struct drm_device *, struct drm_file *);
> void (*lastclose) (struct drm_device *);
> int (*unload) (struct drm_device *);
> + /**
> + * @release:
> + *
> + * Optional callback for destroying device state after the final
> + * reference is released, i.e. the device is being destroyed.
> + */
> + void (*release) (struct drm_device *);
I think sprinkling a reference to this hook into the documentation for
drm_dev_put would be real good. There's also a pile of text citing
drm_dev_unref(), especially in the overview section. I think that should
be udated to explain that release memory should only happen in ->release.
And I think with this change we can remove the cautious note that
drm_dev_ref/unref are busted, too.
And while reviewing this entire mess I've noticed that we probably want to
move the call for drm_vblank_cleanup() from _unregister to
drm_dev_release?
-Daniel
> +
> int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file
> *file_priv);
> int (*dma_quiescent) (struct drm_device *);
> int (*context_dtor) (struct drm_device *dev, int context);
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Introduct i915_platforms.h
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Inspired by the same approach used by Chris Wilson in the self
> test patches.
>
> We add a separate header file containing the list of our
> platforms and then use the pre-processor to generate all
> other places which use that list. This avoids having to
> list them multiple times and avoids the maintenance
> burden.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 30 +++-
> drivers/gpu/drm/i915/i915_platforms.h| 34
>
> drivers/gpu/drm/i915/intel_device_info.c | 30 +++-
> 3 files changed, 40 insertions(+), 54 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_platforms.h
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1480e733312a..ea06d3ff59da 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -825,34 +825,10 @@ static inline unsigned int sseu_subslice_total(const
> struct sseu_dev_info *sseu)
> return hweight8(sseu->slice_mask) * hweight8(sseu->subslice_mask);
> }
>
> -/* Keep in gen based order, and chronological order within a gen */
> enum intel_platform {
> - INTEL_PLATFORM_UNINITIALIZED = 0,
> - INTEL_I830,
> - INTEL_I845G,
> - INTEL_I85X,
> - INTEL_I865G,
> - INTEL_I915G,
> - INTEL_I915GM,
> - INTEL_I945G,
> - INTEL_I945GM,
> - INTEL_G33,
> - INTEL_PINEVIEW,
> - INTEL_I965G,
> - INTEL_I965GM,
> - INTEL_G45,
> - INTEL_GM45,
> - INTEL_IRONLAKE,
> - INTEL_SANDYBRIDGE,
> - INTEL_IVYBRIDGE,
> - INTEL_VALLEYVIEW,
> - INTEL_HASWELL,
> - INTEL_BROADWELL,
> - INTEL_CHERRYVIEW,
> - INTEL_SKYLAKE,
> - INTEL_BROXTON,
> - INTEL_KABYLAKE,
> - INTEL_GEMINILAKE,
> +#define i915_platform(name, value) INTEL_##name = value,
> +#include "i915_platforms.h"
> +#undef i915_platform
> };
>
> struct intel_device_info {
> diff --git a/drivers/gpu/drm/i915/i915_platforms.h
> b/drivers/gpu/drm/i915/i915_platforms.h
> new file mode 100644
> index ..b44ea1dd9c15
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_platforms.h
> @@ -0,0 +1,34 @@
> +/*
> + * List each platform as i915_platform(name, id).
> + *
> + * Names must be legal C identifiers and the ids must be unique integers.
> + *
> + * Keep in gen based order, and chronological order within a gen.
> + */
> +
> +i915_platform(UNINITIALIZED, 0)
> +i915_platform(I830,1)
> +i915_platform(I845G, 2)
> +i915_platform(I85X,3)
> +i915_platform(I865G, 4)
> +i915_platform(I915G, 5)
> +i915_platform(I915GM, 6)
> +i915_platform(I945G, 7)
> +i915_platform(I945GM, 8)
> +i915_platform(G33, 9)
> +i915_platform(PINEVIEW, 10)
> +i915_platform(I965G, 11)
> +i915_platform(I965GM, 12)
> +i915_platform(G45,13)
> +i915_platform(GM45, 14)
> +i915_platform(IRONLAKE, 15)
> +i915_platform(SANDYBRIDGE, 16)
> +i915_platform(IVYBRIDGE, 17)
> +i915_platform(VALLEYVIEW,18)
> +i915_platform(HASWELL,19)
> +i915_platform(BROADWELL, 20)
> +i915_platform(CHERRYVIEW,21)
> +i915_platform(SKYLAKE,22)
> +i915_platform(BROXTON,23)
> +i915_platform(KABYLAKE, 24)
> +i915_platform(GEMINILAKE,25)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index c46415b8c1b9..5192d388d10e 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -24,35 +24,11 @@
>
> #include "i915_drv.h"
>
> -#define PLATFORM_NAME(x) [INTEL_##x] = #x
> static const char * const platform_names[] = {
> - PLATFORM_NAME(I830),
> - PLATFORM_NAME(I845G),
> - PLATFORM_NAME(I85X),
> - PLATFORM_NAME(I865G),
> - PLATFORM_NAME(I915G),
> - PLATFORM_NAME(I915GM),
> - PLATFORM_NAME(I945G),
> - PLATFORM_NAME(I945GM),
> - PLATFORM_NAME(G33),
> - PLATFORM_NAME(PINEVIEW),
> - PLATFORM_NAME(I965G),
> - PLATFORM_NAME(I965GM),
> - PLATFORM_NAME(G45),
> - PLATFORM_NAME(GM45),
> - PLATFORM_NAME(IRONLAKE),
> - PLATFORM_NAME(SANDYBRIDGE),
> - PLATFORM_NAME(IVYBRIDGE),
> - PLATFORM_NAME(VALLEYVIEW),
> - PLATFORM_NAME(HASWELL),
> - PLATFORM_NAME(BROADWELL),
> - PLATFORM_NAME(CHERRYVIEW),
> - PLATFORM_NAME(SKYLAKE),
> - PLATFORM_NAME(BROXTON),
> - PLATFORM_NAME(KABYLAKE),
> - PLATFORM_NAME(GEMINILAKE),
> +#define i915_platform(name, id) [id] = #name,
> +#include "i915_platforms.h"
> +#undef i915_platform
> };
> -#undef PLATFORM_NAME
I was thinking we could improve the printed names here, for example:
[INTEL_I965G] = "I965G/Broadwater"
[INTEL_VALLEYVIEW] = "Valleyview/Baytrail
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of listing them individually we can generate them
> using the new i915_platforms.h header.
>
> Also convert them to a static inline function which
> interestingly makes the code smaller as well.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
NAK. Absolutely opposed to this.
A large part of my work involves digging through the source tree, and a
crucial part of that is looking up definitions and references, both for
macros and functions. Not having the macro/function definitions breaks
that workflow. Losing that, source code archeology gets *much*
harder. The losses are much greater than the gains.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 39 ---
> 1 file changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ea06d3ff59da..fb8f4b7cd1ae 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2579,36 +2579,29 @@ intel_info(const struct drm_i915_private *dev_priv)
> #define IS_REVID(p, since, until) \
> (INTEL_REVID(p) >= (since) && INTEL_REVID(p) <= (until))
>
> -#define IS_I830(dev_priv)((dev_priv)->info.platform == INTEL_I830)
> -#define IS_I845G(dev_priv) ((dev_priv)->info.platform == INTEL_I845G)
> -#define IS_I85X(dev_priv)((dev_priv)->info.platform == INTEL_I85X)
> -#define IS_I865G(dev_priv) ((dev_priv)->info.platform == INTEL_I865G)
> -#define IS_I915G(dev_priv) ((dev_priv)->info.platform == INTEL_I915G)
> -#define IS_I915GM(dev_priv) ((dev_priv)->info.platform == INTEL_I915GM)
> -#define IS_I945G(dev_priv) ((dev_priv)->info.platform == INTEL_I945G)
> -#define IS_I945GM(dev_priv) ((dev_priv)->info.platform == INTEL_I945GM)
> -#define IS_I965G(dev_priv) ((dev_priv)->info.platform == INTEL_I965G)
> -#define IS_I965GM(dev_priv) ((dev_priv)->info.platform == INTEL_I965GM)
> -#define IS_G45(dev_priv) ((dev_priv)->info.platform == INTEL_G45)
> -#define IS_GM45(dev_priv)((dev_priv)->info.platform == INTEL_GM45)
> +/*
> + * This block generates the IS_ helper functions in the format of:
> + *
> + * static inline bool IS_SKYLAKE(const struct drm_i915_private *dev_priv);
> + * ...
> + *
> + * One for each platform listed in i915_platforms.h is generated.
> + */
> +#define i915_platform(name, id) \
> +static inline bool IS_##name(const struct drm_i915_private *dev_priv) \
> +{ \
> + return (dev_priv)->info.platform == INTEL_##name; \
> +}
> +#include "i915_platforms.h"
> +#undef i915_platform
> +
> #define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv))
> #define IS_PINEVIEW_G(dev_priv) (INTEL_DEVID(dev_priv) == 0xa001)
> #define IS_PINEVIEW_M(dev_priv) (INTEL_DEVID(dev_priv) == 0xa011)
> -#define IS_PINEVIEW(dev_priv)((dev_priv)->info.platform ==
> INTEL_PINEVIEW)
> -#define IS_G33(dev_priv) ((dev_priv)->info.platform == INTEL_G33)
> #define IS_IRONLAKE_M(dev_priv) (INTEL_DEVID(dev_priv) == 0x0046)
> -#define IS_IVYBRIDGE(dev_priv) ((dev_priv)->info.platform ==
> INTEL_IVYBRIDGE)
> #define IS_IVB_GT1(dev_priv) (INTEL_DEVID(dev_priv) == 0x0156 || \
>INTEL_DEVID(dev_priv) == 0x0152 || \
>INTEL_DEVID(dev_priv) == 0x015a)
> -#define IS_VALLEYVIEW(dev_priv) ((dev_priv)->info.platform ==
> INTEL_VALLEYVIEW)
> -#define IS_CHERRYVIEW(dev_priv) ((dev_priv)->info.platform ==
> INTEL_CHERRYVIEW)
> -#define IS_HASWELL(dev_priv) ((dev_priv)->info.platform == INTEL_HASWELL)
> -#define IS_BROADWELL(dev_priv) ((dev_priv)->info.platform ==
> INTEL_BROADWELL)
> -#define IS_SKYLAKE(dev_priv) ((dev_priv)->info.platform == INTEL_SKYLAKE)
> -#define IS_BROXTON(dev_priv) ((dev_priv)->info.platform == INTEL_BROXTON)
> -#define IS_KABYLAKE(dev_priv)((dev_priv)->info.platform ==
> INTEL_KABYLAKE)
> -#define IS_GEMINILAKE(dev_priv) ((dev_priv)->info.platform ==
> INTEL_GEMINILAKE)
> #define IS_MOBILE(dev_priv) ((dev_priv)->info.is_mobile)
> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
--
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/16] drm/i915: Provide a hook for selftests
On 07/12/2016 13:58, Chris Wilson wrote: Some pieces of code are independent of hardware but are very tricky to exercise through the normal userspace ABI or via debugfs hooks. Being able to create mock unit tests and execute them through CI is vital. Start by adding a central point where we can execute unit tests and a parameter to enable them. This is disabled by default as the expectation is that these tests will occasionally explode. To facilitate integration with igt, any parameter beginning with i915.igt__ is interpreted as a subtest executable independently via igt/drv_selftest. Two classes of selftests are recognised: mock unit tests and integration tests. Mock unit tests are run as soon as the module is loaded, before the device is probed. At that point there is no driver instantiated and all hw interactions must be "mocked". This is very useful for writing universal tests to exercise code not typically run on a broad range of architectures. Alternatively, you can hook into the late selftests and run when the device has been instantiated - hw interactions are real. v2: Add a macro for compiling conditional code for mock objects inside real objects. v3: Differentiate between mock unit tests and late integration test. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin #v1 --- drivers/gpu/drm/i915/Kconfig.debug | 15 +++ drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_late_selftests.h | 11 ++ drivers/gpu/drm/i915/i915_mock_selftests.h | 11 ++ drivers/gpu/drm/i915/i915_params.c | 8 ++ drivers/gpu/drm/i915/i915_params.h | 4 + drivers/gpu/drm/i915/i915_pci.c| 19 +++- drivers/gpu/drm/i915/i915_selftest.c | 173 + drivers/gpu/drm/i915/i915_selftest.h | 77 + 9 files changed, 318 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/i915_late_selftests.h create mode 100644 drivers/gpu/drm/i915/i915_mock_selftests.h create mode 100644 drivers/gpu/drm/i915/i915_selftest.c create mode 100644 drivers/gpu/drm/i915/i915_selftest.h diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 597648c7a645..76af8774cf70 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -25,6 +25,7 @@ config DRM_I915_DEBUG select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks) select DRM_DEBUG_MM if DRM=y select DRM_I915_SW_FENCE_DEBUG_OBJECTS + select DRM_I915_SELFTEST default n help Choose this option to turn on extra driver debugging that may affect @@ -58,3 +59,17 @@ config DRM_I915_SW_FENCE_DEBUG_OBJECTS Recommended for driver developers only. If in doubt, say "N". + +config DRM_I915_SELFTEST + bool "Enable selftests upon driver load" + depends on DRM_I915 + default n + help + Choose this option to allow the driver to perform selftests upon + loading; also requires the i915.selftest=1 module parameter. To + exit the module after running the selftests (i.e. to prevent normal + module initialisation afterwards) use i915.selftest=-1. + + Recommended for driver developers only. + + If in doubt, say "N". diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 3c30916727fb..7c3b4f0c836c 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -114,6 +114,7 @@ i915-y += dvo_ch7017.o \ # Post-mortem debug and GPU hang state capture i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o +i915-$(CONFIG_DRM_I915_SELFTEST) += i915_selftest.o # virtual gpu code i915-y += i915_vgpu.o diff --git a/drivers/gpu/drm/i915/i915_late_selftests.h b/drivers/gpu/drm/i915/i915_late_selftests.h new file mode 100644 index ..e6645d08d964 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_late_selftests.h @@ -0,0 +1,11 @@ +/* List each unit test as selftest(name, function) + * + * The name is used as both an enum and expanded as subtest__name to create + * a module parameter. It must be unique and legal for a C identifier. + * + * The function should be of type int function(void). It may be conditionally + * compiled using #if IS_ENABLED(DRM_I915_SELFTEST). + * + * Tests are executed in reverse order by igt/drv_selftest + */ +selftest(sanitycheck, i915_late_sanitycheck) /* keep last */ diff --git a/drivers/gpu/drm/i915/i915_mock_selftests.h b/drivers/gpu/drm/i915/i915_mock_selftests.h new file mode 100644 index ..9bead7b496b0 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_mock_selftests.h @@ -0,0 +1,11 @@ +/* List each unit test as selftest(name, function) + * + * The name is used as both an enum and expanded as subtest__name to create + * a module parameter. It must be unique and legal for a C identifier. + * + * The function should be of type int function(void). It may be conditi
[Intel-gfx] [PATCH] drm/i915: Respect ring_mask and num_pipes when install IRQ
From: Elaine Wang
Some platforms only have VCS ring in VDBox. To avoid accessing the
non-existent rings or display registers, check the ring_mask
and num_pipes in gen8 IRQ install and reset functions.
Cc: Joonas Lahtinen
Signed-off-by: Elaine Wang
---
drivers/gpu/drm/i915/i915_irq.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0b119b9..3b3ed22 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 (INTEL_INFO(dev_priv)->num_pipes) {
+ GEN5_IRQ_RESET(GEN8_DE_PORT_);
+ GEN5_IRQ_RESET(GEN8_DE_MISC_);
+ }
GEN5_IRQ_RESET(GEN8_PCU_);
if (HAS_PCH_SPLIT(dev_priv))
@@ -3351,14 +3353,20 @@ static void gen8_gt_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv->pm_ier = 0x0;
dev_priv->pm_imr = ~dev_priv->pm_ier;
- GEN8_IRQ_INIT_NDX(GT, 0, ~gt_interrupts[0], gt_interrupts[0]);
- GEN8_IRQ_INIT_NDX(GT, 1, ~gt_interrupts[1], gt_interrupts[1]);
+
+ if (HAS_ENGINE(dev_priv, RCS) || HAS_ENGINE(dev_priv, BCS))
+ GEN8_IRQ_INIT_NDX(GT, 0, ~gt_interrupts[0], gt_interrupts[0]);
+
+ if (HAS_ENGINE(dev_priv, VCS))
+ GEN8_IRQ_INIT_NDX(GT, 1, ~gt_interrupts[1], gt_interrupts[1]);
/*
* RPS interrupts will get enabled/disabled on demand when RPS itself
* is enabled/disabled. Same wil be the case for GuC interrupts.
*/
GEN8_IRQ_INIT_NDX(GT, 2, dev_priv->pm_imr, dev_priv->pm_ier);
- GEN8_IRQ_INIT_NDX(GT, 3, ~gt_interrupts[3], gt_interrupts[3]);
+
+ if (HAS_ENGINE(dev_priv, VECS))
+ GEN8_IRQ_INIT_NDX(GT, 3, ~gt_interrupts[3], gt_interrupts[3]);
}
static void gen8_de_irq_postinstall(struct drm_i915_private *dev_priv)
@@ -3414,7 +3422,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 (INTEL_INFO(dev_priv)->num_pipes)
+ gen8_de_irq_postinstall(dev_priv);
if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_postinstall(dev);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Update drm_device docs about embedding.
On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > It's supported now! Spotted while reviewing Chris' patch to add a > release hook. > > Cc: Chris Wilson > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_drv.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > index f74b7d06ec01..4ec61ac27477 100644 > --- a/drivers/gpu/drm/drm_drv.c > +++ b/drivers/gpu/drm/drm_drv.c > @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) > * historical baggage. Hence use the reference counting provided by > * drm_dev_ref() and drm_dev_unref() only carefully. > * > - * Also note that embedding of &drm_device is currently not (yet) supported > (but > - * it would be easy to add). Drivers can store driver-private data in the > - * dev_priv field of &drm_device. > + * It is recommended that drivers embed struct &drm_device into their own > device > + * structure, which is supported through drm_dev_init(). > */ > > /** > @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) > * Note that for purely virtual devices @parent can be NULL. > * > * Drivers that do not want to allocate their own device struct > - * embedding struct &drm_device can call drm_dev_alloc() instead. > + * embedding struct &drm_device can call drm_dev_alloc() instead. For drivers > + * that do embed struct &drm_device it must be placed first in the overall > + * structure, and the overall structure must be allocated using kmalloc(): > The > + * drm core's release function unconditionally calls kfree() on the @dev > pointer > + * when the final reference is released. Hmm, the privates are getting pretty big (drm_i915_private fits inside malloc-32678). We should start considering using drm_free_large() instead as that more or less work transparently and allows fallback to vmalloc. As it stands the doc update is correct, so 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 03/16] drm/i915: Add unit tests for the breadcrumb rbtree, insert/remove
On 07/12/2016 13:58, Chris Wilson wrote:
First retroactive test, make sure that the waiters are in global seqno
order after random inserts and removals.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_mock_selftests.h | 1 +
drivers/gpu/drm/i915/intel_breadcrumbs.c | 205 +
drivers/gpu/drm/i915/intel_ringbuffer.h| 2 +
3 files changed, 208 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_mock_selftests.h
b/drivers/gpu/drm/i915/i915_mock_selftests.h
index 9bead7b496b0..1603fd35d190 100644
--- a/drivers/gpu/drm/i915/i915_mock_selftests.h
+++ b/drivers/gpu/drm/i915/i915_mock_selftests.h
@@ -8,4 +8,5 @@
*
* Tests are executed in reverse order by igt/drv_selftest
*/
+selftest(breadcrumbs, intel_breadcrumbs_selftest)
selftest(sanitycheck, i915_mock_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 53ae7884babd..c768608974e1 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -109,6 +109,18 @@ static void __intel_breadcrumbs_enable_irq(struct
intel_breadcrumbs *b)
if (b->rpm_wakelock)
return;
+ if (I915_SELFTEST_ONLY(b->mock)) {
+ /* For our mock objects we want to avoid interaction
+* with the real hardware (which is not set up). So
+* we simply pretend we have enabled the powerwell
+* and the irq, and leave it up to the mock
+* implementation to call intel_engine_wakeup()
+* itself when it wants to simulate a user interrupt,
Another broken key? :) (,)
+*/
+ b->rpm_wakelock = true;
+ return;
+ }
+
/* Since we are waiting on a request, the GPU should be busy
* and should have its own rpm reference. For completeness,
* record an rpm reference for ourselves to cover the
@@ -143,6 +155,11 @@ static void __intel_breadcrumbs_disable_irq(struct
intel_breadcrumbs *b)
if (!b->rpm_wakelock)
return;
+ if (I915_SELFTEST_ONLY(b->mock)) {
+ b->rpm_wakelock = false;
+ return;
+ }
+
if (b->irq_enabled) {
irq_disable(engine);
b->irq_enabled = false;
@@ -661,3 +678,191 @@ unsigned int intel_breadcrumbs_busy(struct
drm_i915_private *i915)
return mask;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include
+
+#include "i915_selftest.h"
+
+static struct intel_engine_cs *mock_engine(const char *name)
+{
+ struct intel_engine_cs *engine;
+ static int id;
+
+ engine = kzalloc(sizeof(*engine) + 4096, GFP_TEMPORARY);
Nitpick but PAGE_SIZE would be better if you care the change it.
+ if (!engine)
+ return NULL;
+
+ /* minimal engine setup for seqno */
+ engine->name = name;
+ engine->id = id++;
+ engine->status_page.page_addr = (void *)(engine + 1);
+
+ /* minimal breadcrumbs init */
+ spin_lock_init(&engine->breadcrumbs.lock);
+ engine->breadcrumbs.mock = true;
+
+ return engine;
+}
+
+static int *get_random_order(int count)
+{
+ int *order;
+ int n, r, tmp;
+
+ order = kmalloc_array(count, sizeof(*order), GFP_TEMPORARY);
+ if (!order)
+ return order;
+
+ for (n = 0; n < count; n++)
+ order[n] = n;
+
+ for (n = count - 1; n > 1; n--) {
+ r = get_random_int() % (n + 1);
+ if (r != n) {
+ tmp = order[n];
+ order[n] = order[r];
+ order[r] = tmp;
+ }
+ }
+
+ return order;
+}
+
+static int check_rbtree(struct intel_engine_cs *engine,
+ const unsigned long *bitmap,
+ const struct intel_wait *waiters,
+ const int count)
+{
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ struct rb_node *rb;
+ int n;
+
+ if (&b->first_wait->node != rb_first(&b->waiters)) {
+ pr_err("First waiter does not match first element of
wait-tree\n");
+ return -EINVAL;
+ }
+
+ n = find_first_bit(bitmap, count);
+ for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
+ struct intel_wait *w = container_of(rb, typeof(*w), node);
+ int idx = w - waiters;
+
+ if (!test_bit(idx, bitmap)) {
+ pr_err("waiter[%d, seqno=%d] removed but still in
wait-tree\n",
+ idx, w->seqno);
+ return -EINVAL;
+ }
+
+ if (n != idx) {
+ pr_err("waiter[%d, seqno=%d] does not match expected next
element in tree [%d]\n",
+ idx, w->seqno, n);
+ return -EINVAL;
Re: [Intel-gfx] [lkp] [PATCH] drm/i915: Fix intel_psr_init() kerneldoc
On Tue, 2016-12-06 at 02:01 +0800, Ye Xiaolong wrote: > On 11/30, Ander Conselvan De Oliveira wrote: > > > > On Wed, 2016-11-30 at 09:29 +0800, kbuild test robot wrote: > > > > > > Hi Ander, > > > > > > [auto build test WARNING on drm-intel/for-linux-next] > > > [also build test WARNING on v4.9-rc7 next-20161129] > > > [if your patch is applied to the wrong git tree, please drop us a note to > > > help improve the system] > > > > > > url: https://github.com/0day-ci/linux/commits/Ander-Conselvan-de-Olivei > > > ra/drm-i915-Fix-intel_psr_init-kerneldoc/20161130-081024 > > > base: git://anongit.freedesktop.org/drm-intel for-linux-next > > > 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/workqueue.h:392: warning: No description found for > > > parameter '...' > > > include/linux/workqueue.h:392: warning: Excess function parameter > > > 'args' description in 'alloc_workqueue' > > > include/linux/workqueue.h:413: warning: No description found for > > > parameter '...' > > > include/linux/workqueue.h:413: warning: Excess function parameter > > > 'args' description in 'alloc_ordered_workqueue' > > > include/linux/kthread.h:26: warning: No description found for parameter > > > '...' > > > kernel/sys.c:1: warning: no structured comments found > > > drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found > > > include/sound/core.h:324: warning: No description found for parameter > > > '...' > > > include/sound/core.h:335: warning: No description found for parameter > > > '...' > > > include/sound/core.h:388: warning: No description found for parameter > > > '...' > > > include/drm/drm_drv.h:295: warning: Incorrect use of kernel-doc > > > format: * Hook for allocating the GEM object struct, for use by core > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'load' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'firstopen' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'open' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'preclose' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'postclose' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'lastclose' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'unload' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'dma_ioctl' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'dma_quiescent' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'context_dtor' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'set_busid' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'irq_handler' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'irq_preinstall' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'irq_postinstall' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'irq_uninstall' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'debugfs_init' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'debugfs_cleanup' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_open_object' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_close_object' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_create_object' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'prime_handle_to_fd' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'prime_fd_to_handle' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_export' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_import' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_pin' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_unpin' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_res_obj' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_get_sg_table' > > > include/drm/drm_drv.h:407: warning: No description found for parameter > > > 'gem_prime_import_sg_table' > > > include/drm/drm_
Re: [Intel-gfx] [PATCH 01/16] drm/i915: Provide a hook for selftests
On Thu, Dec 08, 2016 at 10:47:52AM +, Tvrtko Ursulin wrote:
> On 07/12/2016 13:58, Chris Wilson wrote:
> >-return i915_driver_load(pdev, ent);
> >+err = i915_driver_load(pdev, ent);
> >+if (err)
> >+return err;
> >+
> >+err = i915_late_selftests(pdev);
> >+if (err) {
> >+i915_driver_unload(pci_get_drvdata(pdev));
> >+return err > 0 ? -ENOTTY : err;
>
> Here ...
>
> >+}
> >+
> >+return 0;
> > }
> >
> > static void i915_pci_remove(struct pci_dev *pdev)
> >@@ -520,6 +532,11 @@ static struct pci_driver i915_pci_driver = {
> > static int __init i915_init(void)
> > {
> > bool use_kms = true;
> >+int err;
> >+
> >+err = i915_mock_selftests();
> >+if (err)
> >+return err > 0 ? 0 : err;
>
> ... and here, the return conversion is different but in the
> implementation is the same. It is probably wrong or at least
> confusing so it would be good to make it the same.
The return convention is tricky because ->probe and module_init want
different things. To cancel the probe, we have to return an error value
(-ENOTTY). But for integration with kselftest we want the module load to
report success (kselftest effectively uses
modprobe i915 mock_selftests=-1 || exit "FAIL"
). Our igt_kselftest has access to the error code from the syscall and
so can differentiate better than the kselftest.sh, but that shell script
is the lowest common demoninator
-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 04/16] drm/i915: Add unit tests for the breadcrumb rbtree, completion
On 07/12/2016 13:58, Chris Wilson wrote:
Second retroactive test, make sure that the waiters are removed from the
global wait-tree when their seqno completes.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 110 +++
1 file changed, 110 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c768608974e1..fc950f7ff322 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -705,6 +705,12 @@ static struct intel_engine_cs *mock_engine(const char
*name)
return engine;
}
+static void mock_seqno_advance(struct intel_engine_cs *engine, u32 seqno)
+{
+ intel_write_status_page(engine, I915_GEM_HWS_INDEX, seqno);
+ intel_engine_wakeup(engine);
+}
+
static int *get_random_order(int count)
{
int *order;
@@ -766,6 +772,27 @@ static int check_rbtree(struct intel_engine_cs *engine,
return 0;
}
+static int check_completion(struct intel_engine_cs *engine,
+ const unsigned long *bitmap,
+ const struct intel_wait *waiters,
+ const int count)
+{
+ int n;
+
+ for (n = 0; n < count; n++) {
+ if (intel_wait_complete(&waiters[n]) != !!test_bit(n, bitmap))
+ continue;
+
+ pr_err("waiter[%d, seqno=%d] is %s, but expected %s\n",
+ n, waiters[n].seqno,
+ intel_wait_complete(&waiters[n]) ? "complete" : "active",
+ test_bit(n, bitmap) ? "active" : "complete");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int check_rbtree_empty(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
@@ -857,10 +884,93 @@ static int igt_random_insert_remove(void *ignore)
return err;
}
+static int igt_insert_complete(void *ignore)
+{
+ struct intel_engine_cs *engine;
+ struct intel_wait *waiters;
+ const int count = 4096;
+ unsigned long *bitmap;
+ int err = -ENOMEM;
+ int n, m;
+
+ engine = mock_engine("mock");
+ if (!engine)
+ goto out;
+
+ waiters = drm_malloc_gfp(count, sizeof(*waiters), GFP_TEMPORARY);
+ if (!waiters)
+ goto out_engines;
+
+ bitmap = kcalloc(DIV_ROUND_UP(count, BITS_PER_LONG), sizeof(*bitmap),
+GFP_TEMPORARY);
+ if (!bitmap)
+ goto out_waiters;
+
+ for (n = 0; n < count; n++) {
+ intel_wait_init(&waiters[n], n + 0x1000);
Maybe const int seqno_start = 0x1000 since there are multiple users.
+ intel_engine_add_wait(engine, &waiters[n]);
+ __set_bit(n, bitmap);
+ }
+ err = check_rbtree(engine, bitmap, waiters, count);
+ if (err)
+ goto err;
+
+ for (n = 0; n < count; n = m) {
+ int seqno = 2 * n;
+
+ GEM_BUG_ON(find_first_bit(bitmap, count) != n);
+
+ if (intel_wait_complete(&waiters[n])) {
+ pr_err("waiter[%d, seqno=%d] completed too early\n",
+ n, waiters[n].seqno);
+ err = -EINVAL;
+ goto err;
+ }
+
+ /* complete the following waiters */
+ mock_seqno_advance(engine, seqno + 0x1000);
+ for (m = n; m <= seqno; m++) {
+ if (m == count)
+ break;
+
+ GEM_BUG_ON(!test_bit(m, bitmap));
+ __clear_bit(m, bitmap);
+ }
+
+ intel_engine_remove_wait(engine, &waiters[n]);
+ RB_CLEAR_NODE(&waiters[n].node);
+
+ err = check_rbtree(engine, bitmap, waiters, count);
+ if (err) {
+ pr_err("rbtree corrupt after seqno advance to %d\n",
+ seqno + 0x1000);
+ goto err;
+ }
+
+ err = check_completion(engine, bitmap, waiters, count);
+ if (err) {
+ pr_err("completions after seqno advance to %d failed\n",
+ seqno + 0x1000);
+ goto err;
+ }
+ }
+
+ err = check_rbtree_empty(engine);
+err:
+ kfree(bitmap);
+out_waiters:
+ drm_free_large(waiters);
+out_engines:
+ kfree(engine);
+out:
+ return err;
+}
+
int intel_breadcrumbs_selftest(void)
{
static const struct i915_subtest tests[] = {
SUBTEST(igt_random_insert_remove),
+ SUBTEST(igt_insert_complete),
};
return i915_subtests(tests, NULL);
Looks OK.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing l
Re: [Intel-gfx] [PATCH] drm: Update drm_device docs about embedding.
On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > It's supported now! Spotted while reviewing Chris' patch to add a > > release hook. > > > > Cc: Chris Wilson > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_drv.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > index f74b7d06ec01..4ec61ac27477 100644 > > --- a/drivers/gpu/drm/drm_drv.c > > +++ b/drivers/gpu/drm/drm_drv.c > > @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) > > * historical baggage. Hence use the reference counting provided by > > * drm_dev_ref() and drm_dev_unref() only carefully. > > * > > - * Also note that embedding of &drm_device is currently not (yet) > > supported (but > > - * it would be easy to add). Drivers can store driver-private data in the > > - * dev_priv field of &drm_device. > > + * It is recommended that drivers embed struct &drm_device into their own > > device > > + * structure, which is supported through drm_dev_init(). > > */ > > > > /** > > @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) > > * Note that for purely virtual devices @parent can be NULL. > > * > > * Drivers that do not want to allocate their own device struct > > - * embedding struct &drm_device can call drm_dev_alloc() instead. > > + * embedding struct &drm_device can call drm_dev_alloc() instead. For > > drivers > > + * that do embed struct &drm_device it must be placed first in the overall > > + * structure, and the overall structure must be allocated using kmalloc(): > > The > > + * drm core's release function unconditionally calls kfree() on the @dev > > pointer > > + * when the final reference is released. > > Hmm, the privates are getting pretty big (drm_i915_private fits inside > malloc-32678). We should start considering using drm_free_large() instead > as that more or less work transparently and allows fallback to vmalloc. Yeah, I wondered whether your new ->release hook should be the very last thing in drm_dev_release, and that it would replace the final kfree. Then we could do custom stuff in drivers that have an oversized dev struct ;-) > As it stands the doc update is correct, so > Reviewed-by: Chris Wilson Thanks for the review, applied to drm-misc. -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
[Intel-gfx] ✓ Fi.CI.BAT: success for Claw back the IS_ optimisation
== Series Details == Series: Claw back the IS_ optimisation URL : https://patchwork.freedesktop.org/series/16544/ State : success == Summary == Series 16544v1 Claw back the IS_ optimisation https://patchwork.freedesktop.org/api/1.0/series/16544/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-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 17b1372b7ee9bfd08072bdbeab11b372e82c073b drm-tip: 2016y-12m-08d-10h-13m-45s UTC integration manifest 759148f4 drm/i915: Number the platform enum strategically 4ceaea9 drm/i915: Generate all IS_ macros 01e2445 drm/i915: Introduct i915_platforms.h == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3233/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote: > > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote: > > This is still missing corresponding documentation changes, and I haven't > > moved anything to drm_print.h yet, as suggested. > > > > Sending out with a few functional improvements first to get agreement > > before documenting anything (changes summarised in v2: section below) > > > > In particular, affecting the output format, I stole an idea from Tvrtko > > Ursulin to have the prefix for messages be based on the driver name, > > such as "[i915]" instead of always being "[drm]". > > > > Depending on peoples thoughts on compatibility, we could consider > > removing the prefix given that the dynamic debug control interface has a > > way of specifying that messages should include a module name, function > > or line info like: > > > > echo "module i915 +mfp" > dynamic_debug/control > > > > That would enable all i915 debug messages with a module and function > > prefix. > > > > A trade-off would be that anyone only using the drm.drm_debug interface > > to control messages would loose some information. If we really wanted we > > could have the best of both by adding a utility printing api that can > > recognise when printing due to a dynamic debug control query vs > > drm.drm_debug to conditionally add the prefix. > > > > --- >8 --- (git am --scissors) > > > > Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt) > > allow fine grained control over which debug messages are enabled with > > runtime control through /sysfs/kernel/debug/dynamic_debug/control > > > > This provides more control than the current drm.drm_debug parameter > > which for some use cases is impractical to use given how chatty > > some drm debug categories are. > > > > For example all debug messages in i915_drm.c can be enabled with: > > echo "file i915_perf.c +p" > dynamic_debug/control > > > > This doesn't strictly maintain format compatibility with the previous > > debug messages since the category is now added as part of the prefix > > like "[drm][kms] No FB found". Adding the categories with a consistent > > format makes it possible to enable categories with a dynamic debug > > query like: echo "format [kms] +p" > dynamic_debug/control > > > > This maintains support for enabling debug messages using the drm_debug > > parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the > > debug messages essentially work as before, except with the inclusion of > > categories in the format strings as described above. > > > > This removes the drm_[dev_]printk wrappers considering that the dynamic > > debug macros are only useful if they can track the __FILE__, __func__ > > and __LINE__ where they are called. The wrapper didn't seem necessary in > > the DRM_UT_NONE case with no category flag. > > > > The non _DEV macros are no longer defined in terms of passing NULL to a > > _DEV variant to avoid have the core.c dev_printk implementation adding > > "(NULL device *)". The previous drm_[dev_]prink function used to handle > > this as a special case. > > > > Instead of using DRM_NAME to add [drm] to the start of every message, > > the prefix is now based on module_name(THIS_MODULE) so it will be [drm] > > or e.g. [i915] for the Intel driver. Later we might consider removing > > the prefix altogether considering that the dynamic debug control > > interface has a way of optionally adding the module, function or line to > > the formatting of messages. > > > > v2: > > Add categories to format like "[drm][kms] No FB found" > > Only single conditional call per message (macros expand to less code) > > Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features > > Use module name for msg prefix like [drm] or [i915] > > > > Signed-off-by: Robert Bragg > > Cc: dri-de...@lists.freedesktop.org > > Cc: Daniel Vetter > > Cc: Tvrtko Ursulin > > So assuming I understand it correctly - I like this 3way cascade of > dynamic debug, then printk and no_printk fallback if CONFIG_DEBUG=n for > the space concious. But I guess we do need to add a DRM Kconfig knob to > set DEBUG, at least I'm not entirely sure how that's supposed to work. Or > we might need to have our own #ifdef maze for this. Maybe we need to keep > the old drm*printk stuff for that? Right, I wasn't really sure who/what's responsible for defining DEBUG. I just found this convention documented in Documentation/CodingStyle: > Coming up with good debugging messages can be quite a challenge; and once > you have them, they can be a huge help for remote troubleshooting. However > debug message printing is handled differently than printing other non-debug > messages. While the other pr_XXX() functions print unconditionally, > pr_debug() does not; it is compiled out by default, unless either DEBUG is > defined or CONFIG_DYNAMIC_DEBUG is set. That is true for dev_dbg() also, > and a related convention uses VERBOSE_DEBUG to add dev_vdbg() mess
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move uncore selfchecks to late selftest infrastructure
On 07/12/2016 18:52, Chris Wilson wrote:
Now that the kselftest infrastructure exists, put it to use and add to
it the existing consistency checks on the fw register lookup tables.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_late_selftests.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c| 116 +
2 files changed, 69 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_late_selftests.h
b/drivers/gpu/drm/i915/i915_late_selftests.h
index e6645d08d964..289a651db2fd 100644
--- a/drivers/gpu/drm/i915/i915_late_selftests.h
+++ b/drivers/gpu/drm/i915/i915_late_selftests.h
@@ -8,4 +8,5 @@
*
* Tests are executed in reverse order by igt/drv_selftest
*/
+selftest(uncore, intel_uncore_late_selftests)
selftest(sanitycheck, i915_late_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index c1ca4df38dea..bd8436b8f3a4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -628,33 +628,6 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32
offset)
return entry ? entry->domains : 0;
}
-static void
-intel_fw_table_check(struct drm_i915_private *dev_priv)
-{
- const struct intel_forcewake_range *ranges;
- unsigned int num_ranges;
- s32 prev;
- unsigned int i;
-
- if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
- return;
-
- ranges = dev_priv->uncore.fw_domains_table;
- if (!ranges)
- return;
-
- num_ranges = dev_priv->uncore.fw_domains_table_entries;
-
- for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
- WARN_ON_ONCE(IS_GEN9(dev_priv) &&
-(prev + 1) != (s32)ranges->start);
- WARN_ON_ONCE(prev >= (s32)ranges->start);
- prev = ranges->start;
- WARN_ON_ONCE(prev >= (s32)ranges->end);
- prev = ranges->end;
- }
-}
-
#define GEN_FW_RANGE(s, e, d) \
{ .start = (s), .end = (e), .domains = (d) }
@@ -693,23 +666,6 @@ static const i915_reg_t gen8_shadowed_regs[] = {
/* TODO: Other registers are not yet used */
};
-static void intel_shadow_table_check(void)
-{
- const i915_reg_t *reg = gen8_shadowed_regs;
- s32 prev;
- u32 offset;
- unsigned int i;
-
- if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG))
- return;
-
- for (i = 0, prev = -1; i < ARRAY_SIZE(gen8_shadowed_regs); i++, reg++) {
- offset = i915_mmio_reg_offset(*reg);
- WARN_ON_ONCE(prev >= (s32)offset);
- prev = offset;
- }
-}
-
static int mmio_reg_cmp(u32 key, const i915_reg_t *reg)
{
u32 offset = i915_mmio_reg_offset(*reg);
@@ -1436,10 +1392,6 @@ void intel_uncore_init(struct drm_i915_private *dev_priv)
break;
}
- intel_fw_table_check(dev_priv);
- if (INTEL_GEN(dev_priv) >= 8)
- intel_shadow_table_check();
-
if (intel_vgpu_active(dev_priv)) {
ASSIGN_WRITE_MMIO_VFUNCS(vgpu);
ASSIGN_READ_MMIO_VFUNCS(vgpu);
@@ -1962,3 +1914,71 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private
*dev_priv,
return fw_domains;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+#include "i915_selftest.h"
+
+static int intel_fw_table_check(struct drm_i915_private *i915)
+{
+ const struct intel_forcewake_range *ranges;
+ unsigned int num_ranges, i;
+ s32 prev;
+
+ ranges = i915->uncore.fw_domains_table;
+ if (!ranges)
+ return 0;
+
+ num_ranges = i915->uncore.fw_domains_table_entries;
+ for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
+ /* Check that the tabke is watertight */
table
+ if (WARN_ON(IS_GEN9(i915) && (prev + 1) != (s32)ranges->start))
+ return -EINVAL;
+
+ /* Check that the table never goes backwards */
+ if (WARN_ON(prev >= (s32)ranges->start))
+ return -EINVAL;
+
+ /* Check that the entry is valid */
+ if (WARN_ON(ranges->start >= (s32)ranges->end))
Comparison between signed and unsigned?
+ return -EINVAL;
+
+ prev = ranges->end;
+ }
+
+ return 0;
+}
+
+static int intel_shadow_table_check(void)
+{
+ const i915_reg_t *reg = gen8_shadowed_regs;
+ unsigned int i;
+ s32 prev;
+
+ for (i = 0, prev = -1; i < ARRAY_SIZE(gen8_shadowed_regs); i++, reg++) {
+ u32 offset = i915_mmio_reg_offset(*reg);
+ if (WARN_ON(prev >= (s32)offset))
+ return -EINVAL;
+
+ prev = offset;
+ }
+
+ return 0;
+}
+
+int intel_uncore_late_selftests(struct drm_i915_private *i915)
+{
+ int err;
+
+ err = intel_fw_table_check(i915);
+ if (err)
+
Re: [Intel-gfx] [PATCH] drm: Update drm_device docs about embedding.
On Thu, Dec 08, 2016 at 12:53:07PM +0100, Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 10:50:48AM +, Chris Wilson wrote: > > On Thu, Dec 08, 2016 at 11:28:47AM +0100, Daniel Vetter wrote: > > > It's supported now! Spotted while reviewing Chris' patch to add a > > > release hook. > > > > > > Cc: Chris Wilson > > > Signed-off-by: Daniel Vetter > > > --- > > > drivers/gpu/drm/drm_drv.c | 11 +++ > > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c > > > index f74b7d06ec01..4ec61ac27477 100644 > > > --- a/drivers/gpu/drm/drm_drv.c > > > +++ b/drivers/gpu/drm/drm_drv.c > > > @@ -323,9 +323,8 @@ void drm_minor_release(struct drm_minor *minor) > > > * historical baggage. Hence use the reference counting provided by > > > * drm_dev_ref() and drm_dev_unref() only carefully. > > > * > > > - * Also note that embedding of &drm_device is currently not (yet) > > > supported (but > > > - * it would be easy to add). Drivers can store driver-private data in the > > > - * dev_priv field of &drm_device. > > > + * It is recommended that drivers embed struct &drm_device into their > > > own device > > > + * structure, which is supported through drm_dev_init(). > > > */ > > > > > > /** > > > @@ -462,7 +461,11 @@ static void drm_fs_inode_free(struct inode *inode) > > > * Note that for purely virtual devices @parent can be NULL. > > > * > > > * Drivers that do not want to allocate their own device struct > > > - * embedding struct &drm_device can call drm_dev_alloc() instead. > > > + * embedding struct &drm_device can call drm_dev_alloc() instead. For > > > drivers > > > + * that do embed struct &drm_device it must be placed first in the > > > overall > > > + * structure, and the overall structure must be allocated using > > > kmalloc(): The > > > + * drm core's release function unconditionally calls kfree() on the @dev > > > pointer > > > + * when the final reference is released. > > > > Hmm, the privates are getting pretty big (drm_i915_private fits inside > > malloc-32678). We should start considering using drm_free_large() instead > > as that more or less work transparently and allows fallback to vmalloc. > > Yeah, I wondered whether your new ->release hook should be the very last > thing in drm_dev_release, and that it would replace the final kfree. Then > we could do custom stuff in drivers that have an oversized dev struct ;-) Also considered that, placing it first helped with the onion of dev = kmalloc() drm_dev_init(dev, &driver); i915_driver_init(dev); ... So we would teardown i915, then drm, then free. For now saying that it can either be kmalloc or vmalloc and having if (is_virt) vfree() else kfree() should suffice. That is until we start allocating new devices so regularly that they want a dedicated per-cpu slab ;) -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 2/2] drm/i915: Test all fw tables during mock selftests
On 07/12/2016 18:52, Chris Wilson wrote:
In addition to just testing the fw table we load, during the initial
mock testing we can test that all tables are valid (so the testing is
not limited to just the platforms that load that particular table).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_mock_selftests.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c| 43 +++---
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_mock_selftests.h
b/drivers/gpu/drm/i915/i915_mock_selftests.h
index 34f32f777b34..d2c469eba1dc 100644
--- a/drivers/gpu/drm/i915/i915_mock_selftests.h
+++ b/drivers/gpu/drm/i915/i915_mock_selftests.h
@@ -11,4 +11,5 @@
selftest(objects, i915_gem_object_selftests)
selftest(requests, i915_gem_request_selftest)
selftest(breadcrumbs, intel_breadcrumbs_selftest)
+selftest(uncore, intel_uncore_mock_selftests)
selftest(sanitycheck, i915_mock_sanitycheck) /* keep last */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index bd8436b8f3a4..8ad93acbb16f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1918,20 +1918,16 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private
*dev_priv,
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "i915_selftest.h"
-static int intel_fw_table_check(struct drm_i915_private *i915)
+static int intel_fw_table_check(const struct intel_forcewake_range *ranges,
+ unsigned int num_ranges,
+ int gen)
{
- const struct intel_forcewake_range *ranges;
- unsigned int num_ranges, i;
+ unsigned int i;
s32 prev;
- ranges = i915->uncore.fw_domains_table;
- if (!ranges)
- return 0;
-
- num_ranges = i915->uncore.fw_domains_table_entries;
for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
/* Check that the tabke is watertight */
- if (WARN_ON(IS_GEN9(i915) && (prev + 1) != (s32)ranges->start))
+ if (WARN_ON(gen >= 9 && (prev + 1) != (s32)ranges->start))
return -EINVAL;
/* Check that the table never goes backwards */
@@ -1965,11 +1961,38 @@ static int intel_shadow_table_check(void)
return 0;
}
+int intel_uncore_mock_selftests(void)
+{
+ struct {
+ const struct intel_forcewake_range *ranges;
+ unsigned int num_ranges;
+ int gen;
+ } fw[] = {
+ { __vlv_fw_ranges, ARRAY_SIZE(__vlv_fw_ranges), 7 },
+ { __chv_fw_ranges, ARRAY_SIZE(__chv_fw_ranges), 8 },
+ { __gen9_fw_ranges, ARRAY_SIZE(__gen9_fw_ranges), 9 },
Tables are not per gen so this is a bit confusing. I don't have a much
better idea though. Apart from replacing "int gen" with "bool
test_watertight"?
+ };
+ int err, i;
+
+ for (i = 0; i < ARRAY_SIZE(fw); i++) {
+ err = intel_fw_table_check(fw[i].ranges,
+ fw[i].num_ranges,
+ fw[i].gen);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
int intel_uncore_late_selftests(struct drm_i915_private *i915)
{
int err;
- err = intel_fw_table_check(i915);
+ /* Confirm the table we load is still valid */
+ err = intel_fw_table_check(i915->uncore.fw_domains_table,
+ i915->uncore.fw_domains_table_entries,
+ INTEL_GEN(i915));
if (err)
return err;
Either way,
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use DRM_DEV_ERROR in i915_driver_load
== Series Details == Series: drm/i915: Use DRM_DEV_ERROR in i915_driver_load URL : https://patchwork.freedesktop.org/series/16441/ State : success == Summary == Series 16441v1 drm/i915: Use DRM_DEV_ERROR in i915_driver_load https://patchwork.freedesktop.org/api/1.0/series/16441/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-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 17b1372b7ee9bfd08072bdbeab11b372e82c073b drm-tip: 2016y-12m-08d-10h-13m-45s UTC integration manifest 6e117d3 drm/i915: Use DRM_DEV_ERROR in i915_driver_load == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3234/ ___ 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: Test all fw tables during mock selftests
On Thu, Dec 08, 2016 at 12:14:10PM +, Tvrtko Ursulin wrote:
> >-static int intel_fw_table_check(struct drm_i915_private *i915)
> >+static int intel_fw_table_check(const struct intel_forcewake_range *ranges,
> >+unsigned int num_ranges,
> >+int gen)
> > {
> >-const struct intel_forcewake_range *ranges;
> >-unsigned int num_ranges, i;
> >+unsigned int i;
> > s32 prev;
> >
> >-ranges = i915->uncore.fw_domains_table;
> >-if (!ranges)
> >-return 0;
> >-
> >-num_ranges = i915->uncore.fw_domains_table_entries;
> > for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
> > /* Check that the tabke is watertight */
> >-if (WARN_ON(IS_GEN9(i915) && (prev + 1) != (s32)ranges->start))
> >+if (WARN_ON(gen >= 9 && (prev + 1) != (s32)ranges->start))
> > return -EINVAL;
> >
> > /* Check that the table never goes backwards */
> >@@ -1965,11 +1961,38 @@ static int intel_shadow_table_check(void)
> > return 0;
> > }
> >
> >+int intel_uncore_mock_selftests(void)
> >+{
> >+struct {
> >+const struct intel_forcewake_range *ranges;
> >+unsigned int num_ranges;
> >+int gen;
> >+} fw[] = {
> >+{ __vlv_fw_ranges, ARRAY_SIZE(__vlv_fw_ranges), 7 },
> >+{ __chv_fw_ranges, ARRAY_SIZE(__chv_fw_ranges), 8 },
> >+{ __gen9_fw_ranges, ARRAY_SIZE(__gen9_fw_ranges), 9 },
>
> Tables are not per gen so this is a bit confusing. I don't have a
> much better idea though. Apart from replacing "int gen" with "bool
> test_watertight"?
bool is_watertight is a good suggestion.
-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 01/16] drm/i915: Provide a hook for selftests
On 08/12/2016 11:15, Chris Wilson wrote:
On Thu, Dec 08, 2016 at 10:47:52AM +, Tvrtko Ursulin wrote:
On 07/12/2016 13:58, Chris Wilson wrote:
- return i915_driver_load(pdev, ent);
+ err = i915_driver_load(pdev, ent);
+ if (err)
+ return err;
+
+ err = i915_late_selftests(pdev);
+ if (err) {
+ i915_driver_unload(pci_get_drvdata(pdev));
+ return err > 0 ? -ENOTTY : err;
Here ...
+ }
+
+ return 0;
}
static void i915_pci_remove(struct pci_dev *pdev)
@@ -520,6 +532,11 @@ static struct pci_driver i915_pci_driver = {
static int __init i915_init(void)
{
bool use_kms = true;
+ int err;
+
+ err = i915_mock_selftests();
+ if (err)
+ return err > 0 ? 0 : err;
... and here, the return conversion is different but in the
implementation is the same. It is probably wrong or at least
confusing so it would be good to make it the same.
The return convention is tricky because ->probe and module_init want
different things. To cancel the probe, we have to return an error value
(-ENOTTY). But for integration with kselftest we want the module load to
report success (kselftest effectively uses
modprobe i915 mock_selftests=-1 || exit "FAIL"
). Our igt_kselftest has access to the error code from the syscall and
so can differentiate better than the kselftest.sh, but that shell script
is the lowest common demoninator
Ah ok.
But you agree on the point of validating that subtest do not return
positive error codes in order not to interfere with the behaviour set by
module parameters?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use DRM_DEV_ERROR in i915_driver_load
On 08/12/2016 12:15, Patchwork wrote: == Series Details == Series: drm/i915: Use DRM_DEV_ERROR in i915_driver_load URL : https://patchwork.freedesktop.org/series/16441/ State : success == Summary == Series 16441v1 drm/i915: Use DRM_DEV_ERROR in i915_driver_load https://patchwork.freedesktop.org/api/1.0/series/16441/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-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 17b1372b7ee9bfd08072bdbeab11b372e82c073b drm-tip: 2016y-12m-08d-10h-13m-45s UTC integration manifest 6e117d3 drm/i915: Use DRM_DEV_ERROR in i915_driver_load 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 01/16] drm/i915: Provide a hook for selftests
On Thu, Dec 08, 2016 at 12:30:23PM +, Tvrtko Ursulin wrote: > But you agree on the point of validating that subtest do not return > positive error codes in order not to interfere with the behaviour > set by module parameters? Yup, checking that the tests don't return our magic values is a good idea. -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: Take ownership of the dmabuf->obj when exporting
On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > Currently the reference for the dmabuf->obj is incremented for the > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > interface), but is released in drm_gem_dmabuf_release() (the lowlevel > handler). Improve the symmetry of the dmabuf->obj ownership by acquiring > the reference in drm_gem_dmabuf_export(). This makes it easier to use > the prime functions directly. > > Signed-off-by: Chris Wilson 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 2/2] drm/i915: Test all fw tables during mock selftests
On ke, 2016-12-07 at 18:52 +, Chris Wilson wrote:
> In addition to just testing the fw table we load, during the initial
> mock testing we can test that all tables are valid (so the testing is
> not limited to just the platforms that load that particular table).
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> +static int intel_fw_table_check(const struct intel_forcewake_range *ranges,
> + unsigned int num_ranges,
> + int gen)
> {
> - const struct intel_forcewake_range *ranges;
> - unsigned int num_ranges, i;
> + unsigned int i;
> s32 prev;
>
> - ranges = i915->uncore.fw_domains_table;
> - if (!ranges)
> - return 0;
> -
> - num_ranges = i915->uncore.fw_domains_table_entries;
> for (i = 0, prev = -1; i < num_ranges; i++, ranges++) {
> /* Check that the tabke is watertight */
s/tabke/table/
> int intel_uncore_late_selftests(struct drm_i915_private *i915)
> {
> int err;
>
> - err = intel_fw_table_check(i915);
> + /* Confirm the table we load is still valid */
> + err = intel_fw_table_check(i915->uncore.fw_domains_table,
> + i915->uncore.fw_domains_table_entries,
> + INTEL_GEN(i915));
> if (err)
> return err;
Maybe the mock test should skip .gen == INTEL_GEN(i915) to avoid
duplicate coverage on full run.
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] [PATCH] drm/edid: Don't print an error if the checksum of a CEA block is wrong
It's common to share screens within CI labs, and it's also common for
KVM switches to alter the contents of the CEA block but leave the
checksum outdated.
So in this case, print a debug message instead of an error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson
Cc: Tomi Sarvela
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_edid.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6798c3ad9d53..db79bc949216 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1128,16 +1128,19 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid,
csum = drm_edid_block_checksum(raw_edid);
if (csum) {
- if (print_bad_edid) {
- DRM_ERROR("EDID checksum is invalid, remainder is
%d\n", csum);
- }
-
if (edid_corrupt)
*edid_corrupt = true;
/* allow CEA to slide through, switches mangle this */
- if (raw_edid[0] != 0x02)
+ if (raw_edid[0] == CEA_EXT) {
+ DRM_DEBUG("EDID checksum is invalid, remainder is
%d\n", csum);
+ DRM_DEBUG("Assuming a KVM switch modified the CEA block
but left the original checksum\n");
+ } else {
+ if (print_bad_edid)
+ DRM_ERROR("EDID checksum is invalid, remainder
is %d\n", csum);
+
goto bad;
+ }
}
/* per-block-type checks */
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Introduct i915_platforms.h
On to, 2016-12-08 at 12:41 +0200, Jani Nikula wrote: > > On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: > > > > From: Tvrtko Ursulin > > > > Inspired by the same approach used by Chris Wilson in the self > > test patches. > > > > We add a separate header file containing the list of our > > platforms and then use the pre-processor to generate all > > other places which use that list. This avoids having to > > list them multiple times and avoids the maintenance > > burden. > > > > Signed-off-by: Tvrtko Ursulin > > Cc: Chris Wilson > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > I was thinking we could improve the printed names here, for example: > > [INTEL_I965G] = "I965G/Broadwater" > [INTEL_VALLEYVIEW] = "Valleyview/Baytrail" > +1 on this idea! 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] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
Hi, On 07/12/2016 18:35, Robert Bragg wrote: This is still missing corresponding documentation changes, and I haven't moved anything to drm_print.h yet, as suggested. Sending out with a few functional improvements first to get agreement before documenting anything (changes summarised in v2: section below) In particular, affecting the output format, I stole an idea from Tvrtko Ursulin to have the prefix for messages be based on the driver name, such as "[i915]" instead of always being "[drm]". Depending on peoples thoughts on compatibility, we could consider removing the prefix given that the dynamic debug control interface has a way of specifying that messages should include a module name, function or line info like: echo "module i915 +mfp" > dynamic_debug/control That would enable all i915 debug messages with a module and function prefix. To check if I got it right, that would put the prefix on debug messages while the rest would not have it? (With the option of dropping the prefix in general that is.) Or you thought just removing the prefix from debug messages? A trade-off would be that anyone only using the drm.drm_debug interface to control messages would loose some information. If we really wanted we could have the best of both by adding a utility printing api that can recognise when printing due to a dynamic debug control query vs drm.drm_debug to conditionally add the prefix. I think prefix by default, on non-debug messages, is required. We could perhaps make it like "drm: message", and not "[drm] message", to match the rest of the kernel? --- >8 --- (git am --scissors) Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt) allow fine grained control over which debug messages are enabled with runtime control through /sysfs/kernel/debug/dynamic_debug/control This provides more control than the current drm.drm_debug parameter which for some use cases is impractical to use given how chatty some drm debug categories are. For example all debug messages in i915_drm.c can be enabled with: echo "file i915_perf.c +p" > dynamic_debug/control This doesn't strictly maintain format compatibility with the previous debug messages since the category is now added as part of the prefix like "[drm][kms] No FB found". Adding the categories with a consistent format makes it possible to enable categories with a dynamic debug query like: echo "format [kms] +p" > dynamic_debug/control If I got it right from the patch the actual debug format is: "[drm:function_name][kms] Message" Correct? In which case I would suggest different grouping, where category comes before the function name. For example: "[drm:kms:function_name] Message" I also find a lot of square braces hard to read. So the current "[function [module]]" is not my favourite so plus points for this initiative as well. In general this looks like a good cleanup and improvement so ack from me. Regards, Tvrtko P.S. Also eliminate DRM_NAME in this work? This maintains support for enabling debug messages using the drm_debug parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the debug messages essentially work as before, except with the inclusion of categories in the format strings as described above. This removes the drm_[dev_]printk wrappers considering that the dynamic debug macros are only useful if they can track the __FILE__, __func__ and __LINE__ where they are called. The wrapper didn't seem necessary in the DRM_UT_NONE case with no category flag. The non _DEV macros are no longer defined in terms of passing NULL to a _DEV variant to avoid have the core.c dev_printk implementation adding "(NULL device *)". The previous drm_[dev_]prink function used to handle this as a special case. Instead of using DRM_NAME to add [drm] to the start of every message, the prefix is now based on module_name(THIS_MODULE) so it will be [drm] or e.g. [i915] for the Intel driver. Later we might consider removing the prefix altogether considering that the dynamic debug control interface has a way of optionally adding the module, function or line to the formatting of messages. v2: Add categories to format like "[drm][kms] No FB found" Only single conditional call per message (macros expand to less code) Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features Use module name for msg prefix like [drm] or [i915] Signed-off-by: Robert Bragg Cc: dri-de...@lists.freedesktop.org Cc: Daniel Vetter Cc: Tvrtko Ursulin --- drivers/gpu/drm/drm_drv.c | 47 --- include/drm/drmP.h| 202 +- 2 files changed, 127 insertions(+), 122 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index f74b7d0..25d00aa 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -65,53 +65,6 @@ static struct idr drm_minors_idr; static struct dentry *drm_debugfs_root; -#define DRM_PRINTK_FMT "[" DRM_NAME ":%s
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Introduct i915_platforms.h
On 08/12/2016 13:16, Joonas Lahtinen wrote: On to, 2016-12-08 at 12:41 +0200, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Inspired by the same approach used by Chris Wilson in the self test patches. We add a separate header file containing the list of our platforms and then use the pre-processor to generate all other places which use that list. This avoids having to list them multiple times and avoids the maintenance burden. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen I was thinking we could improve the printed names here, for example: [INTEL_I965G] = "I965G/Broadwater" [INTEL_VALLEYVIEW] = "Valleyview/Baytrail" +1 on this idea! Too much prettiness for the kernel I would have thought. Don't see the benefit personally. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
On 08/12/2016 10:46, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of listing them individually we can generate them using the new i915_platforms.h header. Also convert them to a static inline function which interestingly makes the code smaller as well. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen NAK. Absolutely opposed to this. Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs any longer? A large part of my work involves digging through the source tree, and a crucial part of that is looking up definitions and references, both for macros and functions. Not having the macro/function definitions breaks that workflow. Losing that, source code archeology gets *much* harder. The losses are much greater than the gains. Hm, I struggle to see that point on the same magnitude of a disaster scale as you. I would have thought we all know what IS_SKYLAKE & co are so it would be no big deal. Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Respect ring_mask and num_pipes when install IRQ
On to, 2016-12-08 at 18:46 +0800, Wang Elaine wrote: > > From: Elaine Wang > > Some platforms only have VCS ring in VDBox. To avoid accessing the > non-existent rings or display registers, check the ring_mask > and num_pipes in gen8 IRQ install and reset functions. > > Cc: Joonas Lahtinen > Signed-off-by: Elaine Wang Looks like a sensible thing to me, not able to test myself. Could use an R-b from Ville. 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 2/3] drm/i915: Generate all IS_ macros
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: > On 08/12/2016 10:46, Jani Nikula wrote: >> On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> Instead of listing them individually we can generate them >>> using the new i915_platforms.h header. >>> >>> Also convert them to a static inline function which >>> interestingly makes the code smaller as well. >>> >>> Signed-off-by: Tvrtko Ursulin >>> Cc: Chris Wilson >>> Cc: Jani Nikula >>> Cc: Joonas Lahtinen >> >> NAK. Absolutely opposed to this. > > Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs > any longer? Only when dropped without rationale. I needed to make it clear in no uncertain terms how important this is to me. >> A large part of my work involves digging through the source tree, and a >> crucial part of that is looking up definitions and references, both for >> macros and functions. Not having the macro/function definitions breaks >> that workflow. Losing that, source code archeology gets *much* >> harder. The losses are much greater than the gains. > > Hm, I struggle to see that point on the same magnitude of a disaster > scale as you. I would have thought we all know what IS_SKYLAKE & co are > so it would be no big deal. Sure we know what they are; I want to be able to see all the *references* to them as well, using GNU global. That fails if they're not defined in the first place. And no, git grep is not the same. > Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance. Then all the things passed as parameter would have to be defined. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Number the platform enum strategically
From: Tvrtko Ursulin
If we use only power of two values for the platform enum
values we can let the compiler optimize some common
checks to a single conditional.
For example code like this:
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
Goes from this:
5c3c5: 8b 83 d8 06 00 00 mov0x6d8(%rbx),%eax
5c3cb: 83 f8 12cmp$0x12,%eax
5c3ce: 0f 84 f3 00 00 00 je 5c4c7
5c3d4: 83 f8 15cmp$0x15,%eax
5c3d7: 0f 84 ea 00 00 00 je 5c4c7
To this:
5c1d5: f7 83 d8 06 00 00 00testl $0x24,0x6d8(%rbx)
5c1dc: 00 24 00
5c1df: 0f 85 da 00 00 00 jne5c2bf
It is not much but there is value in this that as long as we
have to have conditions like the above sprinkled troughout the
code, we can at least have the generate binary a bit smarter.
Until we get to more than 32 platforms there is no downside
to this approach.
v2:
* Remove !! from the comparison. (Chris Wilson)
* Simplify the patch by moving the BIT() to the generator.
(Michal Wajdeczko)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_device_info.c | 10 ++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fb8f4b7cd1ae..3be6a19f22eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -826,7 +826,7 @@ static inline unsigned int sseu_subslice_total(const struct
sseu_dev_info *sseu)
}
enum intel_platform {
-#define i915_platform(name, value) INTEL_##name = value,
+#define i915_platform(name, value) INTEL_##name = BIT(value),
#include "i915_platforms.h"
#undef i915_platform
};
@@ -2590,7 +2590,7 @@ intel_info(const struct drm_i915_private *dev_priv)
#define i915_platform(name, id) \
static inline bool IS_##name(const struct drm_i915_private *dev_priv) \
{ \
- return (dev_priv)->info.platform == INTEL_##name; \
+ return (dev_priv)->info.platform & INTEL_##name; \
}
#include "i915_platforms.h"
#undef i915_platform
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 5192d388d10e..26df6363e265 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -25,18 +25,20 @@
#include "i915_drv.h"
static const char * const platform_names[] = {
-#define i915_platform(name, id) [id] = #name,
+#define i915_platform(name, id) [__builtin_ffs(id)] = #name,
#include "i915_platforms.h"
#undef i915_platform
};
const char *intel_platform_name(enum intel_platform platform)
{
- if (WARN_ON_ONCE(platform >= ARRAY_SIZE(platform_names) ||
-platform_names[platform] == NULL))
+ unsigned int idx = ffs(platform);
+
+ if (WARN_ON_ONCE(idx >= ARRAY_SIZE(platform_names) ||
+platform_names[idx] == NULL))
return "";
- return platform_names[platform];
+ return platform_names[idx];
}
void intel_device_info_dump(struct drm_i915_private *dev_priv)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
On Thu, 08 Dec 2016, Jani Nikula wrote: > On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: >> On 08/12/2016 10:46, Jani Nikula wrote: >>> On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of listing them individually we can generate them using the new i915_platforms.h header. Also convert them to a static inline function which interestingly makes the code smaller as well. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen >>> >>> NAK. Absolutely opposed to this. >> >> Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs >> any longer? > > Only when dropped without rationale. I needed to make it clear in no > uncertain terms how important this is to me. > >>> A large part of my work involves digging through the source tree, and a >>> crucial part of that is looking up definitions and references, both for >>> macros and functions. Not having the macro/function definitions breaks >>> that workflow. Losing that, source code archeology gets *much* >>> harder. The losses are much greater than the gains. >> >> Hm, I struggle to see that point on the same magnitude of a disaster >> scale as you. I would have thought we all know what IS_SKYLAKE & co are >> so it would be no big deal. > > Sure we know what they are; I want to be able to see all the > *references* to them as well, using GNU global. That fails if they're > not defined in the first place. And no, git grep is not the same. > >> Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance. > > Then all the things passed as parameter would have to be defined. Oh, btw, patch 1/3 also fails this because the INTEL_FOO enumerations aren't defined as-is but via macros. This is not as important as the IS_FOO ones, because the former aren't really used throughout the source, while the latter are. BR, Jani. > > > 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/3] drm/i915: Generate all IS_ macros
On 08/12/2016 13:37, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: On 08/12/2016 10:46, Jani Nikula wrote: On Thu, 08 Dec 2016, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Instead of listing them individually we can generate them using the new i915_platforms.h header. Also convert them to a static inline function which interestingly makes the code smaller as well. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Cc: Jani Nikula Cc: Joonas Lahtinen NAK. Absolutely opposed to this. Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs any longer? Only when dropped without rationale. I needed to make it clear in no uncertain terms how important this is to me. Hm ok, I'll give you a benefit of doubt here. A large part of my work involves digging through the source tree, and a crucial part of that is looking up definitions and references, both for macros and functions. Not having the macro/function definitions breaks that workflow. Losing that, source code archeology gets *much* harder. The losses are much greater than the gains. Hm, I struggle to see that point on the same magnitude of a disaster scale as you. I would have thought we all know what IS_SKYLAKE & co are so it would be no big deal. Sure we know what they are; I want to be able to see all the *references* to them as well, using GNU global. That fails if they're not defined in the first place. And no, git grep is not the same. Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance. Then all the things passed as parameter would have to be defined. They are already -> enum intel_platform?! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/atomic: Unconditionally call prepare_fb.
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 23767df72615..d19563651e07 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
funcs = plane->helper_private;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
if (funcs->prepare_fb) {
ret = funcs->prepare_fb(plane, plane_state);
if (ret)
@@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
if (j >= i)
continue;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
@@ -1952,9 +1946,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- if (!drm_atomic_helper_framebuffer_changed(dev, old_state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.
When DPMS was introduced to atomic, vblanks only worked when the crtc was enabled and active. wait_for_vblanks were not converted to check for crtc_state->active, which may cause an attempt for vblank_get to fail. This is probably harmless, but convert from enable to active anyway. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 583f47f27b36..23767df72615 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -1117,7 +1117,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev, * vblank wait) in the ->enable boolean. */ old_crtc_state->enable = false; - if (!crtc->state->enable) + if (!crtc->state->active) continue; /* Legacy cursor ioctls are completely unsynced, and userspace -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.
Do something similar to vc4, only allow updating the cursor state
in-place through a fastpath when the watermarks are unaffected. This
will allow cursor movement to be smooth, but changing cursor size or
showing/hiding cursor will still fall back so watermarks can be updated.
Only moving and changing fb is allowed.
Changes since v1:
- Set page flip to always_unused for trybot.
- Copy fence correctly, ignore plane_state->state, should be NULL.
- Check crtc_state for !active and modeset, go to slowpath if the case.
Signed-off-by: Maarten Lankhorst
Acked-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++-
drivers/gpu/drm/i915/intel_display.c | 123 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +
3 files changed, 153 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dbe9fb41ae53..60d75ce8a989 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
drm_atomic_helper_plane_destroy_state(plane, state);
}
-static int intel_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *intel_state)
{
+ struct drm_plane *plane = intel_state->base.plane;
struct drm_i915_private *dev_priv = to_i915(plane->dev);
- struct drm_crtc *crtc = state->crtc;
- struct intel_crtc *intel_crtc;
- struct intel_crtc_state *crtc_state;
+ struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
- struct intel_plane_state *intel_state = to_intel_plane_state(state);
- struct drm_crtc_state *drm_crtc_state;
int ret;
- crtc = crtc ? crtc : plane->state->crtc;
- intel_crtc = to_intel_crtc(crtc);
-
/*
* Both crtc and plane->crtc could be NULL if we're updating a
* property while the plane is disabled. We don't actually have
* anything driver-specific we need to test in that case, so
* just return success.
*/
- if (!crtc)
+ if (!intel_state->base.crtc && !plane->state->crtc)
return 0;
- drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
- if (WARN_ON(!drm_crtc_state))
- return -EINVAL;
-
- crtc_state = to_intel_crtc_state(drm_crtc_state);
-
/* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
intel_state->clip.x1 = 0;
intel_state->clip.y1 = 0;
@@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
return intel_plane_atomic_calc_changes(&crtc_state->base, state);
}
+static int intel_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_crtc_state *drm_crtc_state;
+
+ crtc = crtc ? crtc : plane->state->crtc;
+
+ /*
+* Both crtc and plane->crtc could be NULL if we're updating a
+* property while the plane is disabled. We don't actually have
+* anything driver-specific we need to test in that case, so
+* just return success.
+*/
+ if (!crtc)
+ return 0;
+
+ drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!drm_crtc_state))
+ return -EINVAL;
+
+ return
intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
+ to_intel_plane_state(state));
+}
+
static void intel_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9eaf1e5bdae9..a8b8663ecda7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15028,6 +15029,124 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
};
+static int
+intel_legacy_cursor_update(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ int ret;
+ struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct intel_pl
[Intel-gfx] [PATCH 3/6] drm/atomic: Clean up wait_for_vblanks
Stop relying on a per crtc_state last_vblank_count, we know in advance
how many there can be. Also stop re-using new_crtc_state->enable,
we can now simply set a bitmask with crtc_crtc_mask.
---
drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
include/drm/drm_crtc.h | 5 -
2 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index d19563651e07..ccf0bed9bf4a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1110,19 +1110,20 @@ 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;
+ unsigned last_vblank_count[dev->mode_config.num_crtc];
+
+/*
+ * Legacy cursor ioctls are completely unsynced, and userspace
+ * relies on that (by doing tons of cursor updates).
+ */
+ if (old_state->legacy_cursor_update)
+ return;
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;
-
- if (!crtc->state->active)
- continue;
+ 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 +1134,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);
+ last_vblank_count[i] = 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 !=
+ last_vblank_count[i] !=
drm_crtc_vblank_count(crtc),
msecs_to_jiffies(50));
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;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed
drm_atomic_helpers use framebuffer_changed to skip some vblank waits in case properties don't change. This may skip vblank waits also when properties like rotation are changed. Fix this by always waiting for vblank if planes are added to the state, and always calling prepare_fb even when fb stays the same. Any smarts for this should be in the driver, they know when waiting can be skipped. While at it, cleanup drm_atomic_helper_wait_for_vblanks. It's reusing members of the crtc_state for different things, Maarten Lankhorst (6): drm/atomic: Use active instead of enable in wait_for_vblanks. drm/atomic: Unconditionally call prepare_fb. drm/atomic: Clean up wait_for_vblanks drm/atomic: Wait for vblank whenever a plane is added to state. drm/atomic: Remove drm_atomic_helper_framebuffer_changed. drm/i915: Add a cursor hack to allow converting legacy page flip to atomic. drivers/gpu/drm/drm_atomic_helper.c | 77 --- drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++- drivers/gpu/drm/i915/intel_display.c | 123 +- drivers/gpu/drm/i915/intel_drv.h | 2 + include/drm/drm_atomic_helper.h | 3 - include/drm/drm_crtc.h| 5 -- 6 files changed, 168 insertions(+), 89 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.
The current api doesn't take into account that whenever properties like
rotation or z-pos change we have to wait for vblank. To make sure
that we wait correctly, err on the side of caution and wait whenever
a plane is added to state.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index ccf0bed9bf4a..fdeaea84a3b7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
*dev,
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
struct drm_crtc_state *new_crtc_state = crtc->state;
- if (!new_crtc_state->active)
- continue;
-
- if (!drm_atomic_helper_framebuffer_changed(dev,
- old_state, crtc))
+ if (!new_crtc_state->active || !new_crtc_state->planes_changed)
continue;
ret = drm_crtc_vblank_get(crtc);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/atomic: Remove drm_atomic_helper_framebuffer_changed.
This function is now completely unused, zap it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 35 ---
include/drm/drm_atomic_helper.h | 3 ---
2 files changed, 38 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fdeaea84a3b7..69ee1a94e851 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1058,41 +1058,6 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
*dev,
EXPORT_SYMBOL(drm_atomic_helper_wait_for_fences);
/**
- * drm_atomic_helper_framebuffer_changed - check if framebuffer has changed
- * @dev: DRM device
- * @old_state: atomic state object with old state structures
- * @crtc: DRM crtc
- *
- * Checks whether the framebuffer used for this CRTC changes as a result of
- * the atomic update. This is useful for drivers which cannot use
- * drm_atomic_helper_wait_for_vblanks() and need to reimplement its
- * functionality.
- *
- * Returns:
- * true if the framebuffer changed.
- */
-bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
- struct drm_atomic_state *old_state,
- struct drm_crtc *crtc)
-{
- struct drm_plane *plane;
- struct drm_plane_state *old_plane_state;
- int i;
-
- for_each_plane_in_state(old_state, plane, old_plane_state, i) {
- if (plane->state->crtc != crtc &&
- old_plane_state->crtc != crtc)
- continue;
-
- if (plane->state->fb != old_plane_state->fb)
- return true;
- }
-
- return false;
-}
-EXPORT_SYMBOL(drm_atomic_helper_framebuffer_changed);
-
-/**
* drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
* @dev: DRM device
* @old_state: atomic state object with old state structures
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 7ff92b09fd9c..4b2353dc34ba 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -48,9 +48,6 @@ int drm_atomic_helper_commit(struct drm_device *dev,
int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
struct drm_atomic_state *state,
bool pre_swap);
-bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
- struct drm_atomic_state *old_state,
- struct drm_crtc *crtc);
void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
struct drm_atomic_state *old_state);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> On 08/12/2016 13:37, Jani Nikula wrote:
>> On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
>>> On 08/12/2016 10:46, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of listing them individually we can generate them
> using the new i915_platforms.h header.
>
> Also convert them to a static inline function which
> interestingly makes the code smaller as well.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
NAK. Absolutely opposed to this.
>>>
>>> Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs
>>> any longer?
>>
>> Only when dropped without rationale. I needed to make it clear in no
>> uncertain terms how important this is to me.
>
> Hm ok, I'll give you a benefit of doubt here.
Thanks; I hope you've observed I don't use it lightly.
A large part of my work involves digging through the source tree, and a
crucial part of that is looking up definitions and references, both for
macros and functions. Not having the macro/function definitions breaks
that workflow. Losing that, source code archeology gets *much*
harder. The losses are much greater than the gains.
>>>
>>> Hm, I struggle to see that point on the same magnitude of a disaster
>>> scale as you. I would have thought we all know what IS_SKYLAKE & co are
>>> so it would be no big deal.
>>
>> Sure we know what they are; I want to be able to see all the
>> *references* to them as well, using GNU global. That fails if they're
>> not defined in the first place. And no, git grep is not the same.
>>
>>> Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance.
>>
>> Then all the things passed as parameter would have to be defined.
>
> They are already -> enum intel_platform?!
See the other mail; they'd have to be defined directly (as they
currently are in git) instead of via macros (as in patch 1).
Hmm, how about
static inline bool intel_is_platform(const struct drm_i915_private *dev_priv,
enum intel_platform platform)
{
return dev_priv->info.platform == platform;
}
and doing
#define IS_FOO(dev_priv) intel_is_platform(dev_priv, INTEL_FOO)
manually for the ones we actually use (we don't need them all)? If the
function is inline, I don't see how defining N similar functions instead
of passing in the parameter would be more efficient. And you could still
do the optimizations of patchs 3/3 AFAICS.
Suitable compromise?
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 v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match the spec, but we still see a timeout on
> at least one SKL. A CDCLK change request following the failed one will
> succeed nevertheless.
>
> I could reproduce this problem easily by running kms_pipe_crc_basic in a
> loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> the worst case - when the pre-emption happened right after calculating
> timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> once which failed and so _wait_for() timed out. As opposed to this the
> spec says to keep retrying the request for at most a 3ms period.
>
> To fix this send the first request explicitly to guarantee that there is
> 3ms between the first and last request. Though this matches the spec, I
> noticed that in rare cases this can still time out if we sent only a few
> requests (in the worst case 2) _and_ PCODE is busy for some reason even
> after a previous request and a 3ms delay. To work around this retry the
> polling with pre-emption disabled to maximize the number of requests.
> Also increase the timeout to 10ms to account for interrupts that could
> reduce the number of requests. With this change I couldn't trigger
> the problem.
>
> v2:
> - Use 1ms poll period instead of 10us. (Chris)
> v3:
> - Poll with pre-emption disabled to increase the number of request
> attempts. (Ville, Chris)
> - Factor out a helper to poll, it's also needed by the next patch.
> v4:
> - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
> reply is generic. (Ville)
> v5:
> - List the request specific timeout values as code comment. (Ville)
> v6:
> - Try the poll first with preemption enabled.
> - Add code comment about first request being queued by PCODE. (Art)
> - Add timeout_base_ms argument. (Ville)
>
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Cc: Art Runyan
> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> Signed-off-by: Imre Deak
The only issue I have is that buried within snb_pcode_read() is another
wait_for, now in an atomic section and we have been trying to erradicate
those. It should be happy enough, just a pita to fix later!
Other than that and a minor nit, it looks like a reasonable compromise.
Reviewed-by: Chris Wilson
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 31 +--
> drivers/gpu/drm/i915/intel_pm.c | 75
>
> 3 files changed, 87 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ca9786c..a2462bf 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3597,6 +3597,8 @@ extern void intel_display_print_error_state(struct
> drm_i915_error_state_buf *e,
>
> int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
> *val);
> int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
> val);
> +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> request,
> + u32 reply_mask, u32 reply, int timeout_base_ms);
>
> /* intel_sideband.c */
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1fafcce..4ef7392 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6280,35 +6280,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> dev_priv->cdclk_pll.vco = 0;
> }
>
> -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - int ret;
> - u32 val;
> -
> - /* inform PCU we want to change CDCLK */
> - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> - mutex_lock(&dev_priv->rps.hw_lock);
> - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> - mutex_unlock(&dev_priv->rps.hw_lock);
> -
> - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> -}
> -
> -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> -{
> - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> -}
> -
> static void skl_set_cdclk(struct drm_i915_private *dev_priv, int cdclk, int
> vco)
> {
> u32 freq_select, pcu_ack;
> + int ret;
>
> WARN_ON((cdclk == 24000) != (vco == 0));
>
> DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz (VCO %d kHz)\n", cdclk, vco);
>
> - if (!skl_cdclk_wait_for_pcu_ready(dev_priv)) {
> - DRM_ERROR("failed to inform PCU about cdclk change\n");
> + mutex_lock(&dev_priv->rps.hw_lock);
> + ret =
Re: [Intel-gfx] [RFC v2] drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
On Thu, Dec 08, 2016 at 11:57:25AM +, Robert Bragg wrote: > On Thu, Dec 8, 2016 at 12:17 AM, Daniel Vetter wrote: > > > > On Wed, Dec 07, 2016 at 06:35:29PM +, Robert Bragg wrote: > > > This is still missing corresponding documentation changes, and I haven't > > > moved anything to drm_print.h yet, as suggested. > > > > > > Sending out with a few functional improvements first to get agreement > > > before documenting anything (changes summarised in v2: section below) > > > > > > In particular, affecting the output format, I stole an idea from Tvrtko > > > Ursulin to have the prefix for messages be based on the driver name, > > > such as "[i915]" instead of always being "[drm]". > > > > > > Depending on peoples thoughts on compatibility, we could consider > > > removing the prefix given that the dynamic debug control interface has a > > > way of specifying that messages should include a module name, function > > > or line info like: > > > > > > echo "module i915 +mfp" > dynamic_debug/control > > > > > > That would enable all i915 debug messages with a module and function > > > prefix. > > > > > > A trade-off would be that anyone only using the drm.drm_debug interface > > > to control messages would loose some information. If we really wanted we > > > could have the best of both by adding a utility printing api that can > > > recognise when printing due to a dynamic debug control query vs > > > drm.drm_debug to conditionally add the prefix. > > > > > > --- >8 --- (git am --scissors) > > > > > > Dynamic debug messages (ref: Documentation/dynamic-debug-howto.txt) > > > allow fine grained control over which debug messages are enabled with > > > runtime control through /sysfs/kernel/debug/dynamic_debug/control > > > > > > This provides more control than the current drm.drm_debug parameter > > > which for some use cases is impractical to use given how chatty > > > some drm debug categories are. > > > > > > For example all debug messages in i915_drm.c can be enabled with: > > > echo "file i915_perf.c +p" > dynamic_debug/control > > > > > > This doesn't strictly maintain format compatibility with the previous > > > debug messages since the category is now added as part of the prefix > > > like "[drm][kms] No FB found". Adding the categories with a consistent > > > format makes it possible to enable categories with a dynamic debug > > > query like: echo "format [kms] +p" > dynamic_debug/control > > > > > > This maintains support for enabling debug messages using the drm_debug > > > parameter. If dynamic debug is not enabled via CONFIG_DYNAMIC_DEBUG the > > > debug messages essentially work as before, except with the inclusion of > > > categories in the format strings as described above. > > > > > > This removes the drm_[dev_]printk wrappers considering that the dynamic > > > debug macros are only useful if they can track the __FILE__, __func__ > > > and __LINE__ where they are called. The wrapper didn't seem necessary in > > > the DRM_UT_NONE case with no category flag. > > > > > > The non _DEV macros are no longer defined in terms of passing NULL to a > > > _DEV variant to avoid have the core.c dev_printk implementation adding > > > "(NULL device *)". The previous drm_[dev_]prink function used to handle > > > this as a special case. > > > > > > Instead of using DRM_NAME to add [drm] to the start of every message, > > > the prefix is now based on module_name(THIS_MODULE) so it will be [drm] > > > or e.g. [i915] for the Intel driver. Later we might consider removing > > > the prefix altogether considering that the dynamic debug control > > > interface has a way of optionally adding the module, function or line to > > > the formatting of messages. > > > > > > v2: > > > Add categories to format like "[drm][kms] No FB found" > > > Only single conditional call per message (macros expand to less code) > > > Uses __dynamic_pr_debug/dev_dbg for dynamic formatting features > > > Use module name for msg prefix like [drm] or [i915] > > > > > > Signed-off-by: Robert Bragg > > > Cc: dri-de...@lists.freedesktop.org > > > Cc: Daniel Vetter > > > Cc: Tvrtko Ursulin > > > > So assuming I understand it correctly - I like this 3way cascade of > > dynamic debug, then printk and no_printk fallback if CONFIG_DEBUG=n for > > the space concious. But I guess we do need to add a DRM Kconfig knob to > > set DEBUG, at least I'm not entirely sure how that's supposed to work. Or > > we might need to have our own #ifdef maze for this. Maybe we need to keep > > the old drm*printk stuff for that? > > Right, I wasn't really sure who/what's responsible for defining DEBUG. > > I just found this convention documented in Documentation/CodingStyle: > > > Coming up with good debugging messages can be quite a challenge; and once > > you have them, they can be a huge help for remote troubleshooting. However > > debug message printing is handled differently than printing other non-debug > > messages. While the other pr_XXX()
Re: [Intel-gfx] [PATCH] drm: Take ownership of the dmabuf->obj when exporting
On Thu, Dec 08, 2016 at 03:03:29PM +0200, Joonas Lahtinen wrote: > On ke, 2016-12-07 at 21:45 +, Chris Wilson wrote: > > Currently the reference for the dmabuf->obj is incremented for the > > dmabuf in drm_gem_prime_handle_to_fd() (at the high level userspace > > interface), but is released in drm_gem_dmabuf_release() (the lowlevel > > handler). Improve the symmetry of the dmabuf->obj ownership by acquiring > > the reference in drm_gem_dmabuf_export(). This makes it easier to use > > the prime functions directly. > > > > Signed-off-by: Chris Wilson > > Reviewed-by: Joonas Lahtinen Sorry forgot to reply here that I merged this, after some discussion with Chris on irc to make sure the kerneldoc is updated. -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 6/6] drm/i915: Add a cursor hack to allow converting legacy page flip to atomic.
On 8 December 2016 at 13:45, Maarten Lankhorst
wrote:
> Do something similar to vc4, only allow updating the cursor state
> in-place through a fastpath when the watermarks are unaffected. This
> will allow cursor movement to be smooth, but changing cursor size or
> showing/hiding cursor will still fall back so watermarks can be updated.
>
> Only moving and changing fb is allowed.
>
> Changes since v1:
> - Set page flip to always_unused for trybot.
> - Copy fence correctly, ignore plane_state->state, should be NULL.
> - Check crtc_state for !active and modeset, go to slowpath if the case.
>
> Signed-off-by: Maarten Lankhorst
> Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 47 +++-
> drivers/gpu/drm/i915/intel_display.c | 123
> +-
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> 3 files changed, 153 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index dbe9fb41ae53..60d75ce8a989 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -103,36 +103,24 @@ intel_plane_destroy_state(struct drm_plane *plane,
> drm_atomic_helper_plane_destroy_state(plane, state);
> }
>
> -static int intel_plane_atomic_check(struct drm_plane *plane,
> - struct drm_plane_state *state)
> +int intel_plane_atomic_check_with_state(struct intel_crtc_state *crtc_state,
> + struct intel_plane_state *intel_state)
> {
> + struct drm_plane *plane = intel_state->base.plane;
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> - struct drm_crtc *crtc = state->crtc;
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc_state *crtc_state;
> + struct drm_plane_state *state = &intel_state->base;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> - struct intel_plane_state *intel_state = to_intel_plane_state(state);
> - struct drm_crtc_state *drm_crtc_state;
> int ret;
>
> - crtc = crtc ? crtc : plane->state->crtc;
> - intel_crtc = to_intel_crtc(crtc);
> -
> /*
> * Both crtc and plane->crtc could be NULL if we're updating a
> * property while the plane is disabled. We don't actually have
> * anything driver-specific we need to test in that case, so
> * just return success.
> */
> - if (!crtc)
> + if (!intel_state->base.crtc && !plane->state->crtc)
> return 0;
>
> - drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> crtc);
> - if (WARN_ON(!drm_crtc_state))
> - return -EINVAL;
> -
> - crtc_state = to_intel_crtc_state(drm_crtc_state);
> -
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> @@ -184,6 +172,31 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> return intel_plane_atomic_calc_changes(&crtc_state->base, state);
> }
>
> +static int intel_plane_atomic_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_crtc_state *drm_crtc_state;
> +
> + crtc = crtc ? crtc : plane->state->crtc;
> +
> + /*
> +* Both crtc and plane->crtc could be NULL if we're updating a
> +* property while the plane is disabled. We don't actually have
> +* anything driver-specific we need to test in that case, so
> +* just return success.
> +*/
> + if (!crtc)
> + return 0;
> +
> + drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> crtc);
> + if (WARN_ON(!drm_crtc_state))
> + return -EINVAL;
> +
> + return
> intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
> +
> to_intel_plane_state(state));
> +}
> +
> static void intel_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9eaf1e5bdae9..a8b8663ecda7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15028,6 +15029,124 @@ const struct drm_plane_funcs intel_plane_funcs = {
> .atomic_destroy_state = intel_plane_destroy_state,
> };
>
> +static int
> +intel_legacy_cursor_update(struct drm_plane *plane,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> +
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Generate all IS_ macros
On 08/12/2016 14:00, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
On 08/12/2016 13:37, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
On 08/12/2016 10:46, Jani Nikula wrote:
On Thu, 08 Dec 2016, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Instead of listing them individually we can generate them
using the new i915_platforms.h header.
Also convert them to a static inline function which
interestingly makes the code smaller as well.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
NAK. Absolutely opposed to this.
Gee, sounds a bit to harsh to me. :) Didn't we say we are not doing NAKs
any longer?
Only when dropped without rationale. I needed to make it clear in no
uncertain terms how important this is to me.
Hm ok, I'll give you a benefit of doubt here.
Thanks; I hope you've observed I don't use it lightly.
A large part of my work involves digging through the source tree, and a
crucial part of that is looking up definitions and references, both for
macros and functions. Not having the macro/function definitions breaks
that workflow. Losing that, source code archeology gets *much*
harder. The losses are much greater than the gains.
Hm, I struggle to see that point on the same magnitude of a disaster
scale as you. I would have thought we all know what IS_SKYLAKE & co are
so it would be no big deal.
Sure we know what they are; I want to be able to see all the
*references* to them as well, using GNU global. That fails if they're
not defined in the first place. And no, git grep is not the same.
Imagine if we changed it to IS_PLATFORM(SKYLAKE) for instance.
Then all the things passed as parameter would have to be defined.
They are already -> enum intel_platform?!
See the other mail; they'd have to be defined directly (as they
currently are in git) instead of via macros (as in patch 1).
Hmm, how about
static inline bool intel_is_platform(const struct drm_i915_private *dev_priv,
enum intel_platform platform)
{
return dev_priv->info.platform == platform;
}
and doing
#define IS_FOO(dev_priv) intel_is_platform(dev_priv, INTEL_FOO)
manually for the ones we actually use (we don't need them all)? If the
function is inline, I don't see how defining N similar functions instead
of passing in the parameter would be more efficient. And you could still
do the optimizations of patchs 3/3 AFAICS.
Suitable compromise?
Yes, in fact, I was already half way through typing that when this
e-mail arrived.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Respect ring_mask and num_pipes when install IRQ
== Series Details == Series: drm/i915: Respect ring_mask and num_pipes when install IRQ URL : https://patchwork.freedesktop.org/series/16547/ State : success == Summary == Series 16547v1 drm/i915: Respect ring_mask and num_pipes when install IRQ https://patchwork.freedesktop.org/api/1.0/series/16547/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-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 24cc1f39920c0caf747c6bda267ca19b99f21786 drm-tip: 2016y-12m-08d-12h-31m-59s UTC integration manifest 248ffa7 drm/i915: Respect ring_mask and num_pipes when install IRQ == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3236/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On to, 2016-12-08 at 14:02 +, Chris Wilson wrote:
> On Mon, Dec 05, 2016 at 06:27:37PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> > SKL
> >
> > increased the timeout to match the spec, but we still see a timeout on
> > at least one SKL. A CDCLK change request following the failed one will
> > succeed nevertheless.
> >
> > I could reproduce this problem easily by running kms_pipe_crc_basic in a
> > loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
> > the worst case - when the pre-emption happened right after calculating
> > timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
> > once which failed and so _wait_for() timed out. As opposed to this the
> > spec says to keep retrying the request for at most a 3ms period.
> >
> > To fix this send the first request explicitly to guarantee that there is
> > 3ms between the first and last request. Though this matches the spec, I
> > noticed that in rare cases this can still time out if we sent only a few
> > requests (in the worst case 2) _and_ PCODE is busy for some reason even
> > after a previous request and a 3ms delay. To work around this retry the
> > polling with pre-emption disabled to maximize the number of requests.
> > Also increase the timeout to 10ms to account for interrupts that could
> > reduce the number of requests. With this change I couldn't trigger
> > the problem.
> >
> > v2:
> > - Use 1ms poll period instead of 10us. (Chris)
> > v3:
> > - Poll with pre-emption disabled to increase the number of request
> > attempts. (Ville, Chris)
> > - Factor out a helper to poll, it's also needed by the next patch.
> > v4:
> > - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
> > reply is generic. (Ville)
> > v5:
> > - List the request specific timeout values as code comment. (Ville)
> > v6:
> > - Try the poll first with preemption enabled.
> > - Add code comment about first request being queued by PCODE. (Art)
> > - Add timeout_base_ms argument. (Ville)
> >
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Cc: Art Runyan
> > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
> > Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
> > Signed-off-by: Imre Deak
>
> The only issue I have is that buried within snb_pcode_read() is another
> wait_for, now in an atomic section and we have been trying to erradicate
> those. It should be happy enough, just a pita to fix later!
Yea, agreed with the rational for that. I can volunteer to refactor
this part as a follow-up, although passing a flag to snb_pcode_read()
would be still the clearest to me.
Btw, this is also for -stable imo.
> Other than that and a minor nit, it looks like a reasonable compromise.
> Reviewed-by: Chris Wilson
>
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/intel_display.c | 31 +--
> > drivers/gpu/drm/i915/intel_pm.c | 75
> >
> > 3 files changed, 87 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index ca9786c..a2462bf 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3597,6 +3597,8 @@ extern void intel_display_print_error_state(struct
> > drm_i915_error_state_buf *e,
> >
> > int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 *val);
> > int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox,
> > u32 val);
> > +int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32
> > request,
> > + u32 reply_mask, u32 reply, int timeout_base_ms);
> >
> > /* intel_sideband.c */
> > u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 1fafcce..4ef7392 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6280,35 +6280,24 @@ skl_dpll0_disable(struct drm_i915_private *dev_priv)
> > dev_priv->cdclk_pll.vco = 0;
> > }
> >
> > -static bool skl_cdclk_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - int ret;
> > - u32 val;
> > -
> > - /* inform PCU we want to change CDCLK */
> > - val = SKL_CDCLK_PREPARE_FOR_CHANGE;
> > - mutex_lock(&dev_priv->rps.hw_lock);
> > - ret = sandybridge_pcode_read(dev_priv, SKL_PCODE_CDCLK_CONTROL, &val);
> > - mutex_unlock(&dev_priv->rps.hw_lock);
> > -
> > - return ret == 0 && (val & SKL_CDCLK_READY_FOR_CHANGE);
> > -}
> > -
> > -static bool skl_cdclk_wait_for_pcu_ready(struct drm_i915_private *dev_priv)
> > -{
> > - return _wait_for(skl_cdclk_pcu_ready(dev_priv), 3000, 10) == 0;
> > -}
> > -
> >
Re: [Intel-gfx] [PATCH 11/11] drm/i915: Kill the 830 MI_OVERLAY_OFF workaround
Hi Ville,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20161208]
[cannot apply to v4.9-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/ville-syrjala-linux-intel-com/drm-i915-Overlay-fixes/20161208-060045
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a0-12081851 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_overlay.c: In function 'intel_overlay_off':
>> drivers/gpu/drm/i915/intel_overlay.c:409: warning: unused variable 'dev_priv'
vim +/dev_priv +409 drivers/gpu/drm/i915/intel_overlay.c
71f85de3 Ville Syrjälä 2016-12-07 393 container_of(active,
typeof(*overlay), last_flip);
18cb592b Ville Syrjälä 2016-12-07 394 struct drm_i915_private
*dev_priv = overlay->i915;
71f85de3 Ville Syrjälä 2016-12-07 395
71f85de3 Ville Syrjälä 2016-12-07 396
intel_overlay_release_old_vma(overlay);
03f77ea5 Daniel Vetter 2009-09-15 397
b303cf95 Chris Wilson 2010-08-12 398 overlay->crtc->overlay = NULL;
b303cf95 Chris Wilson 2010-08-12 399 overlay->crtc = NULL;
209c2a5e Ville Syrjälä 2015-03-31 400 overlay->active = false;
18cb592b Ville Syrjälä 2016-12-07 401
18cb592b Ville Syrjälä 2016-12-07 402 if (IS_I830(dev_priv))
18cb592b Ville Syrjälä 2016-12-07 403
i830_overlay_clock_gating(dev_priv, true);
02e792fb Daniel Vetter 2009-09-15 404 }
02e792fb Daniel Vetter 2009-09-15 405
02e792fb Daniel Vetter 2009-09-15 406 /* overlay needs to be disabled in OCMD
reg */
ce453d81 Chris Wilson 2011-02-21 407 static int intel_overlay_off(struct
intel_overlay *overlay)
02e792fb Daniel Vetter 2009-09-15 408 {
1ee8da6d Chris Wilson 2016-05-12 @409 struct drm_i915_private
*dev_priv = overlay->i915;
dad540ce John Harrison 2015-05-29 410 struct drm_i915_gem_request
*req;
7e37f889 Chris Wilson 2016-08-02 411 struct intel_ring *ring;
8dc5d147 Chris Wilson 2010-08-12 412 u32 flip_addr =
overlay->flip_addr;
e1f99ce6 Chris Wilson 2010-10-27 413 int ret;
02e792fb Daniel Vetter 2009-09-15 414
77589f56 Ville Syrjälä 2015-03-31 415 WARN_ON(!overlay->active);
02e792fb Daniel Vetter 2009-09-15 416
02e792fb Daniel Vetter 2009-09-15 417 /* According to intel docs the
overlay hw may hang (when switching
:: The code at line 409 was first introduced by commit
:: 1ee8da6df17dc481948aa2d04005e87bc7d387a4 drm/i915: Convert
intel_overlay.c to use native drm_i915_private pointers
:: TO: Chris Wilson
:: CC: Chris Wilson
---
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
Re: [Intel-gfx] [PATCH v6 1/2] drm/i915/gen9: Fix PCODE polling during CDCLK change notification
On Thu, Dec 08, 2016 at 04:18:50PM +0200, Imre Deak wrote: > Yep. Btw, I also pondered if we could just make this part of > wait_for(), but not sure if we want the corresponding code increase > (and for -stable we'd want a minimal diff). It's not required in other > cases, although it could speed up the wait in some cases. AFAIR Ville > did some measurements on this. The majority use intel_wait_for_register() which includes the spin then sleep (i.e. a double wait_for()) as suggested by Ville. -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] [CI] drm/i915: Reorder phys backing storage release
In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I
reordered the object->pages teardown to be more friendly wrt to a
separate obj->mm.lock. However, I overlooked the phys object and left it
with a dangling use-after-free of its phys_handle. Move the allocation
of the phys handle to get_pages and it release to put_pages to prevent
the invalid access and to improve symmetry.
v2: Add commentary about always aligning to page size.
Testcase: igt/drv_selftest/objects
Reported-by: Ville Syrjälä
Fixes: a4f5ea64f0a8 ("drm/i915: Refactor object page API")
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem.c | 53 ++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 36183945e61a..b3660339fa6b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -176,21 +176,35 @@ static struct sg_table *
i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
{
struct address_space *mapping = obj->base.filp->f_mapping;
- char *vaddr = obj->phys_handle->vaddr;
+ drm_dma_handle_t *phys;
struct sg_table *st;
struct scatterlist *sg;
+ char *vaddr;
int i;
if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
return ERR_PTR(-EINVAL);
+ /* Always aligning to the object size, allows a single allocation
+* to handle all possible callers, and given typical object sizes,
+* the alignment of the buddy allocation will naturally match.
+*/
+ phys = drm_pci_alloc(obj->base.dev,
+obj->base.size,
+roundup_pow_of_two(obj->base.size));
+ if (!phys)
+ return ERR_PTR(-ENOMEM);
+
+ vaddr = phys->vaddr;
for (i = 0; i < obj->base.size / PAGE_SIZE; i++) {
struct page *page;
char *src;
page = shmem_read_mapping_page(mapping, i);
- if (IS_ERR(page))
- return ERR_CAST(page);
+ if (IS_ERR(page)) {
+ st = ERR_CAST(page);
+ goto err_phys;
+ }
src = kmap_atomic(page);
memcpy(vaddr, src, PAGE_SIZE);
@@ -204,21 +218,29 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object
*obj)
i915_gem_chipset_flush(to_i915(obj->base.dev));
st = kmalloc(sizeof(*st), GFP_KERNEL);
- if (st == NULL)
- return ERR_PTR(-ENOMEM);
+ if (st == NULL) {
+ st = ERR_PTR(-ENOMEM);
+ goto err_phys;
+ }
if (sg_alloc_table(st, 1, GFP_KERNEL)) {
kfree(st);
- return ERR_PTR(-ENOMEM);
+ st = ERR_PTR(-ENOMEM);
+ goto err_phys;
}
sg = st->sgl;
sg->offset = 0;
sg->length = obj->base.size;
- sg_dma_address(sg) = obj->phys_handle->busaddr;
+ sg_dma_address(sg) = phys->busaddr;
sg_dma_len(sg) = obj->base.size;
+ obj->phys_handle = phys;
+ return st;
+
+err_phys:
+ drm_pci_free(obj->base.dev, phys);
return st;
}
@@ -274,12 +296,13 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object
*obj,
sg_free_table(pages);
kfree(pages);
+
+ drm_pci_free(obj->base.dev, obj->phys_handle);
}
static void
i915_gem_object_release_phys(struct drm_i915_gem_object *obj)
{
- drm_pci_free(obj->base.dev, obj->phys_handle);
i915_gem_object_unpin_pages(obj);
}
@@ -540,15 +563,13 @@ int
i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align)
{
- drm_dma_handle_t *phys;
int ret;
- if (obj->phys_handle) {
- if ((unsigned long)obj->phys_handle->vaddr & (align -1))
- return -EBUSY;
+ if (align > obj->base.size)
+ return -EINVAL;
+ if (obj->ops == &i915_gem_phys_ops)
return 0;
- }
if (obj->mm.madv != I915_MADV_WILLNEED)
return -EFAULT;
@@ -564,12 +585,6 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object
*obj,
if (obj->mm.pages)
return -EBUSY;
- /* create a new object */
- phys = drm_pci_alloc(obj->base.dev, obj->base.size, align);
- if (!phys)
- return -ENOMEM;
-
- obj->phys_handle = phys;
obj->ops = &i915_gem_phys_ops;
return i915_gem_object_pin_pages(obj);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Don't print an error if the checksum of a CEA block is wrong
== Series Details == Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong URL : https://patchwork.freedesktop.org/series/16556/ State : warning == Summary == Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block is wrong https://patchwork.freedesktop.org/api/1.0/series/16556/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-skl-6770hq) 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:233 dwarn:1 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 24cc1f39920c0caf747c6bda267ca19b99f21786 drm-tip: 2016y-12m-08d-12h-31m-59s UTC integration manifest 471fc5b drm/edid: Don't print an error if the checksum of a CEA block is wrong == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3237/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status
On Tue, 06 Dec 2016, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical capabilities of
> the link, but it's possible we can't reach this in practice. The DP
> spec describes how the link should be reduced, but we can't reduce
> the link below the requirements of the mode. Black screen follows.
>
> One idea would be to have setcrtc return a failure. However, it
> already should not fail as the atomic checks have passed. It would
> also conflict with the idea of making setcrtc asynchronous in the
> future, returning before the actual mode setting and link training.
>
> Another idea is to train the link "upfront" at hotplug time, before
> pruning the mode list, so that we can do the pruning based on
> practical not theoretical capabilities. However, the changes for link
> training are pretty drastic, all for the sake of error handling and
> DP compliance, when the most common happy day scenario is the current
> approach of link training at mode setting time, using the optimal
> parameters for the mode. It is also not certain all hardware could do
> this without the pipe on; not even all our hardware can do this. Some
> of this can be solved, but not trivially.
>
> Both of the above ideas also fail to address link degradation *during*
> operation.
>
> The solution is to add a new "link-status" connector property in order
> to address link training failure in a way that:
> a) changes the current happy day scenario as little as possible, to
> avoid regressions, b) can be implemented the same way by all drm
> drivers, c) is still opt-in for the drivers and userspace, and opting
> out doesn't regress the user experience, d) doesn't prevent drivers
> from implementing better or alternate approaches, possibly without
> userspace involvement. And, of course, handles all the issues presented.
> In the usual happy day scenario, this is always "good". If something
> fails during or after a mode set, the kernel driver can set the link
> status to "bad" and issue a hotplug uevent for userspace to have it
> re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> again. If the theoretical capabilities of the link can't be reached,
> the mode list is trimmed based on that.
>
> v4:
> * Add comments in kernel-doc format (Daniel Vetter)
> * Update the kernel-doc for link-status (Sean Paul)
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
>
> Reviewed-by: Sean Paul
> Reviewed-by: Daniel Vetter
> Acked-by: Tony Cheng
> Acked-by: Harry Wentland
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic.c| 10 +++
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> drivers/gpu/drm/drm_connector.c | 53
> +
> include/drm/drm_connector.h | 19 +
> include/drm/drm_mode_config.h | 5
> include/uapi/drm/drm_mode.h | 4 +++
> 6 files changed, 106 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 19d7bcb..70a5152 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>* now?) atomic writes to DPMS property:
>*/
> return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> + * only hw issues can do that.
> + */
> + if (state->link_status == DRM_LINK_STATUS_GOOD)
> + return 0;
Is it conceivable we'd want to support the userspace requesting the
change from GOOD to BAD at a later point in time? If yes, perhaps the
right answer here is to return an error on GOOD->BAD transition, so the
userspace can distinguish between the kernel rejecting vs. accepting the
property set?
BR,
Jani.
> + state->link_status = val;
> + return 0;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct
> drm_printer *p,
> *val = (state->crtc) ? state->crtc->base.id : 0;
> } else if (property == config->dpms_property) {
> *va
[Intel-gfx] ✗ Fi.CI.BAT: warning for Claw back the IS_ optimisation (rev2)
== Series Details == Series: Claw back the IS_ optimisation (rev2) URL : https://patchwork.freedesktop.org/series/16544/ State : warning == Summary == Series 16544v2 Claw back the IS_ optimisation https://patchwork.freedesktop.org/api/1.0/series/16544/revisions/2/mbox/ Test drv_module_reload: Subgroup basic-reload: pass -> DMESG-WARN (fi-hsw-4770r) pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-n2820) pass -> DMESG-WARN (fi-ilk-650) pass -> DMESG-WARN (fi-byt-j1900) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-bsw-n3050) pass -> DMESG-WARN (fi-ivb-3520m) pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-hsw-4770) pass -> DMESG-WARN (fi-bdw-5557u) pass -> DMESG-WARN (fi-skl-6700hq) Subgroup basic-reload-final: pass -> DMESG-WARN (fi-hsw-4770r) pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-n2820) pass -> DMESG-WARN (fi-ilk-650) pass -> DMESG-WARN (fi-byt-j1900) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-bsw-n3050) pass -> DMESG-WARN (fi-ivb-3520m) pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-hsw-4770) pass -> DMESG-WARN (fi-bdw-5557u) pass -> DMESG-WARN (fi-skl-6700hq) Subgroup basic-reload-inject: pass -> DMESG-WARN (fi-hsw-4770r) pass -> DMESG-WARN (fi-snb-2520m) pass -> DMESG-WARN (fi-skl-6260u) pass -> DMESG-WARN (fi-ivb-3770) pass -> DMESG-WARN (fi-byt-n2820) pass -> DMESG-WARN (fi-ilk-650) pass -> DMESG-WARN (fi-byt-j1900) pass -> DMESG-WARN (fi-kbl-7500u) pass -> DMESG-WARN (fi-bsw-n3050) pass -> DMESG-WARN (fi-ivb-3520m) pass -> DMESG-WARN (fi-snb-2600) pass -> DMESG-WARN (fi-skl-6770hq) pass -> DMESG-WARN (fi-hsw-4770) pass -> DMESG-WARN (fi-bdw-5557u) pass -> DMESG-WARN (fi-skl-6700hq) fi-bdw-5557u total:247 pass:230 dwarn:3 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:205 dwarn:3 dfail:0 fail:0 skip:39 fi-byt-j1900 total:247 pass:217 dwarn:3 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:213 dwarn:3 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:225 dwarn:3 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:225 dwarn:3 dfail:0 fail:0 skip:19 fi-ilk-650 total:247 pass:192 dwarn:3 dfail:0 fail:0 skip:52 fi-ivb-3520m total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:223 dwarn:3 dfail:0 fail:0 skip:21 fi-skl-6260u total:247 pass:231 dwarn:3 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:224 dwarn:3 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:231 dwarn:3 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:213 dwarn:3 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:212 dwarn:3 dfail:0 fail:0 skip:32 24cc1f39920c0caf747c6bda267ca19b99f21786 drm-tip: 2016y-12m-08d-12h-31m-59s UTC integration manifest ab139b1 drm/i915: Number the platform enum strategically e2a3c06 drm/i915: Generate all IS_ macros db53ca9 drm/i915: Introduct i915_platforms.h == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3238/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/4] drm: Add a new connector atomic property for link status
On Thu, Dec 08, 2016 at 05:05:54PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's possible we can't reach this in practice. The DP
> > spec describes how the link should be reduced, but we can't reduce
> > the link below the requirements of the mode. Black screen follows.
> >
> > One idea would be to have setcrtc return a failure. However, it
> > already should not fail as the atomic checks have passed. It would
> > also conflict with the idea of making setcrtc asynchronous in the
> > future, returning before the actual mode setting and link training.
> >
> > Another idea is to train the link "upfront" at hotplug time, before
> > pruning the mode list, so that we can do the pruning based on
> > practical not theoretical capabilities. However, the changes for link
> > training are pretty drastic, all for the sake of error handling and
> > DP compliance, when the most common happy day scenario is the current
> > approach of link training at mode setting time, using the optimal
> > parameters for the mode. It is also not certain all hardware could do
> > this without the pipe on; not even all our hardware can do this. Some
> > of this can be solved, but not trivially.
> >
> > Both of the above ideas also fail to address link degradation *during*
> > operation.
> >
> > The solution is to add a new "link-status" connector property in order
> > to address link training failure in a way that:
> > a) changes the current happy day scenario as little as possible, to
> > avoid regressions, b) can be implemented the same way by all drm
> > drivers, c) is still opt-in for the drivers and userspace, and opting
> > out doesn't regress the user experience, d) doesn't prevent drivers
> > from implementing better or alternate approaches, possibly without
> > userspace involvement. And, of course, handles all the issues presented.
> > In the usual happy day scenario, this is always "good". If something
> > fails during or after a mode set, the kernel driver can set the link
> > status to "bad" and issue a hotplug uevent for userspace to have it
> > re-check the valid modes through GET_CONNECTOR IOCTL, and try modeset
> > again. If the theoretical capabilities of the link can't be reached,
> > the mode list is trimmed based on that.
> >
> > v4:
> > * Add comments in kernel-doc format (Daniel Vetter)
> > * Update the kernel-doc for link-status (Sean Paul)
> > v3:
> > * Fixed a build error (Jani Saarinen)
> > v2:
> > * Removed connector->link_status (Daniel Vetter)
> > * Set connector->state->link_status in
> > drm_mode_connector_set_link_status_property
> > (Daniel Vetter)
> > * Set the connector_changed flag to true if connector->state->link_status
> > changed.
> > * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> > * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> >
> > Reviewed-by: Sean Paul
> > Reviewed-by: Daniel Vetter
> > Acked-by: Tony Cheng
> > Acked-by: Harry Wentland
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Cc: Chris Wilson
> > Cc: Sean Paul
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic.c| 10 +++
> > drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> > drivers/gpu/drm/drm_connector.c | 53
> > +
> > include/drm/drm_connector.h | 19 +
> > include/drm/drm_mode_config.h | 5
> > include/uapi/drm/drm_mode.h | 4 +++
> > 6 files changed, 106 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 19d7bcb..70a5152 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct
> > drm_connector *connector,
> > * now?) atomic writes to DPMS property:
> > */
> > return -EINVAL;
> > + } else if (property == config->link_status_property) {
> > + /* Never downgrade from GOOD to BAD on userspace's request here,
> > +* only hw issues can do that.
> > +*/
> > + if (state->link_status == DRM_LINK_STATUS_GOOD)
> > + return 0;
>
> Is it conceivable we'd want to support the userspace requesting the
> change from GOOD to BAD at a later point in time? If yes, perhaps the
> right answer here is to return an error on GOOD->BAD transition, so the
> userspace can distinguish between the kernel rejecting vs. accepting the
> property set?
One of the design ideas behind atomic is that userspace doesn't need to be
able to understand all properties, but still needs to be able to restore
the state it wants on VT switch. Or as a "pls reset my display to boot-up
state because my compositor made a mess of it
Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support
On Mon, Dec 05, 2016 at 12:42:11PM -0800, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> >Sent: Thursday, December 1, 2016 5:11 AM
> >To: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading
> >Support
> >
> >
> >On 30/11/2016 23:31, Anusha Srivatsa wrote:
> >> This patch adds the HuC Loading for the BXT by using the updated file
> >> construction.
> >>
> >> Version 1.7 of the HuC firmware.
> >>
> >> v2: rebased.
> >> v3: rebased on top of drm-tip
> >>
> >> Cc: Jeff Mcgee
> >> Signed-off-by: Anusha Srivatsa
> >> Reviewed-by: Jeff McGee
> >> ---
> >> drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
> >> b/drivers/gpu/drm/i915/intel_huc_loader.c
> >> index 663fcc4..6357c19 100644
> >> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> >> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> >> @@ -40,6 +40,10 @@
> >> * Note that HuC firmware loading must be done before GuC loading.
> >> */
> >>
> >> +#define BXT_FW_MAJOR 01
> >> +#define BXT_FW_MINOR 07
> >> +#define BXT_BLD_NUM 1398
> >> +
> >> #define SKL_FW_MAJOR 01
> >> #define SKL_FW_MINOR 07
> >> #define SKL_BLD_NUM 1398
> >> @@ -52,6 +56,9 @@
> >>SKL_FW_MINOR, SKL_BLD_NUM)
> >> MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
> >>
> >> +#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
> >> + BXT_FW_MINOR, BXT_BLD_NUM)
> >> +MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
> >> /**
> >> * huc_ucode_xfer() - DMA's the firmware
> >> * @dev_priv: the drm device
> >> @@ -159,6 +166,10 @@ void intel_huc_init(struct drm_device *dev)
> >>fw_path = I915_SKL_HUC_UCODE;
> >>huc_fw->major_ver_wanted = SKL_FW_MAJOR;
> >>huc_fw->minor_ver_wanted = SKL_FW_MINOR;
> >> + } else if (IS_BROXTON(dev_priv)) {
> >> + fw_path = I915_BXT_HUC_UCODE;
> >> + huc_fw->major_ver_wanted = BXT_FW_MAJOR;
> >> + huc_fw->minor_ver_wanted = BXT_FW_MINOR;
> >>}
> >>
> >>huc_fw->uc_fw_path = fw_path;
> >>
> >
> >Build number in the file name still worries me. Last time I've asked about
> >it the
> >thread kind of died off so I will re-state it.
> >
> >My concern is that if we will be getting firmware releases with the same
> >major-
> >minor but different build numbers, then embedding the build number into the
> >driver prevents loading of a newer firmware unless the kernel is also
> >updated.
> >
> >I am not sure if that is what we want. Perhaps it is not expected at all
> >that will
> >happen in production so it is not a concern?
> >
> >Or if it could happen, perhaps we should either push back on the scheme
> >- drop the build number and bump the minor in all cases, or alternatively
> >for our
> >purposes drop the build number from the driver and have a symlinked scheme on
> >disk?
> >
> >Regards,
> >
> >Tvrtko
>
> Hi Tvrtko,
> Sincere apologies for responding so late. According to my understanding, Jeff
> correct me if I am wrong, we are finalizing the firmware version number for
> every kernel version. So a certain kernel will have only one possible firware
> major-minor and build number for a certain platform.
>
> I have cc-ed Jeff in this thread so he can add his comment on build number.
> Jeff, any comments?
>
> Regards,
> Anusha
Sorry for delayed response. I'm checking with HuC firmware team on their
intended release model.
-Jeff
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/atomic: Use active instead of enable in wait_for_vblanks.
On Thu, Dec 08, 2016 at 02:45:24PM +0100, Maarten Lankhorst wrote: > When DPMS was introduced to atomic, vblanks only worked when the crtc > was enabled and active. wait_for_vblanks were not converted to check for > crtc_state->active, which may cause an attempt for vblank_get to fail. > > This is probably harmless, but convert from enable to active anyway. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 583f47f27b36..23767df72615 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1117,7 +1117,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device > *dev, >* vblank wait) in the ->enable boolean. */ > old_crtc_state->enable = false; > > - if (!crtc->state->enable) > + if (!crtc->state->active) Hm, with this change we /should/ be able to make the drm_crtc_vblank_get call a few lines below WARN when it fails. Not doing that was only done at first because there was no accurate active state tracking for the CRTC, and since the vblank state should match active I've used that. Care for that follow-up patch? Applied this one here meanwhile. -Daniel > continue; > > /* Legacy cursor ioctls are completely unsynced, and userspace > -- > 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 3/6] drm/atomic: Clean up wait_for_vblanks
On Thu, Dec 08, 2016 at 02:45:26PM +0100, Maarten Lankhorst wrote:
> Stop relying on a per crtc_state last_vblank_count, we know in advance
> how many there can be. Also stop re-using new_crtc_state->enable,
> we can now simply set a bitmask with crtc_crtc_mask.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 29 +++--
> include/drm/drm_crtc.h | 5 -
> 2 files changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d19563651e07..ccf0bed9bf4a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1110,19 +1110,20 @@ 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;
> + unsigned last_vblank_count[dev->mode_config.num_crtc];
I think putting last_vblank_count into
drm_atomic_state->crtcs.last_vblank_count would be nice(r). At least I
always freak out when we have dynamically sized arrays on the stack ;-)
> +
> + /*
> + * Legacy cursor ioctls are completely unsynced, and userspace
> + * relies on that (by doing tons of cursor updates).
> + */
> + if (old_state->legacy_cursor_update)
> + return;
>
> 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;
> -
> - if (!crtc->state->active)
> - continue;
> + 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 +1134,16 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> if (ret != 0)
> continue;
if (WARN_ON(ret != 0))
continue;
... is the WARN_ON I meant in patch 1. Would be good to do that too while
we're at it.
-Daniel
>
> - old_crtc_state->enable = true;
> - old_crtc_state->last_vblank_count = drm_crtc_vblank_count(crtc);
> + crtc_mask |= drm_crtc_mask(crtc);
> + last_vblank_count[i] = 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 !=
> + last_vblank_count[i] !=
> drm_crtc_vblank_count(crtc),
> msecs_to_jiffies(50));
>
> 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;
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/6] drm/atomic: Unconditionally call prepare_fb.
On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> Atomic drivers may set properties like rotation on the same fb, which
> may require a call to prepare_fb even when framebuffer stays identical.
>
> Instead of handling all the special cases in the core, let the driver
> decide when prepare_fb and cleanup_fb are noops.
>
> Signed-off-by: Maarten Lankhorst
I think this makes sense, but would be really good to get a pile of acks
from driver maintainers on this one. Rob, Eric, Laurent, others?
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 23767df72615..d19563651e07 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
>
> funcs = plane->helper_private;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc))
> - continue;
> -
> if (funcs->prepare_fb) {
> ret = funcs->prepare_fb(plane, plane_state);
> if (ret)
> @@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
> if (j >= i)
> continue;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc))
> - continue;
> -
> funcs = plane->helper_private;
>
> if (funcs->cleanup_fb)
> @@ -1952,9 +1946,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
> *dev,
> for_each_plane_in_state(old_state, plane, plane_state, i) {
> const struct drm_plane_helper_funcs *funcs;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, old_state,
> plane_state->crtc))
> - continue;
> -
> funcs = plane->helper_private;
>
> if (funcs->cleanup_fb)
> --
> 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 4/6] drm/atomic: Wait for vblank whenever a plane is added to state.
On Thu, Dec 08, 2016 at 02:45:27PM +0100, Maarten Lankhorst wrote:
> The current api doesn't take into account that whenever properties like
> rotation or z-pos change we have to wait for vblank. To make sure
> that we wait correctly, err on the side of caution and wait whenever
> a plane is added to state.
Why do we need to wait when rotation or zpos has changed? I'm a bit lost
... So rotation makes sense since often that means a special, rotated
mapping (or a different offset on omap's TILER as a different example).
But z-pos I have no idad why that matters.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ccf0bed9bf4a..fdeaea84a3b7 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1123,11 +1123,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> struct drm_crtc_state *new_crtc_state = crtc->state;
>
> - if (!new_crtc_state->active)
> - continue;
> -
> - if (!drm_atomic_helper_framebuffer_changed(dev,
> - old_state, crtc))
> + if (!new_crtc_state->active || !new_crtc_state->planes_changed)
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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] ✗ Fi.CI.BAT: warning for drm/edid: Don't print an error if the checksum of a CEA block is wrong
> == Series Details == > > Series: drm/edid: Don't print an error if the checksum of a CEA block is wrong > URL : https://patchwork.freedesktop.org/series/16556/ > State : warning > > == Summary == > > Series 16556v1 drm/edid: Don't print an error if the checksum of a CEA block > is > wrong > https://patchwork.freedesktop.org/api/1.0/series/16556/revisions/1/mbox/ > > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-a: > pass -> DMESG-WARN (fi-skl-6770hq) Still: https://bugs.freedesktop.org/show_bug.cgi?id=97929 > > 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:233 dwarn:1 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 > > 24cc1f39920c0caf747c6bda267ca19b99f21786 drm-tip: 2016y-12m-08d-12h- > 31m-59s UTC integration manifest 471fc5b drm/edid: Don't print an error if the > checksum of a CEA block is wrong > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3237/ Jani Saarinen Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Remove drm_atomic_helper_framebuffer_changed
== Series Details == Series: drm/atomic: Remove drm_atomic_helper_framebuffer_changed URL : https://patchwork.freedesktop.org/series/16561/ State : success == Summary == Series 16561v1 drm/atomic: Remove drm_atomic_helper_framebuffer_changed https://patchwork.freedesktop.org/api/1.0/series/16561/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-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 24cc1f39920c0caf747c6bda267ca19b99f21786 drm-tip: 2016y-12m-08d-12h-31m-59s UTC integration manifest d8037d4 drm/i915: Add a cursor hack to allow converting legacy page flip to atomic. b237f24 drm/atomic: Remove drm_atomic_helper_framebuffer_changed. 11c7d13 drm/atomic: Wait for vblank whenever a plane is added to state. c82f2eb drm/atomic: Clean up wait_for_vblanks 6507f92 drm/atomic: Unconditionally call prepare_fb. 212a206 drm/atomic: Use active instead of enable in wait_for_vblanks. == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3239/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: More documentation hooked to i915.rst
On Wed, Dec 07, 2016 at 09:40:33PM +, Robert Bragg wrote:
> This adds a 'Perf' section to i915.rst with the following sub sections:
> - Overview
> - Comparison with Core Perf
> - i915 Driver Entry Points
> - i915 Perf Stream
> - i915 Perf Observation Architecture Stream
> - All i915 Perf Internals
>
> v2:
> section headers in i915.rst (Daniel Vetter)
> missing symbol docs + other fixups (Matthew Auld)
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
> Cc: Daniel Vetter
Obligatory bikeshed about explicitly listening all functions, but hey
great docs, I'll merge ;-)
Thanks, applied to dinq.
-Daniel
> ---
> Documentation/gpu/i915.rst | 91 +
> drivers/gpu/drm/i915/i915_drv.h | 151 +++---
> drivers/gpu/drm/i915/i915_perf.c | 412
> ---
> 3 files changed, 598 insertions(+), 56 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 117d2ab..3843ef6 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -356,4 +356,95 @@ switch_mm
> .. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h
> :doc: switch_mm tracepoint
>
> +Perf
> +
> +
> +Overview
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :doc: i915 Perf Overview
> +
> +Comparison with Core Perf
> +-
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :doc: i915 Perf History and Comparison with Core Perf
> +
> +i915 Driver Entry Points
> +
> +
> +This section covers the entrypoints exported outside of i915_perf.c to
> +integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl.
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_init
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_fini
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_register
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_unregister
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_open_ioctl
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_release
> +
> +i915 Perf Stream
> +
> +
> +This section covers the stream-semantics-agnostic structures and functions
> +for representing an i915 perf stream FD and associated file operations.
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
> + :functions: i915_perf_stream
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
> + :functions: i915_perf_stream_ops
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: read_properties_unlocked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_open_ioctl_locked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_destroy_locked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_read
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_ioctl
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_enable_locked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_disable_locked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_poll
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_perf_poll_locked
> +
> +i915 Perf Observation Architecture Stream
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h
> + :functions: i915_oa_ops
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_stream_init
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_read
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_stream_enable
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_stream_disable
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_wait_unlocked
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :functions: i915_oa_poll_wait
> +
> +All i915 Perf Internals
> +---
> +
> +This section simply includes all currently documented i915 perf internals, in
> +no particular order, but may include some more minor utilities or platform
> +specific details than found in the more high-level sections.
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c
> + :internal:
> +
> .. WARNING: DOCPROC directive not supported:
> !Cdrivers/gpu/drm/i915/i915_irq.c
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 33758ac..49c7651 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1847,89 +1847,186 @@ struct i915_oa_reg {
>
> struct i915_perf_stream;
>
> +/**
> + * struct i915_perf_stream_ops - the OPs to support a specific stream type
> + */
> struct i915_per
Re: [Intel-gfx] [PATCH 1/2] drm/i915: split off Pineview desktop and mobile device info
On Thu, Dec 08, 2016 at 11:11:50AM +0200, Jani Nikula wrote:
> On Thu, 08 Dec 2016, Jani Nikula wrote:
> > On Thu, 08 Dec 2016, Jani Nikula wrote:
> >> This lets us use IS_MOBILE() for distinguishing the desktop and mobile
> >> parts instead of duplicating PCI IDs in Pineview specific checks.
> >
> > This probably needs more thorough review of the !IS_MOBILE() paths in
> > parts not touched by this patch.
>
> And Daniel says,
>
> 11:06 danvet j4ni, pnv is_mobile, even for the desktop version
> 11:06 danvet iirc
> 11:07 danvet because is_mobile has nothing to do with whether the
> chip is for laptops or not
>
> so better just forget about these two patches I guess.
Yeah, IS_MOBILE is seriously confusing in our code. On gen2/3 it was
essentially matching HAS_LVDS (but we never made that one), later on the
splits started to happened on different axis (atom vs big core and stuff
like that), but somehow IS_MOBILE stuck around to this day and is
sometimes abused to restrict w/a to specific chips. If someone wants to
clean this up:
- Remove IS_MOBILE on gen5+, use specific platforms/pci ids where we need
it.
- Rename IS_MOBILE to HAS_LVDS on gen2/3/4 (not entirely sure about gen4,
would need to double-check that it makes sense).
- Nuke is_mobile from the chip info, it's only misleading people. Mobile
is the future everywhere anyway ;-)
Cheers, Daniel
>
>
> BR,
> Jani.
>
>
> >
> > For example this one in i915_gem_detect_bit_6_swizzle() which was pretty
> > weird already before the Pineview device info patches:
> >
> > } else if (IS_MOBILE(dev_priv) ||
> >(IS_GEN3(dev_priv) &&
> > !IS_G33(dev_priv) && !IS_PINEVIEW(dev_priv))) {
> >
> > BR,
> > Jani.
> >
> >
> >>
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Jani Nikula
> >> ---
> >> arch/x86/kernel/early-quirks.c | 3 ++-
> >> drivers/gpu/drm/i915/i915_drv.h | 2 --
> >> drivers/gpu/drm/i915/i915_pci.c | 12 ++--
> >> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> >> include/drm/i915_pciids.h | 6 --
> >> 5 files changed, 18 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/early-quirks.c
> >> b/arch/x86/kernel/early-quirks.c
> >> index 6a08e25a48d8..34af418d88cc 100644
> >> --- a/arch/x86/kernel/early-quirks.c
> >> +++ b/arch/x86/kernel/early-quirks.c
> >> @@ -508,7 +508,8 @@ static const struct pci_device_id intel_early_ids[]
> >> __initconst = {
> >>INTEL_I945G_IDS(&gen3_early_ops),
> >>INTEL_I945GM_IDS(&gen3_early_ops),
> >>INTEL_VLV_IDS(&gen6_early_ops),
> >> - INTEL_PINEVIEW_IDS(&gen3_early_ops),
> >> + INTEL_PINEVIEW_D_IDS(&gen3_early_ops),
> >> + INTEL_PINEVIEW_M_IDS(&gen3_early_ops),
> >>INTEL_I965G_IDS(&gen3_early_ops),
> >>INTEL_G33_IDS(&gen3_early_ops),
> >>INTEL_I965GM_IDS(&gen3_early_ops),
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 1480e733312a..ee1726b28b82 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2616,8 +2616,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> >> #define IS_G45(dev_priv) ((dev_priv)->info.platform == INTEL_G45)
> >> #define IS_GM45(dev_priv) ((dev_priv)->info.platform == INTEL_GM45)
> >> #define IS_G4X(dev_priv) (IS_G45(dev_priv) || IS_GM45(dev_priv))
> >> -#define IS_PINEVIEW_G(dev_priv) (INTEL_DEVID(dev_priv) == 0xa001)
> >> -#define IS_PINEVIEW_M(dev_priv) (INTEL_DEVID(dev_priv) == 0xa011)
> >> #define IS_PINEVIEW(dev_priv) ((dev_priv)->info.platform ==
> >> INTEL_PINEVIEW)
> >> #define IS_G33(dev_priv) ((dev_priv)->info.platform == INTEL_G33)
> >> #define IS_IRONLAKE_M(dev_priv) (INTEL_DEVID(dev_priv) == 0x0046)
> >> diff --git a/drivers/gpu/drm/i915/i915_pci.c
> >> b/drivers/gpu/drm/i915/i915_pci.c
> >> index 93f50ef2a309..451113f79499 100644
> >> --- a/drivers/gpu/drm/i915/i915_pci.c
> >> +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> @@ -139,7 +139,14 @@ static const struct intel_device_info intel_g33_info
> >> = {
> >>.has_overlay = 1,
> >> };
> >>
> >> -static const struct intel_device_info intel_pineview_info = {
> >> +static const struct intel_device_info intel_pineview_d_info = {
> >> + GEN3_FEATURES,
> >> + .platform = INTEL_PINEVIEW,
> >> + .has_hotplug = 1,
> >> + .has_overlay = 1,
> >> +};
> >> +
> >> +static const struct intel_device_info intel_pineview_m_info = {
> >>GEN3_FEATURES,
> >>.platform = INTEL_PINEVIEW, .is_mobile = 1,
> >>.has_hotplug = 1,
> >> @@ -444,7 +451,8 @@ static const struct pci_device_id pciidlist[] = {
> >>INTEL_I965GM_IDS(&intel_i965gm_info),
> >>INTEL_GM45_IDS(&intel_gm45_info),
> >>INTEL_G45_IDS(&intel_g45_info),
> >> - INTEL_PINEVIEW_IDS(&intel_pineview_info),
> >> + INTEL_PINEVIEW_D_IDS(&intel_pineview_d_info),
> >> + INTEL_PINEVIEW_M_IDS(&intel_pineview_m_info),
> >>INTEL_IRONLAKE_D_IDS(&intel_ironlake_d_info),
> >>INTE
Re: [Intel-gfx] [PATCH] drm/i915: Do not reset detect_done flag in intel_dp_detect
On Wed, Dec 07, 2016 at 07:51:21PM -0800, Manasi Navare wrote: > Ville, > You mentioned that this detect_done should be set to false also > in the resume case so in i915_display_resume where it calls > intel_hpd_init that eventually schedules the hpd_poll_init_work and > calls drm_helper_hpd_irq_event() which then calls .detect(). > So in this case if I have to reset this detect_done in the > hpd_poll_init_work, how do I make sure I do it only if the > connector is DP? We have the .reset hook for these sort of things. > > Manasi > > On Wed, Dec 07, 2016 at 04:05:56PM +0200, Ville Syrjälä wrote: > > On Tue, Dec 06, 2016 at 04:43:51PM -0800, Manasi Navare wrote: > > > The detect_done flag was introduced in the commit > > > 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c in order to avoid > > > multiple detects on hotplug where intel_dp_long_pulse() > > > was called from HPD handler as well as in intel_dp_detect. > > > So this detect_done flag was required to make sure intel_dp_detect() > > > did not call long pulse handler again if it was already been called > > > from HPD handler. However commit 1015811609c0328b5ed670d07748591b837e74eb > > > differs the long hpd handling entirely until the hotplug work runs to > > > avoid the double long hpd handling the "detect_done" flag is trying > > > to prevent. > > > > That sentence doesn't parse here. Anyways, the flag indeed is now a nop > > and your patch is pretty much the same what I did here: > > https://patchwork.freedesktop.org/patch/101476/ > > > > > > > > So now we do not need to reset the detect_done flag to false in > > > intel_dp_detect. It will be reset in the intel_dp_hpd_pulse so > > > that intel_dp_detect does a full detect. However if the .detect > > > gets called during mode enumeration then we do not need to do a > > > full detect. This patch avoids the WARNS_ONS during connected boot > > > case when it calls intel_dp_check_link_status() due to multiple > > > detects > > > > How exactly does it do that? Also we shouldn't sweep that under the rug > > anyway. Instead someone should actually fix the problem that causes the > > WARN. > > > > > and also avoids DP compliance failures. It avoids doing > > > a full detect every single time on .detect(). > > > > > > Cc: Ville Syrjala > > > Cc: Daniel Vetter > > > Cc: Jani Nikula > > > Signed-off-by: Manasi Navare > > > --- > > > drivers/gpu/drm/i915/intel_dp.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > > b/drivers/gpu/drm/i915/intel_dp.c > > > index db75bb9..9c9277e 100644 > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > > @@ -4470,8 +4470,6 @@ static bool intel_digital_port_connected(struct > > > drm_i915_private *dev_priv, > > > if (!intel_dp->detect_done) > > > status = intel_dp_long_pulse(intel_dp->attached_connector); > > > > > > - intel_dp->detect_done = false; > > > - > > > return status; > > > } > > > > > > -- > > > 1.9.1 > > > > -- > > Ville Syrjälä > > Intel OTC -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC
On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote: > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > > This series implements following set of functionality > > Implement IPC WA's for Broxton/KBL > > Enable IPC in supported platforms > > Convert WM calculation to fixed point calculation > > Calculation of System memory Bandwidth for SKL/KBL/BXT > > Implementation of Arbitrated memory Bandwidth related WM WA's > > Pushed patches 1, 2, 3, 5 and 6, with small bikesheds applied. Thanks > for the patches! > > (actually I had a little problem with dim, so right now only dinq has > the patches, drm-tip doesn't, soon they will appear) Hm, what did go boom with dim? If the pushing worked, then you can re-run just the drm-tip rebuilding with $ dim rebuild-tip Might also be worth it to upgrade to latest dim, we've dropped a few bugfixes in the branch push/pull logic in a few places since the big conversion, you might hit them. If all this doesn't help, pls ping me on irc with a pastebin of what's going on. For testing you can always run $ dim pq To repush dinq - dim will complain if you'll do a non-ff push and abort, so it's safe. -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 i-g-t] igt_kms: Remove support for drivers with <1 drm_plane
On Wed, Dec 07, 2016 at 07:16:13PM -0500, Lyude wrote:
> We've had support for universal planes since kernel version 3.15, so
> there's not really a good reason to try supporting drivers that lack
> plane support now. As well, the current has_universal_planes logic is
> broken anyway as it makes the assumption that having display planes
> always means we have both a primary plane and a cursor plane (this isn't
> true on radeon/amdgpu and nouveau).
>
> So, remove this, and just check for whether or not we have a cursor
> plane.
>
> Signed-off-by: Lyude
lgtm, feel free to push.
-Daniel
> ---
> lib/igt_kms.c | 29 ++---
> lib/igt_kms.h | 2 +-
> tests/kms_crtc_background_color.c | 2 --
> tests/kms_plane_scaling.c | 1 -
> tests/kms_rotation_crc.c | 25 +
> tests/kms_universal_plane.c | 5 +
> 6 files changed, 25 insertions(+), 39 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 82bb41d..0e7b8e8 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1407,7 +1407,6 @@ void igt_display_init(igt_display_t *display, int
> drm_fd)
> plane = &pipe->planes[IGT_PLANE_PRIMARY];
> plane->is_primary = 1;
> plane->index = IGT_PLANE_PRIMARY;
> - display->has_universal_planes = 1;
> break;
> case DRM_PLANE_TYPE_CURSOR:
> /*
> @@ -1420,7 +1419,7 @@ void igt_display_init(igt_display_t *display, int
> drm_fd)
> plane = &pipe->planes[IGT_PLANE_CURSOR];
> plane->is_cursor = 1;
> plane->index = IGT_PLANE_CURSOR;
> - display->has_universal_planes = 1;
> + display->has_cursor_plane = true;
> break;
> default:
> plane = &pipe->planes[p];
> @@ -1445,35 +1444,27 @@ void igt_display_init(igt_display_t *display, int
> drm_fd)
> plane->rotation = (igt_rotation_t)prop_value;
> }
>
> - if (display->has_universal_planes) {
> - /*
> - * If we have universal planes, we should have both
> - * primary and cursor planes setup now.
> - */
> - igt_assert(pipe->planes[IGT_PLANE_PRIMARY].drm_plane &&
> -pipe->planes[IGT_PLANE_CURSOR].drm_plane);
> + /*
> + * At the bare minimum, we should expect to have a primary
> + * plane
> + */
> + igt_assert(pipe->planes[IGT_PLANE_PRIMARY].drm_plane);
>
> + if (display->has_cursor_plane) {
> /*
>* Cursor was put in the last slot. If we have 0 or
>* only 1 sprite, that's the wrong slot and we need to
>* move it down.
>*/
> if (p != IGT_PLANE_CURSOR) {
> - pipe->planes[p] =
> pipe->planes[IGT_PLANE_CURSOR];
> + pipe->planes[p] =
> + pipe->planes[IGT_PLANE_CURSOR];
> pipe->planes[p].index = p;
> memset(&pipe->planes[IGT_PLANE_CURSOR], 0,
> sizeof *plane);
> }
> } else {
> - /*
> - * No universal plane support. Add drm_plane-less
> - * primary and cursor planes.
> - */
> - plane = &pipe->planes[IGT_PLANE_PRIMARY];
> - plane->pipe = pipe;
> - plane->index = IGT_PLANE_PRIMARY;
> - plane->is_primary = true;
> -
> + /* Add drm_plane-less cursor */
> plane = &pipe->planes[p];
> plane->pipe = pipe;
> plane->index = p;
> diff --git a/lib/igt_kms.h b/lib/igt_kms.h
> index 6422adc..0dcb325 100644
> --- a/lib/igt_kms.h
> +++ b/lib/igt_kms.h
> @@ -311,7 +311,7 @@ struct igt_display {
> unsigned long pipes_in_use;
> igt_output_t *outputs;
> igt_pipe_t pipes[I915_MAX_PIPES];
> - bool has_universal_planes;
> + bool has_cursor_plane;
> bool is_atomic;
> };
>
> diff --git a/tests/kms_crtc_background_color.c
> b/tests/kms_crtc_background_color.c
> index b97c114..537d4ce 100644
> --- a/tests/kms_crtc_background_color.c
> +++ b/tests/kms_crtc_background_color.c
> @@ -131,8 +131,6 @@ static void test_crtc_background(data_t *data)
> enum pipe pipe;
> int vali
