[Intel-gfx] [PATCH] gpu: drm: i915: intel_sideband.c: Remove some unused functions
Removes some functions that are not used anywhere:
vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/i915_drv.h |6 -
drivers/gpu/drm/i915/intel_sideband.c | 44 -
2 files changed, 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 16a6f6d..d248957 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2849,23 +2849,17 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv, u8 mbox, u32 val)
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr);
void vlv_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 val);
u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
-void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg);
void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int
reg, u32 val);
u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
enum intel_sbi_destination destination);
void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
enum intel_sbi_destination destination);
-u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
int vlv_gpu_freq(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 01d841e..5939171 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -129,14 +129,6 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr)
return val;
}
-u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
-{
- u32 val = 0;
- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
- SB_CRRDDA_NP, reg, &val);
- return val;
-}
-
void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
@@ -157,34 +149,6 @@ void vlv_cck_write(struct drm_i915_private *dev_priv, u32
reg, u32 val)
SB_CRWRDA_NP, reg, &val);
}
-u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg)
-{
- u32 val = 0;
- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
- SB_CRRDDA_NP, reg, &val);
- return val;
-}
-
-void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
-{
- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
- SB_CRWRDA_NP, reg, &val);
-}
-
-u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
-{
- u32 val = 0;
- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
- SB_CRRDDA_NP, reg, &val);
- return val;
-}
-
-void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
-{
- vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
- SB_CRWRDA_NP, reg, &val);
-}
-
u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg)
{
u32 val = 0;
@@ -267,14 +231,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
}
}
-u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
-{
- u32 val = 0;
- vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
- reg, &val);
- return val;
-}
-
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
{
vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] gpu: drm: i915: intel_dp.c: Remove unused function
Remove the function intel_dp_set_drrs_state() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dp.c | 89 --
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 90 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5ad45bf..6df948b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4810,95 +4810,6 @@ intel_dp_init_panel_power_sequencer_registers(struct
drm_device *dev,
I915_READ(pp_div_reg));
}
-void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_encoder *encoder;
- struct intel_dp *intel_dp = NULL;
- struct intel_crtc_config *config = NULL;
- struct intel_crtc *intel_crtc = NULL;
- struct intel_connector *intel_connector = dev_priv->drrs.connector;
- u32 reg, val;
- enum edp_drrs_refresh_rate_type index = DRRS_HIGH_RR;
-
- if (refresh_rate <= 0) {
- DRM_DEBUG_KMS("Refresh rate should be positive non-zero.\n");
- return;
- }
-
- if (intel_connector == NULL) {
- DRM_DEBUG_KMS("DRRS supported for eDP only.\n");
- return;
- }
-
- /*
-* FIXME: This needs proper synchronization with psr state. But really
-* hard to tell without seeing the user of this function of this code.
-* Check locking and ordering once that lands.
-*/
- if (INTEL_INFO(dev)->gen < 8 && intel_edp_is_psr_enabled(dev)) {
- DRM_DEBUG_KMS("DRRS is disabled as PSR is enabled\n");
- return;
- }
-
- encoder = intel_attached_encoder(&intel_connector->base);
- intel_dp = enc_to_intel_dp(&encoder->base);
- intel_crtc = encoder->new_crtc;
-
- if (!intel_crtc) {
- DRM_DEBUG_KMS("DRRS: intel_crtc not initialized\n");
- return;
- }
-
- config = &intel_crtc->config;
-
- if (intel_dp->drrs_state.type < SEAMLESS_DRRS_SUPPORT) {
- DRM_DEBUG_KMS("Only Seamless DRRS supported.\n");
- return;
- }
-
- if (intel_connector->panel.downclock_mode->vrefresh == refresh_rate)
- index = DRRS_LOW_RR;
-
- if (index == intel_dp->drrs_state.refresh_rate_type) {
- DRM_DEBUG_KMS(
- "DRRS requested for previously set RR...ignoring\n");
- return;
- }
-
- if (!intel_crtc->active) {
- DRM_DEBUG_KMS("eDP encoder disabled. CRTC not Active\n");
- return;
- }
-
- if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
- reg = PIPECONF(intel_crtc->config.cpu_transcoder);
- val = I915_READ(reg);
- if (index > DRRS_HIGH_RR) {
- val |= PIPECONF_EDP_RR_MODE_SWITCH;
- intel_dp_set_m_n(intel_crtc);
- } else {
- val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
- }
- I915_WRITE(reg, val);
- }
-
- /*
-* mutex taken to ensure that there is no race between differnt
-* drrs calls trying to update refresh rate. This scenario may occur
-* in future when idleness detection based DRRS in kernel and
-* possible calls from user space to set differnt RR are made.
-*/
-
- mutex_lock(&intel_dp->drrs_state.mutex);
-
- intel_dp->drrs_state.refresh_rate_type = index;
-
- mutex_unlock(&intel_dp->drrs_state.mutex);
-
- DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
-}
-
static struct drm_display_mode *
intel_dp_drrs_init(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ba71522..6ad239d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -941,7 +941,6 @@ void intel_edp_panel_on(struct intel_dp *intel_dp);
void intel_edp_panel_off(struct intel_dp *intel_dp);
void intel_edp_psr_enable(struct intel_dp *intel_dp);
void intel_edp_psr_disable(struct intel_dp *intel_dp);
-void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
void intel_edp_psr_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_edp_psr_flush(struct drm_device *dev,
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
Remove the function intel_output_name() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0a1a56..14c47cf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12258,28 +12258,6 @@ static bool has_edp_a(struct drm_device *dev)
return true;
}
-const char *intel_output_name(int output)
-{
- static const char *names[] = {
- [INTEL_OUTPUT_UNUSED] = "Unused",
- [INTEL_OUTPUT_ANALOG] = "Analog",
- [INTEL_OUTPUT_DVO] = "DVO",
- [INTEL_OUTPUT_SDVO] = "SDVO",
- [INTEL_OUTPUT_LVDS] = "LVDS",
- [INTEL_OUTPUT_TVOUT] = "TV",
- [INTEL_OUTPUT_HDMI] = "HDMI",
- [INTEL_OUTPUT_DISPLAYPORT] = "DisplayPort",
- [INTEL_OUTPUT_EDP] = "eDP",
- [INTEL_OUTPUT_DSI] = "DSI",
- [INTEL_OUTPUT_UNKNOWN] = "Unknown",
- };
-
- if (output < 0 || output >= ARRAY_SIZE(names) || !names[output])
- return "Invalid";
-
- return names[output];
-}
-
static bool intel_crt_present(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ba71522..7dde496 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -793,7 +793,6 @@ void intel_ddi_clock_get(struct intel_encoder *encoder,
void intel_ddi_set_vc_payload_alloc(struct drm_crtc *crtc, bool state);
/* intel_display.c */
-const char *intel_output_name(int output);
bool intel_has_pending_fb_unpin(struct drm_device *dev);
int intel_pch_rawclk(struct drm_device *dev);
void intel_mark_busy(struct drm_device *dev);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/20] fix misspelling of current function in string
Hi Julia, On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote: > These patches replace what appears to be a reference to the name of the > current function but is misspelled in some way by either the name of the > function itself, or by %s and then __func__ in an argument list. Would there be any value in doing this for _all_ cases where the function name is written in a format string? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] gpu: drm: i915: intel_dsi_pll.c: Remove unused function
Remove the function dsi_rr_formula() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 83 +-
1 file changed, 1 insertion(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index fa7a6ca..20086e8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,88 +50,7 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
-#ifdef DSI_CLK_FROM_RR
-
-static u32 dsi_rr_formula(const struct drm_display_mode *mode,
- int pixel_format, int video_mode_format,
- int lane_count, bool eotp)
-{
- u32 bpp;
- u32 hactive, vactive, hfp, hsync, hbp, vfp, vsync, vbp;
- u32 hsync_bytes, hbp_bytes, hactive_bytes, hfp_bytes;
- u32 bytes_per_line, bytes_per_frame;
- u32 num_frames;
- u32 bytes_per_x_frames, bytes_per_x_frames_x_lanes;
- u32 dsi_bit_clock_hz;
- u32 dsi_clk;
-
- switch (pixel_format) {
- default:
- case VID_MODE_FORMAT_RGB888:
- case VID_MODE_FORMAT_RGB666_LOOSE:
- bpp = 24;
- break;
- case VID_MODE_FORMAT_RGB666:
- bpp = 18;
- break;
- case VID_MODE_FORMAT_RGB565:
- bpp = 16;
- break;
- }
-
- hactive = mode->hdisplay;
- vactive = mode->vdisplay;
- hfp = mode->hsync_start - mode->hdisplay;
- hsync = mode->hsync_end - mode->hsync_start;
- hbp = mode->htotal - mode->hsync_end;
-
- vfp = mode->vsync_start - mode->vdisplay;
- vsync = mode->vsync_end - mode->vsync_start;
- vbp = mode->vtotal - mode->vsync_end;
-
- hsync_bytes = DIV_ROUND_UP(hsync * bpp, 8);
- hbp_bytes = DIV_ROUND_UP(hbp * bpp, 8);
- hactive_bytes = DIV_ROUND_UP(hactive * bpp, 8);
- hfp_bytes = DIV_ROUND_UP(hfp * bpp, 8);
-
- bytes_per_line = DSI_HSS_PACKET_SIZE + hsync_bytes +
- DSI_HSA_PACKET_EXTRA_SIZE + DSI_HSE_PACKET_SIZE +
- hbp_bytes + DSI_HBP_PACKET_EXTRA_SIZE +
- hactive_bytes + DSI_HACTIVE_PACKET_EXTRA_SIZE +
- hfp_bytes + DSI_HFP_PACKET_EXTRA_SIZE;
-
- /*
-* XXX: Need to accurately calculate LP to HS transition timeout and add
-* it to bytes_per_line/bytes_per_frame.
-*/
-
- if (eotp && video_mode_format == VIDEO_MODE_BURST)
- bytes_per_line += DSI_EOTP_PACKET_SIZE;
-
- bytes_per_frame = vsync * bytes_per_line + vbp * bytes_per_line +
- vactive * bytes_per_line + vfp * bytes_per_line;
-
- if (eotp &&
- (video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ||
-video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS))
- bytes_per_frame += DSI_EOTP_PACKET_SIZE;
-
- num_frames = drm_mode_vrefresh(mode);
- bytes_per_x_frames = num_frames * bytes_per_frame;
-
- bytes_per_x_frames_x_lanes = bytes_per_x_frames / lane_count;
-
- /* the dsi clock is divided by 2 in the hardware to get dsi ddr clock */
- dsi_bit_clock_hz = bytes_per_x_frames_x_lanes * 8;
- dsi_clk = dsi_bit_clock_hz / 1000;
-
- if (eotp && video_mode_format == VIDEO_MODE_BURST)
- dsi_clk *= 2;
-
- return dsi_clk;
-}
-
-#else
+#ifndef DSI_CLK_FROM_RR
/* Get DSI clock from pixel clock */
static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Intel graphics corruption
well on my arch machine with an intel gma 4 graphics card using xfree86-video-intel im seeing lots of graphics corruption i can give images it it would help -- Fennec ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] gpu: drm: i915: intel_dsi_cmd.c: Remove unused function
Remove the function dsi_hs_mode_enable() that is not used anywhere.
This was partially found by using a static code analysis program called
cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/i915/intel_dsi_cmd.c | 21 -
drivers/gpu/drm/i915/intel_dsi_cmd.h |2 --
2 files changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
index f4767fd..71addcc 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -103,27 +103,6 @@ enum dsi_type {
DSI_GENERIC,
};
-/* enable or disable command mode hs transmissions */
-void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable)
-{
- struct drm_encoder *encoder = &intel_dsi->base.base;
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
- enum pipe pipe = intel_crtc->pipe;
- u32 temp;
- u32 mask = DBI_FIFO_EMPTY;
-
- if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) & mask) == mask, 50))
- DRM_ERROR("Timeout waiting for DBI FIFO empty\n");
-
- temp = I915_READ(MIPI_HS_LP_DBI_ENABLE(pipe));
- temp &= DBI_HS_LP_MODE_MASK;
- I915_WRITE(MIPI_HS_LP_DBI_ENABLE(pipe), enable ? DBI_HS_MODE :
DBI_LP_MODE);
-
- intel_dsi->hs = enable;
-}
-
static int dsi_vc_send_short(struct intel_dsi *intel_dsi, int channel,
u8 data_type, u16 data)
{
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h
b/drivers/gpu/drm/i915/intel_dsi_cmd.h
index 46aa1ac..7ad54c0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_cmd.h
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.h
@@ -36,8 +36,6 @@
#define DPI_LP_MODE_EN false
#define DPI_HS_MODE_EN true
-void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable);
-
int dsi_vc_dcs_write(struct intel_dsi *intel_dsi, int channel,
const u8 *data, int len);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel graphics corruption
On Fri, Dec 05, 2014 at 11:29:09PM -0600, Fennec Fox wrote: > well on my arch machine with an intel gma 4 graphics card using > xfree86-video-intel im seeing lots of graphics corruption i can > give images it it would help I presume you filed https://bugs.freedesktop.org/show_bug.cgi?id=87065 and so know by that this was fixed by commit 656bfa3afc14e45e2d9e1624bf60d79b3beb12f2 Author: Daniel Vetter Date: Thu Nov 20 09:26:30 2014 +0100 drm/i915: Pin tiled objects for L-shaped configs Let's just throw in the towel on this one and take the cheap way out. Based on a patch from Chris Wilson, but checking for a different bit. Chris' patch checked for even bank layout, this one here for a magic bit. Given the evidence we've gathered (not much) both work I think, but checking for the magic bit might be more accurate. Anyway, works on my gm45 here. For paranoi restrict to gen4 (and mobile), since we've only ever seen this on gm45 and i965gm. Also add some debugfs output so that we can skip the tiled swapping tests properly in these cases. v2: Clean up the quirk'ed pin count in free_object to avoid upsetting the WARN_ON. Spotted by Chris. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: > Remove the function intel_output_name() that is not used anywhere. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist Queued for 3.20, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] tests/kms_psr_sink_crc: Add manual mode.
On Fri, Dec 05, 2014 at 08:14:24PM -0500, Rodrigo Vivi wrote:
> Sink CRC is the most reliable way to test PSR. However in some platforms
> apparently auto generated packages force panel to keep calculating CRC
> invalidating
> our current sink crc check over debugfs.
>
> So, this manual test help us to find possible gaps on this platforms where we
> cannot
> trust on sink crc checks.
>
> Signed-off-by: Rodrigo Vivi
> ---
> tests/kms_psr_sink_crc.c | 74
>
> 1 file changed, 68 insertions(+), 6 deletions(-)
>
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index 155c25f..3853031 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ioctl_wrappers.h"
> #include "drmtest.h"
> @@ -37,6 +38,7 @@
> #include "igt_aux.h"
>
> bool running_with_psr_disabled;
> +bool manual;
>
> #define CRC_BLACK ""
>
> @@ -244,6 +246,9 @@ static void get_sink_crc(data_t *data, char *crc) {
> int ret;
> FILE *file;
>
> + if (manual)
> + return;
> +
> file = igt_debugfs_fopen("i915_sink_crc_eDP1", "r");
> igt_require(file);
>
> @@ -271,6 +276,9 @@ static bool is_green(char *crc)
> unsigned int rh, gh, bh, mask;
> int ret;
>
> + if (manual)
> + return false;
> +
> sscanf(color_mask, "%4x", &mask);
>
> memcpy(rs, &crc[0], 4);
> @@ -293,6 +301,31 @@ static bool is_green(char *crc)
> (bh & mask) == 0);
> }
>
> +static void assert(bool condition, const char *debug_msg)
This collides with the libc assert() macro.
> +{
> + if (manual) {
> + struct termios oldt, newt;
> + char c;
> +
> + igt_info("%s? [Y/n]: ", debug_msg);
> +
> + tcgetattr(STDIN_FILENO, &oldt);
> + newt = oldt;
> + newt.c_lflag &= ~(ICANON);
> + tcsetattr(STDIN_FILENO, TCSANOW, &newt);
> + c = getchar();
> + if (c != '\n')
> + igt_info("\n");
> + tcsetattr(STDIN_FILENO, TCSANOW, &oldt);
> +
> + if (c == 'n' || c == 'N')
> + igt_fail(-1);
tbh not sure whether this is all that useful to wait for keypresses and
then make the test fail/pass. You need to manually run the testcase
anyway. Imo better to just use igt_debug_wait_for_keypress. That one also
magically skips if the option hasn't been set. And yeah we might good to
add a new common option like --interactive-debug for it instead of just
the env variable. You could even reuse that here then (by exporting
an igt_interactive_debug boolean or so).
> + } else {
> + igt_debug("%s\n", debug_msg);
> + igt_assert(condition);
igt_assert_f. Also I'd just use igt_assert_f(manual || condition) instead,
simplifies the control flow.
> + }
> +}
> +
> static void test_crc(data_t *data)
> {
> uint32_t handle = data->fb_white.gem_handle;
> @@ -300,18 +333,19 @@ static void test_crc(data_t *data)
> void *ptr;
> char ref_crc[12];
> char crc[12];
> + char manual_debug[50] = "";
Just make this a const char * point and assign strings to it. No need for
strcpy.
>
> igt_plane_set_fb(data->primary, &data->fb_green);
> igt_display_commit(&data->display);
>
> /* Confirm that screen became Green */
> get_sink_crc(data, ref_crc);
> - igt_assert(is_green(ref_crc));
> + assert(is_green(ref_crc), "screen GREEN");
>
> /* Confirm screen stays Green after PSR got active */
> igt_assert(wait_psr_entry(data, 10));
> get_sink_crc(data, ref_crc);
> - igt_assert(is_green(ref_crc));
> + assert(is_green(ref_crc), "screen GREEN");
>
> /* Setting a secondary fb/plane */
> switch (data->test_plane) {
> @@ -325,7 +359,10 @@ static void test_crc(data_t *data)
> /* Confirm it is not Green anymore */
> igt_assert(wait_psr_entry(data, 10));
> get_sink_crc(data, ref_crc);
> - igt_assert(!is_green(ref_crc));
> + if (data->test_plane == PRIMARY)
> + assert(!is_green(ref_crc), "screen WHITE");
> + else
> + assert(!is_green(ref_crc), "GREEN background with WHITE box");
>
> switch (data->op) {
> case PAGE_FLIP:
> @@ -333,7 +370,8 @@ static void test_crc(data_t *data)
> igt_assert(drmModePageFlip(data->drm_fd, data->crtc_id,
> data->fb_green.fb_id, 0, NULL) == 0);
> get_sink_crc(data, crc);
> - igt_assert(is_green(crc));
> + assert(is_green(crc), "screen GREEN");
> + strcpy(manual_debug, "still GREEN");
> break;
> case MMAP_GTT:
> ptr = gem_mmap__gtt(data->drm_fd, handle, data->mod_size,
> @@ -342,6 +380,8 @@ static void test_crc(data_t *data)
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.
On Fri, Dec 05, 2014 at 08:40:42PM -0500, Rodrigo Vivi wrote:
> Since active function on VLV immediately activate PSR let's give more
> time for idleness.
>
> v2: Rebase over intel_psr.c and fix typo.
> v3: Revival: Manual tests indicated that this is needed. With a short delay
> there is a huge
> risk of getting blank screens when planes are being enabled.
>
> Signed-off-by: Rodrigo Vivi
> Reviewed-by: Durgadoss R
> ---
> drivers/gpu/drm/i915/intel_psr.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index afb8b8c..a6028b6 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -597,6 +597,12 @@ void intel_psr_flush(struct drm_device *dev,
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc;
> enum pipe pipe;
> + /* On HSW/BDW Hardware controls idle_frames to go to PSR entry state
> + * However on VLV we go to PSR active state with psr work. So let's
> + * wait more time. The main reason is to give more time when primary
> + * plane is getting enabled avoiding blank screens.
> + */
> + int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 5000);
Same question as before: Shouldn't we look at vbt perhaps like on ddi
platforms to compute a reasonable delay? 5s is kinda not reasonable I
think ;-)
-Daniel
>
> mutex_lock(&dev_priv->psr.lock);
> if (!dev_priv->psr.enabled) {
> @@ -629,7 +635,7 @@ void intel_psr_flush(struct drm_device *dev,
>
> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> schedule_delayed_work(&dev_priv->psr.work,
> - msecs_to_jiffies(100));
> + msecs_to_jiffies(delay));
> mutex_unlock(&dev_priv->psr.lock);
> }
>
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: resume MST after reading back hw state
On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Otherwise the MST resume paths can hit DPMS paths > which hit state checker paths, which hit WARN_ON, > because the state checker is inconsistent with the > hw. > > This fixes a bunch of WARN_ON's on resume after > undocking. > > Signed-off-by: Dave Airlie Makes sense, so Reviewed-by: Daniel Vetter And Cc: sta...@vger.kernel.org when Jani picks it up. While reading around I've noticed though that we might miss dp mst changes after resume: - intel_dp_mst_resume checks for can_mst, so will skip if we didn't plug in an mst thing before suspend. - drm_helper_hpd_irq_event only does the locked detect dance and doesn't do the unlocked mst dance we do before calling down into ->detect callbacks. So I think if we plug in an mst dock while suspended and then resume we'll miss the hotplug in the kernel. Or do I miss something? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: resume MST after reading back hw state
On Mon, Dec 08, 2014 at 10:44:54AM +0100, Daniel Vetter wrote: > On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote: > > From: Dave Airlie > > > > Otherwise the MST resume paths can hit DPMS paths > > which hit state checker paths, which hit WARN_ON, > > because the state checker is inconsistent with the > > hw. > > > > This fixes a bunch of WARN_ON's on resume after > > undocking. > > > > Signed-off-by: Dave Airlie > > Makes sense, so Reviewed-by: Daniel Vetter > > And Cc: sta...@vger.kernel.org when Jani picks it up. > > While reading around I've noticed though that we might miss dp mst changes > after resume: > - intel_dp_mst_resume checks for can_mst, so will skip if we didn't plug > in an mst thing before suspend. > - drm_helper_hpd_irq_event only does the locked detect dance and doesn't > do the unlocked mst dance we do before calling down into ->detect > callbacks. > > So I think if we plug in an mst dock while suspended and then resume > we'll miss the hotplug in the kernel. Or do I miss something? Aside: On some ports/platforms hpd pins don't work until hpd interrupts are enabled. So maybe we should take the full reprobe out of intel_dp_mst_resume anyway and replace drm_helper_hpd_irq_event with a call to schedule our async hpd worker with all port bits set? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote: > On 12/05/2014 04:50 PM, Gerd Hoffmann wrote: > > A few comments on the kernel stuff (brief look so far, also > > compile-tested only, intel gfx on my test machine is too old). > > > > * Noticed the kernel bits don't even compile when configured as > > module. Everything (vgt, i915, kvm) must be compiled into the > > kernel. > > Yes, that's planned to be done along with separating hypervisor-related > code from vgt. Good. > > What are the exact requirements for the device? Must it match the host > > exactly, to not confuse the guest intel graphics driver? Or would > > something more recent -- such as the q35 emulation qemu has -- be good > > enough to make things work (assuming we add support for the > > graphic-related pci config space registers there)? > > > > I don't know that is exactly needed, we also need to have Windows > driver considered. However, I'm quite confident that, if things gonna > work for IGD passthrough, it gonna work for GVT-g. I'd suggest to focus on q35 emulation. q35 is new enough that a version with integrated graphics exists, so the gap we have to close is *much* smaller. In case guests expect a northbridge matching the chipset generation of the graphics device (which I'd expect is the case, after digging a bit in the igd and agpgart linux driver code) I think we should add proper device emulation for them, i.e. comply q35-pcihost with sandybridge-pcihost + ivybridge-pcihost + haswell-pcihost instead of just copying over the pci ids from the host. Most likely all those variants can share most of the emulation code. SeaBIOS then can just get support for these three northbridge variants, so we don't need magic pci id switching hacks at all. > > The patch also adds a dummy isa bridge at 0x1f. Simliar question here: > > What exactly is needed here? Would things work if we simply use the q35 > > lpc device here? > Ditto. Ok. Lets try to just use the q35 emulation + q35 lpc device then instead of adding a second dummy lpc device. cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_sideband.c: Remove some unused functions
On Sun, 07 Dec 2014, Rickard Strandqvist
wrote:
> Removes some functions that are not used anywhere:
> vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
> vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
I'd let them be.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/i915_drv.h |6 -
> drivers/gpu/drm/i915/intel_sideband.c | 44
> -
> 2 files changed, 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 16a6f6d..d248957 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2849,23 +2849,17 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv, u8 mbox, u32 val)
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr);
> void vlv_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 val);
> u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg);
> void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg, u32 val);
> u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
> enum intel_sbi_destination destination);
> void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
>enum intel_sbi_destination destination);
> -u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>
> int vlv_gpu_freq(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 01d841e..5939171 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -129,14 +129,6 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8
> addr)
> return val;
> }
>
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> {
> vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
> @@ -157,34 +149,6 @@ void vlv_cck_write(struct drm_i915_private *dev_priv,
> u32 reg, u32 val)
> SB_CRWRDA_NP, reg, &val);
> }
>
> -u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> -void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> -{
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
> - SB_CRWRDA_NP, reg, &val);
> -}
> -
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> -{
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
> - SB_CRWRDA_NP, reg, &val);
> -}
> -
> u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg)
> {
> u32 val = 0;
> @@ -267,14 +231,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
> u16 reg, u32 value,
> }
> }
>
> -u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
> - reg, &val);
> - return val;
> -}
> -
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> {
> vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
___
Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM
On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote: > On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote: > > I don't know that is exactly needed, we also need to have Windows > > driver considered. However, I'm quite confident that, if things gonna > > work for IGD passthrough, it gonna work for GVT-g. > > I'd suggest to focus on q35 emulation. q35 is new enough that a version > with integrated graphics exists, so the gap we have to close is *much* > smaller. > > In case guests expect a northbridge matching the chipset generation of > the graphics device (which I'd expect is the case, after digging a bit > in the igd and agpgart linux driver code) I think we should add proper > device emulation for them, i.e. comply q35-pcihost with > sandybridge-pcihost + ivybridge-pcihost + haswell-pcihost instead of > just copying over the pci ids from the host. Most likely all those > variants can share most of the emulation code. I don't think i915.ko should care about either northbridge nor pch on para-virtualized platforms. We do noodle around in there for the oddball memory controller setting and for some display stuff. But neither of that really applies to paravirtualized hw. And if there's any case like that we should patch it out (like we do with some of the runtime pm code already). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/20] drm/i915: fix misspelling of current function in string
On Sun, 07 Dec 2014, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
>
> ---
> The semantic patch is difficult to summarize, but is available in the cover
> letter of this patch series.
>
> The message is sort of ambiguous, but I assume that it is intended to refer
> to the function in which the problem is detected.
Hmm, DRM_DEBUG prints __func__ too.
Jani.
>
> drivers/gpu/drm/i915/i915_gem.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d2ba315..fa21d1c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4335,7 +4335,7 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
> }
>
> if (obj->pin_filp != file) {
> - DRM_DEBUG("Not pinned by caller in i915_gem_pin_ioctl(): %d\n",
> + DRM_DEBUG("Not pinned by caller in %s(): %d\n", __func__,
> args->handle);
> ret = -EINVAL;
> goto out;
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_dsi_cmd.c: Remove unused function
On Sun, 07 Dec 2014, Rickard Strandqvist
wrote:
> Remove the function dsi_hs_mode_enable() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/intel_dsi_cmd.c | 21 -
> drivers/gpu/drm/i915/intel_dsi_cmd.h |2 --
> 2 files changed, 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> index f4767fd..71addcc 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> @@ -103,27 +103,6 @@ enum dsi_type {
> DSI_GENERIC,
> };
>
> -/* enable or disable command mode hs transmissions */
> -void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable)
> -{
> - struct drm_encoder *encoder = &intel_dsi->base.base;
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> - enum pipe pipe = intel_crtc->pipe;
> - u32 temp;
> - u32 mask = DBI_FIFO_EMPTY;
> -
> - if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) & mask) == mask, 50))
> - DRM_ERROR("Timeout waiting for DBI FIFO empty\n");
> -
> - temp = I915_READ(MIPI_HS_LP_DBI_ENABLE(pipe));
> - temp &= DBI_HS_LP_MODE_MASK;
> - I915_WRITE(MIPI_HS_LP_DBI_ENABLE(pipe), enable ? DBI_HS_MODE :
> DBI_LP_MODE);
> -
> - intel_dsi->hs = enable;
> -}
> -
> static int dsi_vc_send_short(struct intel_dsi *intel_dsi, int channel,
>u8 data_type, u16 data)
> {
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> index 46aa1ac..7ad54c0 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> @@ -36,8 +36,6 @@
> #define DPI_LP_MODE_EN false
> #define DPI_HS_MODE_EN true
>
> -void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable);
> -
> int dsi_vc_dcs_write(struct intel_dsi *intel_dsi, int channel,
>const u8 *data, int len);
>
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_dsi_pll.c: Remove unused function
On Mon, 08 Dec 2014, Rickard Strandqvist
wrote:
> Remove the function dsi_rr_formula() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 83
> +-
> 1 file changed, 1 insertion(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index fa7a6ca..20086e8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -50,88 +50,7 @@ static const u32 lfsr_converts[] = {
> 71, 35 /* 91 - 92 */
> };
>
> -#ifdef DSI_CLK_FROM_RR
> -
> -static u32 dsi_rr_formula(const struct drm_display_mode *mode,
> - int pixel_format, int video_mode_format,
> - int lane_count, bool eotp)
> -{
> - u32 bpp;
> - u32 hactive, vactive, hfp, hsync, hbp, vfp, vsync, vbp;
> - u32 hsync_bytes, hbp_bytes, hactive_bytes, hfp_bytes;
> - u32 bytes_per_line, bytes_per_frame;
> - u32 num_frames;
> - u32 bytes_per_x_frames, bytes_per_x_frames_x_lanes;
> - u32 dsi_bit_clock_hz;
> - u32 dsi_clk;
> -
> - switch (pixel_format) {
> - default:
> - case VID_MODE_FORMAT_RGB888:
> - case VID_MODE_FORMAT_RGB666_LOOSE:
> - bpp = 24;
> - break;
> - case VID_MODE_FORMAT_RGB666:
> - bpp = 18;
> - break;
> - case VID_MODE_FORMAT_RGB565:
> - bpp = 16;
> - break;
> - }
> -
> - hactive = mode->hdisplay;
> - vactive = mode->vdisplay;
> - hfp = mode->hsync_start - mode->hdisplay;
> - hsync = mode->hsync_end - mode->hsync_start;
> - hbp = mode->htotal - mode->hsync_end;
> -
> - vfp = mode->vsync_start - mode->vdisplay;
> - vsync = mode->vsync_end - mode->vsync_start;
> - vbp = mode->vtotal - mode->vsync_end;
> -
> - hsync_bytes = DIV_ROUND_UP(hsync * bpp, 8);
> - hbp_bytes = DIV_ROUND_UP(hbp * bpp, 8);
> - hactive_bytes = DIV_ROUND_UP(hactive * bpp, 8);
> - hfp_bytes = DIV_ROUND_UP(hfp * bpp, 8);
> -
> - bytes_per_line = DSI_HSS_PACKET_SIZE + hsync_bytes +
> - DSI_HSA_PACKET_EXTRA_SIZE + DSI_HSE_PACKET_SIZE +
> - hbp_bytes + DSI_HBP_PACKET_EXTRA_SIZE +
> - hactive_bytes + DSI_HACTIVE_PACKET_EXTRA_SIZE +
> - hfp_bytes + DSI_HFP_PACKET_EXTRA_SIZE;
> -
> - /*
> - * XXX: Need to accurately calculate LP to HS transition timeout and add
> - * it to bytes_per_line/bytes_per_frame.
> - */
> -
> - if (eotp && video_mode_format == VIDEO_MODE_BURST)
> - bytes_per_line += DSI_EOTP_PACKET_SIZE;
> -
> - bytes_per_frame = vsync * bytes_per_line + vbp * bytes_per_line +
> - vactive * bytes_per_line + vfp * bytes_per_line;
> -
> - if (eotp &&
> - (video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ||
> - video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS))
> - bytes_per_frame += DSI_EOTP_PACKET_SIZE;
> -
> - num_frames = drm_mode_vrefresh(mode);
> - bytes_per_x_frames = num_frames * bytes_per_frame;
> -
> - bytes_per_x_frames_x_lanes = bytes_per_x_frames / lane_count;
> -
> - /* the dsi clock is divided by 2 in the hardware to get dsi ddr clock */
> - dsi_bit_clock_hz = bytes_per_x_frames_x_lanes * 8;
> - dsi_clk = dsi_bit_clock_hz / 1000;
> -
> - if (eotp && video_mode_format == VIDEO_MODE_BURST)
> - dsi_clk *= 2;
> -
> - return dsi_clk;
> -}
> -
> -#else
> +#ifndef DSI_CLK_FROM_RR
>
> /* Get DSI clock from pixel clock */
> static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_dp.c: Remove unused function
On Sun, Dec 07, 2014 at 10:36:10PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_dp_set_drrs_state() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Ok I've merged one of these patches here for old stale code, but all the
others are in areas where there's a lot of stuff going on and we'll likely
use these functions again. So decided to drop those patches.
If you want to keep working on drm stuff I'd highly appreciate it. We have
a list of intro tasks which might be interesting:
http://www.x.org/wiki/DRMJanitors/
Nuking all the UMS checks might be a good one, we've already started with
that. And #intel-gfx irc on freenode is always a good place to hang out
and ask questions.
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 89
> --
> drivers/gpu/drm/i915/intel_drv.h |1 -
> 2 files changed, 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5ad45bf..6df948b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4810,95 +4810,6 @@ intel_dp_init_panel_power_sequencer_registers(struct
> drm_device *dev,
> I915_READ(pp_div_reg));
> }
>
> -void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_encoder *encoder;
> - struct intel_dp *intel_dp = NULL;
> - struct intel_crtc_config *config = NULL;
> - struct intel_crtc *intel_crtc = NULL;
> - struct intel_connector *intel_connector = dev_priv->drrs.connector;
> - u32 reg, val;
> - enum edp_drrs_refresh_rate_type index = DRRS_HIGH_RR;
> -
> - if (refresh_rate <= 0) {
> - DRM_DEBUG_KMS("Refresh rate should be positive non-zero.\n");
> - return;
> - }
> -
> - if (intel_connector == NULL) {
> - DRM_DEBUG_KMS("DRRS supported for eDP only.\n");
> - return;
> - }
> -
> - /*
> - * FIXME: This needs proper synchronization with psr state. But really
> - * hard to tell without seeing the user of this function of this code.
> - * Check locking and ordering once that lands.
> - */
> - if (INTEL_INFO(dev)->gen < 8 && intel_edp_is_psr_enabled(dev)) {
> - DRM_DEBUG_KMS("DRRS is disabled as PSR is enabled\n");
> - return;
> - }
> -
> - encoder = intel_attached_encoder(&intel_connector->base);
> - intel_dp = enc_to_intel_dp(&encoder->base);
> - intel_crtc = encoder->new_crtc;
> -
> - if (!intel_crtc) {
> - DRM_DEBUG_KMS("DRRS: intel_crtc not initialized\n");
> - return;
> - }
> -
> - config = &intel_crtc->config;
> -
> - if (intel_dp->drrs_state.type < SEAMLESS_DRRS_SUPPORT) {
> - DRM_DEBUG_KMS("Only Seamless DRRS supported.\n");
> - return;
> - }
> -
> - if (intel_connector->panel.downclock_mode->vrefresh == refresh_rate)
> - index = DRRS_LOW_RR;
> -
> - if (index == intel_dp->drrs_state.refresh_rate_type) {
> - DRM_DEBUG_KMS(
> - "DRRS requested for previously set RR...ignoring\n");
> - return;
> - }
> -
> - if (!intel_crtc->active) {
> - DRM_DEBUG_KMS("eDP encoder disabled. CRTC not Active\n");
> - return;
> - }
> -
> - if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
> - reg = PIPECONF(intel_crtc->config.cpu_transcoder);
> - val = I915_READ(reg);
> - if (index > DRRS_HIGH_RR) {
> - val |= PIPECONF_EDP_RR_MODE_SWITCH;
> - intel_dp_set_m_n(intel_crtc);
> - } else {
> - val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
> - }
> - I915_WRITE(reg, val);
> - }
> -
> - /*
> - * mutex taken to ensure that there is no race between differnt
> - * drrs calls trying to update refresh rate. This scenario may occur
> - * in future when idleness detection based DRRS in kernel and
> - * possible calls from user space to set differnt RR are made.
> - */
> -
> - mutex_lock(&intel_dp->drrs_state.mutex);
> -
> - intel_dp->drrs_state.refresh_rate_type = index;
> -
> - mutex_unlock(&intel_dp->drrs_state.mutex);
> -
> - DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
> -}
> -
> static struct drm_display_mode *
> intel_dp_drrs_init(struct intel_digital_port *intel_dig_port,
> struct intel_connector *intel_connector,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ba71522..6ad239d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -941,7 +941,6 @@ void intel_edp_panel_on(struct inte
Re: [Intel-gfx] [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
On Mon, 08 Dec 2014, Aaron Lu wrote:
> We have a new bug report that has the same problem:
> https://bugzilla.kernel.org/show_bug.cgi?id=88941
>
> The posted patch solves the problem. I know it's not perfect, but it
> doesn't seem it would do any harm to existing systems so should be safe.
>
> Better, if someone can shed some light on how this should be properly
> handled, that would be great.
There was a bug report that I can't find right now that had a similar
problem. I wrote a few patches, even somewhat polished ones (that I now
pushed to [1] for reference) to handle extended DIDL. Unfortunately this
didn't help the bug reporter because the right one was beyond the
extended DIDL too, so I don't think I even sent these to the list.
Anyway, just one more data point. This might help your reporter, so
worth a try. But it doesn't solve everything.
BR,
Jani.
>
> Thanks,
> Aaron
>
> On 03/04/2014 10:45 PM, Daniel Vetter wrote:
>> On Wed, Feb 19, 2014 at 04:59:06PM +0800, Aaron Lu wrote:
>>> On 02/19/2014 03:33 PM, Matthew Garrett wrote:
On Wed, Feb 19, 2014 at 03:31:29PM +0800, Aaron Lu wrote:
> DID2 is in system memory region and has some assigned value like 0x400
> when we read it. For this case it is easy since there is only one output
> device that is of type LVDS so we can match it to connector of type eDP
> or LVDS, suppose there is only one such connector. But for output
> devices' whose _ADR has the value of 0x301, 0x302, etc. I have no idea
> how to match them up to the connectors of that type as we can't be sure
> the probe order we have used in i915 driver is the same as BIOS'.
Non-standard _ADR values are assigend by the GPU vendor, so Intel should
be able to provide you with the correct interpretations.
>>>
>>> It doesn't seem the _ADR value has to be the format defined by _DOD, as
>>> the example of the ACPI spec gives:
>>> Method (_ADR, 0) {
>>> return(0x0100)
>>> }
>>> So that is not the problem here.
>>>
>>> The problem is, we don't have any way of matching an ACPI output device
>>> node to a drm connector of the same type when there are more than 1 of
>>> those with the same type, i.e. we don't know how the index value are
>>> assigned by BIOS.
>>
>> I've thought the OpRegion spec has some additional fields in there
>> indicating the port number, which we could match up at least on modern
>> platforms (where there's only ever port A-E). But that's very hazy
>> recollection from a really old OpRegion spec, i.e. I have no bloody clue
>> at all ;-)
>>
>> If I misremember this then we need to start on a begging tour again and
>> ask the windows guys how this is all supposed to work ...
>> -Daniel
>>
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/opregion: work around buggy firmware that provides 8+ output devices
On Mon, 08 Dec 2014, Jani Nikula wrote: > On Mon, 08 Dec 2014, Aaron Lu wrote: >> We have a new bug report that has the same problem: >> https://bugzilla.kernel.org/show_bug.cgi?id=88941 >> >> The posted patch solves the problem. I know it's not perfect, but it >> doesn't seem it would do any harm to existing systems so should be safe. >> >> Better, if someone can shed some light on how this should be properly >> handled, that would be great. > > There was a bug report that I can't find right now that had a similar > problem. I wrote a few patches, even somewhat polished ones (that I now > pushed to [1] for reference) to handle extended DIDL. Unfortunately this > didn't help the bug reporter because the right one was beyond the > extended DIDL too, so I don't think I even sent these to the list. > > Anyway, just one more data point. This might help your reporter, so > worth a try. But it doesn't solve everything. [1] http://cgit.freedesktop.org/~jani/drm/log/?h=didl -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use DSI Pll1 for enabling MIPI DSI on Port C
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
> DSI Pll1 is used for enabling DSI on Port C.
>
> Signed-off-by: Gaurav K Singh
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c |7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index 8957f10..9b7f6a5 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -241,9 +241,12 @@ static void vlv_configure_dsi_pll(struct intel_encoder
> *encoder)
> return;
> }
>
> - dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI0_DSIPLL;
> + if ((intel_dsi->ports == ((1 << PORT_A) | (1 << PORT_C))) ||
> + (intel_dsi->ports == (1 << PORT_A)))
> + dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI0_DSIPLL;
>
> - if (intel_dsi->dual_link)
> + if ((intel_dsi->ports == ((1 << PORT_A) | (1 << PORT_C))) ||
> + (intel_dsi->ports == (1 << PORT_C)))
> dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI1_DSIPLL;
In other words, patches 1 and 2 can be squashed into one that has:
if (intel_dsi->ports & (1 << PORT_A))
dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI0_DSIPLL;
if (intel_dsi->ports & (1 << PORT_C))
dsi_mnp.dsi_pll_ctrl |= DSI_PLL_CLK_GATE_DSI1_DSIPLL;
Right?
BR,
Jani.
>
> DRM_DEBUG_KMS("dsi pll div %08x, ctrl %08x\n",
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Get HW state changes required for DSI port C
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
> Due to some hardware limitations, MIPI Port C DPI Enable bit
> does not get set. To check whether DSI Port C was enabled in BIOS,
> check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
> is linked with Pipe B.
"due to some hardware limitations" is awfully vague. The same code will
be used on many platforms; I doubt this applies to all of them. Is there
a workaround name for this?
BR,
Jani.
>
> Signed-off-by: Gaurav K Singh
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 215d004..0334c4d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -398,8 +398,9 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> enum pipe *pipe)
> {
> struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> enum intel_display_power_domain power_domain;
> - u32 port_ctl, func;
> + u32 dsi_status, func;
> enum port port;
>
> DRM_DEBUG_KMS("\n");
> @@ -409,13 +410,23 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> return false;
>
> /* XXX: this only works for one DSI output */
> - for_each_dsi_port(port, (1 << PORT_A) | (1 << PORT_C)) {
> - port_ctl = I915_READ(MIPI_PORT_CTRL(port));
> + for_each_dsi_port(port, intel_dsi->ports) {
> func = I915_READ(MIPI_DSI_FUNC_PRG(port));
>
> - if ((port_ctl & DPI_ENABLE) || (func &
> CMD_MODE_DATA_WIDTH_MASK)) {
> + /* Due to some hardware limitations, MIPI Port C DPI Enable
> + * bit does not get set. To check whether DSI Port C was
> + * enabled in BIOS, check the Pipe B enable bit
> + */
> + if (port == PORT_C)
> + dsi_status = I915_READ(PIPECONF(PIPE_B)) &
> + PIPECONF_ENABLE;
> + else
> + dsi_status = I915_READ(MIPI_PORT_CTRL(port)) &
> + DPI_ENABLE;
> +
> + if (dsi_status || (func & CMD_MODE_DATA_WIDTH_MASK)) {
> if (I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY) {
> - *pipe = port == PORT_A ? PIPE_A : PIPE_C;
> + *pipe = port == PORT_A ? PIPE_A : PIPE_B;
> return true;
> }
> }
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
2014-12-08 6:42 GMT-02:00 Daniel Vetter : > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: >> Remove the function intel_output_name() that is not used anywhere. >> >> This was partially found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist > > Queued for 3.20, thanks for the patch. This function was created for the "DDI personality" patches. We merged the function but never ended up merging the patch containing the callers... > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Sat, 06 Dec 2014, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift
> result
> (0x2800200) requires 43 bits to represent, but 'int' only has 32
> bits
> [-Wshift-overflow]
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> ^~~
> drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
> 'WA_SET_BIT_MASKED'
> WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0x)
>
> Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
> trying to shift it a bit more.
>
> The other thing is that it's not the usual case of setting WA bits here, we
> need to have separate mask and value.
>
> To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
> (unshifted) mask and the desired value and the rest of the patch ripples
> through from it.
>
> This bug was introduced when reworking the WA emission in:
>
> Commit 7225342ab501befdb64bcec76ded41f5897c0855
> Author: Mika Kuoppala
> Date: Tue Oct 7 17:21:26 2014 +0300
>
> drm/i915: Build workaround list in ring initialization
>
> Cc: Mika Kuoppala
> Cc: Arun Siluvery
> Signed-off-by: Damien Lespiau
Pushed to drm-intel-next-fixes, thanks for the patch.
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 ++--
> 3 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc03fac..6c64d61 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -36,6 +36,7 @@
>
> #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
special cases of _MASKED_FIELD...? ;)
BR,
Jani.
>
> /* PCI config space */
>
> @@ -1284,7 +1285,7 @@ enum punit_power_well {
> #define GEN6_WIZ_HASHING_8x8
> GEN6_WIZ_HASHING(0, 0)
> #define GEN6_WIZ_HASHING_8x4
> GEN6_WIZ_HASHING(0, 1)
> #define GEN6_WIZ_HASHING_16x4
> GEN6_WIZ_HASHING(1, 0)
> -#define GEN6_WIZ_HASHING_MASK
> (GEN6_WIZ_HASHING(1, 1) << 16)
> +#define GEN6_WIZ_HASHING_MASK
> GEN6_WIZ_HASHING(1, 1)
> #define GEN6_TD_FOUR_ROW_DISPATCH_DISABLE (1 << 5)
>
> #define GFX_MODE 0x02520
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 78911e2..209751b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6389,7 +6389,7 @@ static void gen6_init_clock_gating(struct drm_device
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
> I915_WRITE(GEN6_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_16x4, GEN6_WIZ_HASHING_MASK));
>
> ilk_init_lp_watermarks(dev);
>
> @@ -6587,7 +6587,7 @@ static void haswell_init_clock_gating(struct drm_device
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
> I915_WRITE(GEN7_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_16x4, GEN6_WIZ_HASHING_MASK));
>
> /* WaSwitchSolVfFArbitrationPriority:hsw */
> I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
> @@ -6684,7 +6684,7 @@ static void ivybridge_init_clock_gating(struct
> drm_device *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
> I915_WRITE(GEN7_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_16x4, GEN6_WIZ_HASHING_MASK));
>
> snpcr = I915_READ(GEN6_MBCUNIT_SNPCR);
> snpcr &= ~GEN6_MBC_SNPCR_MASK;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 79b4ca5..40cefef 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -739,6 +739,9 @@ static int wa_add(struct drm_i915_private *dev_priv,
> #define WA_CLR_BIT_MASKED(addr, mask) \
> WA_REG(addr, _MASKED_BIT_DISABLE(mask), (mask) & 0x)
>
> +#define WA_SET_FIELD_MASKED(addr, value, mask) \
> + WA_REG(addr, _MASKED_FIELD(value, mask), mask)
> +
> #define WA_SET_BIT(addr, mask) WA_REG(addr, I915_READ(addr) | (mask), mask)
> #define WA_CLR_BIT(
Re: [Intel-gfx] [PATCH] drm/i915: resume MST after reading back hw state
On Mon, 08 Dec 2014, Daniel Vetter wrote: > On Mon, Dec 08, 2014 at 01:23:37PM +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> Otherwise the MST resume paths can hit DPMS paths >> which hit state checker paths, which hit WARN_ON, >> because the state checker is inconsistent with the >> hw. >> >> This fixes a bunch of WARN_ON's on resume after >> undocking. >> >> Signed-off-by: Dave Airlie > > Makes sense, so Reviewed-by: Daniel Vetter Pushed to drm-intel-next-fixes, thanks for the patch and review. BR, Jani. > > And Cc: sta...@vger.kernel.org when Jani picks it up. > > While reading around I've noticed though that we might miss dp mst changes > after resume: > - intel_dp_mst_resume checks for can_mst, so will skip if we didn't plug > in an mst thing before suspend. > - drm_helper_hpd_irq_event only does the locked detect dance and doesn't > do the unlocked mst dance we do before calling down into ->detect > callbacks. > > So I think if we plug in an mst dock while suspended and then resume > we'll miss the hotplug in the kernel. Or do I miss something? > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: compute wait_ioctl timeout correctly
On Thu, 04 Dec 2014, Daniel Vetter wrote:
> We've lost the +1 required for correct timeouts in
>
> commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
> Author: Thomas Gleixner
> Date: Wed Jul 16 21:05:06 2014 +
>
> drm: i915: Use nsec based interfaces
>
> Use ktime_get_raw_ns() and get rid of the back and forth timespec
> conversions.
>
> Signed-off-by: Thomas Gleixner
> Acked-by: Daniel Vetter
> Signed-off-by: John Stultz
>
> So fix this up by reinstating our handrolled _timeout function. While
> at it bother with handling MAX_JIFFIES.
>
> v2: Convert to usecs (we don't care about the accuracy anyway) first
> to avoid overflow issues Dave Gordon spotted.
>
> v3: Drop the explicit MAX_JIFFY_OFFSET check, usecs_to_jiffies should
> take care of that already. It might be a bit too enthusiastic about it
> though.
>
> v4: Chris has a much nicer color, so use his implementation.
>
> This requires to export nsec_to_jiffies from time.c.
>
> Cc: Chris Wilson
> Cc: Dave Gordon
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749
> Cc: Thomas Gleixner
> Cc: John Stultz
> Signed-off-by: Daniel Vetter
Pushed to drm-intel-next-fixes, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/i915_gem.c | 3 ++-
> kernel/time/time.c | 1 +
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 049482f5d9ac..564a45f4a0ab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3097,6 +3097,11 @@ static inline unsigned long
> msecs_to_jiffies_timeout(const unsigned int m)
> return min_t(unsigned long, MAX_JIFFY_OFFSET, j + 1);
> }
>
> +static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
> +{
> +return min_t(u64, MAX_JIFFY_OFFSET, nsecs_to_jiffies64(n) + 1);
> +}
> +
> static inline unsigned long
> timespec_to_jiffies_timeout(const struct timespec *value)
> {
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 9d362d320d82..04a9f26407ae 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1226,7 +1226,8 @@ int __i915_wait_request(struct drm_i915_gem_request
> *req,
> if (i915_gem_request_completed(req, true))
> return 0;
>
> - timeout_expire = timeout ? jiffies + nsecs_to_jiffies((u64)*timeout) :
> 0;
> + timeout_expire = timeout ?
> + jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
>
> if (INTEL_INFO(dev)->gen >= 6 && ring->id == RCS &&
> can_wait_boost(file_priv)) {
> gen6_rps_boost(dev_priv);
> diff --git a/kernel/time/time.c b/kernel/time/time.c
> index a9ae20fb0b11..8fae82ca5cbf 100644
> --- a/kernel/time/time.c
> +++ b/kernel/time/time.c
> @@ -745,6 +745,7 @@ u64 nsecs_to_jiffies64(u64 n)
> return div_u64(n * 9, (9ull * NSEC_PER_SEC + HZ / 2) / HZ);
> #endif
> }
> +EXPORT_SYMBOL(nsecs_to_jiffies64);
>
> /**
> * nsecs_to_jiffies - Convert nsecs in u64 to jiffies
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Handle inaccurate time conversion issues
On Fri, 28 Nov 2014, Daniel Vetter wrote: > So apparently jiffies<->nsec<->ktime isn't accurate or something. At > elast if we timeout there's occasionally still a few hundred us left > (in a 2 second timeout). > > Stuff I've tried and thrown out again: > - Sampling the before timestamp before jiffies. Doesn't improve test > path rate at all. > - Using jiffies. Way to inaccurate, which means way too much drift > with signals plus automatic ioctl restarting in userspace. In > hindsight we should have used an absolute timeout, but hey we need > something for v3 of the i915 gem wait interfaces ;-) > - Trying to figure out where accuracy gets lost. gl testcase really > don't care all that much about this (as long as isn't not massively > off), it's just that the testcase gets a bit upset if it receives an > EITME with timeout > 0. > > So as long as we're in the ballbark it's good enough. So patch > everything up if we're at most one jiffies off. I get's me a solid > test again. > > This regression is probably introduced in > > commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9 > Author: Thomas Gleixner > Date: Wed Jul 16 21:05:06 2014 + > > drm: i915: Use nsec based interfaces > > Use ktime_get_raw_ns() and get rid of the back and forth timespec > conversions. > > Signed-off-by: Thomas Gleixner > Acked-by: Daniel Vetter > Signed-off-by: John Stultz > > Probably because I'm too lazy to confirm myself and still waiting for > QA ;-) > > Cc: Thomas Gleixner > Cc: John Stultz > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749 > Signed-off-by: Daniel Vetter Pushed to drm-intel-next-fixes, thanks for the patch. BR, Jani. > --- > drivers/gpu/drm/i915/i915_gem.c | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 002730d1409b..abdc5bcdbd0d 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1302,6 +1302,16 @@ int __i915_wait_seqno(struct intel_engine_cs *ring, > u32 seqno, > s64 tres = *timeout - (now - before); > > *timeout = tres < 0 ? 0 : tres; > + > + /* > + * Apparently ktime isn't accurate enough and occasionally has a > + * bit of mismatch in the jiffies<->nsecs<->ktime loop. So patch > + * things up to make the test happy. We allow up to 1 jiffy. > + * > + * This is a regrssion from the timespec->ktime conversion. > + */ > + if (ret == -ETIME && *timeout < jiffies_to_usecs(1)*1000) > + *timeout = 0; > } > > return ret; > -- > 1.9.3 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: don't always do full mode sets when infoframes are enabled
On Fri, 05 Dec 2014, Daniel Vetter wrote: > On Thu, Dec 04, 2014 at 12:59:07PM -0800, Jesse Barnes wrote: >> On Mon, 1 Dec 2014 09:54:28 -0800 >> Jesse Barnes wrote: >> >> > Partial revert of >> > >> > commit 206645910b9796bff13fcdb67bdca166b724ba62 >> > Author: Jesse Barnes >> > Date: Wed Nov 5 14:26:09 2014 -0800 >> > >> > drm/i915: check for audio and infoframe changes across mode sets >> > v2 >> > >> > References: https://bugs.freedesktop.org/show_bug.cgi?id=86683 >> > Signed-off-by: Jesse Barnes >> > --- >> > drivers/gpu/drm/i915/intel_display.c | 10 ++ >> > 1 file changed, 6 insertions(+), 4 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_display.c >> > b/drivers/gpu/drm/i915/intel_display.c index 42bcbea..fe27a2c 100644 >> > --- a/drivers/gpu/drm/i915/intel_display.c >> > +++ b/drivers/gpu/drm/i915/intel_display.c >> > @@ -11601,10 +11601,12 @@ static int intel_crtc_set_config(struct >> > drm_mode_set *set) to_intel_crtc(set->crtc)->config.has_audio) >> >config->mode_changed = true; >> > >> > - /* Force mode sets for any infoframe stuff */ >> > - if (pipe_config->has_infoframe || >> > - to_intel_crtc(set->crtc)->config.has_infoframe) >> > - config->mode_changed = true; >> > + /* >> > + * Note we have an issue here with infoframes: >> > current code >> > + * only updates them on the full mode set path per hw >> > + * requirements. So here we should be checking for >> > any >> > + * required changes and forcing a mode set. >> > + */ >> >} >> > >> >/* set_mode will free it in the mode_changed case */ >> >> >> This got a tested-by from QA on the referenced bug, so I guess we >> should pick it up as the revert. >> >> Daniel? > > Sorry, fell through the cracks. Now it's for Jani to pick up since 3.20 is > already split away. I've pinged him. I've pushed this to drm-intel-next-queued last week. Thanks for the patch. BR, Jani. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't complain about stolen conflicts on gen3
On Fri, 05 Dec 2014, Daniel Vetter wrote:
> On Fri, Dec 05, 2014 at 10:30:47AM -0800, Jesse Barnes wrote:
>> On Fri, 11 Apr 2014 15:55:17 +0200
>> Daniel Vetter wrote:
>>
>> > Apparently stuff works that way on those machines.
>> >
>> > I agree with Chris' concern that this is a bit risky but imo worth a
>> > shot in -next just for fun. Afaics all these machines have the pci
>> > resources allocated like that by the BIOS, so I suspect that it's all
>> > ok.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031
>> > Tested-by: lu hua
>> > Signed-off-by: Daniel Vetter
>> > ---
>> > drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
>> > 1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c index
>> > 62ef55ba061c..99d147af173a 100644 ---
>> > a/drivers/gpu/drm/i915/i915_gem_stolen.c +++
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -93,7 +93,11 @@ static
>> > unsigned long i915_stolen_to_physical(struct drm_device *dev) r =
>> > devm_request_mem_region(dev->dev, base + 1, dev_priv->gtt.stolen_size
>> > - 1, "Graphics Stolen Memory");
>> > - if (r == NULL) {
>> > + /*
>> > + * GEN3 firmware likes to smash pci bridges into the
>> > stolen
>> > + * range. Apparently this works.
>> > + */
>> > + if (r == NULL && !IS_GEN3(dev)) {
>> >DRM_ERROR("conflict detected with stolen
>> > region: [0x%08x - 0x%08x]\n", base, base +
>> > (uint32_t)dev_priv->gtt.stolen_size); base = 0;
>>
>>
>> Yeah just to allay fears: the decode priority on the GMCH is fixed and
>> specific. The stolen range is demarcated by some regs which the GMCH
>> decodes before it tries going out into PCI space. So it's safe to see
>> the stolen range under the bus0 window (probably even under some device
>> window down the range) but does make things messier for us.
>>
>> Reviewed-by: Jesse Barnes
>>
>> Looks like the reporter gave a t-b too.
>
> The other t-b from the other bugzilla is missing though:
>
> Tested-by: Paul Menzel
> Cc: sta...@vger.kernel.org
>
> This regression goes back to
>
> commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09
> Author: Chris Wilson
> Date: Thu Jul 4 12:28:35 2013 +0100
>
> drm/i915: Verify that our stolen memory doesn't conflict
>
> Jani, can you please pick this up for 3.19?
Pushed to drm-intel-next-fixes, thanks for the patch and review.
BR,
Jani.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Get HW state changes required for DSI port C
On 12/8/2014 5:07 PM, Jani Nikula wrote:
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
Due to some hardware limitations, MIPI Port C DPI Enable bit
does not get set. To check whether DSI Port C was enabled in BIOS,
check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
is linked with Pipe B.
"due to some hardware limitations" is awfully vague. The same code will
be used on many platforms; I doubt this applies to all of them. Is there
a workaround name for this?
BR,
Jani.
Hi Jani,
This is currently only for BYT, I missed to add in this patch commit header.
Software workaround for getting the HW status of DSI Port C on BYT, will
it be fine if I include this in the commit header.
With regards,
Gaurav
Signed-off-by: Gaurav K Singh
---
drivers/gpu/drm/i915/intel_dsi.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 215d004..0334c4d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -398,8 +398,9 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
enum pipe *pipe)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
enum intel_display_power_domain power_domain;
- u32 port_ctl, func;
+ u32 dsi_status, func;
enum port port;
DRM_DEBUG_KMS("\n");
@@ -409,13 +410,23 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
return false;
/* XXX: this only works for one DSI output */
- for_each_dsi_port(port, (1 << PORT_A) | (1 << PORT_C)) {
- port_ctl = I915_READ(MIPI_PORT_CTRL(port));
+ for_each_dsi_port(port, intel_dsi->ports) {
func = I915_READ(MIPI_DSI_FUNC_PRG(port));
- if ((port_ctl & DPI_ENABLE) || (func & CMD_MODE_DATA_WIDTH_MASK)) {
+ /* Due to some hardware limitations, MIPI Port C DPI Enable
+* bit does not get set. To check whether DSI Port C was
+* enabled in BIOS, check the Pipe B enable bit
+*/
+ if (port == PORT_C)
+ dsi_status = I915_READ(PIPECONF(PIPE_B)) &
+ PIPECONF_ENABLE;
+ else
+ dsi_status = I915_READ(MIPI_PORT_CTRL(port)) &
+ DPI_ENABLE;
+
+ if (dsi_status || (func & CMD_MODE_DATA_WIDTH_MASK)) {
if (I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY) {
- *pipe = port == PORT_A ? PIPE_A : PIPE_C;
+ *pipe = port == PORT_A ? PIPE_A : PIPE_B;
return true;
}
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Get HW state changes required for DSI port C
On Mon, 08 Dec 2014, "Singh, Gaurav K" wrote:
> On 12/8/2014 5:07 PM, Jani Nikula wrote:
>> On Sun, 07 Dec 2014, Gaurav K Singh wrote:
>>> Due to some hardware limitations, MIPI Port C DPI Enable bit
>>> does not get set. To check whether DSI Port C was enabled in BIOS,
>>> check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
>>> is linked with Pipe B.
>> "due to some hardware limitations" is awfully vague. The same code will
>> be used on many platforms; I doubt this applies to all of them. Is there
>> a workaround name for this?
>>
>> BR,
>> Jani.
>
> Hi Jani,
>
> This is currently only for BYT, I missed to add in this patch commit header.
>
> Software workaround for getting the HW status of DSI Port C on BYT, will
> it be fine if I include this in the commit header.
No, it's not enough to amend the commit message. I prefer the
implementation to be generic for all platforms, and quirks like this
need to be special cases isolated as much as possible.
Please do something along the lines of:
port_ctl = I915_READ(MIPI_PORT_CTRL(port));
func = I915_READ(MIPI_DSI_FUNC_PRG(port));
dpi_enabled = port_ctl & DPI_ENABLE;
/* Due to some BYT hardware limitation ... etc... */
if (IS_VALLEYVIEW(dev) && !IS_CHERRYVIEW(dev) && port == PORT_C)
dpi_enabled = I915_READ(PIPECONF(PIPE_B)) & PIPECONF_ENABLE;
if (dpi_enabled || (func & CMD_MODE_DATA_WIDTH_MASK))
/* etc */
As you see, the exception clearly stands out, it's specific to BYT, and
it's easy to amend the condition or rip it out altogether as needed.
BR,
Jani.
>
> With regards,
> Gaurav
>>
>>> Signed-off-by: Gaurav K Singh
>>> ---
>>> drivers/gpu/drm/i915/intel_dsi.c | 21 -
>>> 1 file changed, 16 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
>>> b/drivers/gpu/drm/i915/intel_dsi.c
>>> index 215d004..0334c4d 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>>> @@ -398,8 +398,9 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
>>> *encoder,
>>>enum pipe *pipe)
>>> {
>>> struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
>>> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
>>> enum intel_display_power_domain power_domain;
>>> - u32 port_ctl, func;
>>> + u32 dsi_status, func;
>>> enum port port;
>>>
>>> DRM_DEBUG_KMS("\n");
>>> @@ -409,13 +410,23 @@ static bool intel_dsi_get_hw_state(struct
>>> intel_encoder *encoder,
>>> return false;
>>>
>>> /* XXX: this only works for one DSI output */
>>> - for_each_dsi_port(port, (1 << PORT_A) | (1 << PORT_C)) {
>>> - port_ctl = I915_READ(MIPI_PORT_CTRL(port));
>>> + for_each_dsi_port(port, intel_dsi->ports) {
>>> func = I915_READ(MIPI_DSI_FUNC_PRG(port));
>>>
>>> - if ((port_ctl & DPI_ENABLE) || (func &
>>> CMD_MODE_DATA_WIDTH_MASK)) {
>>> + /* Due to some hardware limitations, MIPI Port C DPI Enable
>>> +* bit does not get set. To check whether DSI Port C was
>>> +* enabled in BIOS, check the Pipe B enable bit
>>> +*/
>>> + if (port == PORT_C)
>>> + dsi_status = I915_READ(PIPECONF(PIPE_B)) &
>>> + PIPECONF_ENABLE;
>>> + else
>>> + dsi_status = I915_READ(MIPI_PORT_CTRL(port)) &
>>> + DPI_ENABLE;
>>> +
>>> + if (dsi_status || (func & CMD_MODE_DATA_WIDTH_MASK)) {
>>> if (I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY) {
>>> - *pipe = port == PORT_A ? PIPE_A : PIPE_C;
>>> + *pipe = port == PORT_A ? PIPE_A : PIPE_B;
>>> return true;
>>> }
>>> }
>>> --
>>> 1.7.9.5
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move golden context init into ->init_context
On 02/12/14 15:19, Daniel Vetter wrote:
> Similar to a patch from Thomas Daniel for lrc contexts. This keeps
> both sides somewhat in sync and should make Dave Gordon happy.
>
> Note that both the wa and the golden context init code suffer a bit
> from an inssuficient split into driver load and hw init code. Which
> means we have a bunch of tests all over the place to check whether the
> one-time initialization has been done already or not.
>
> All that one-tim code should be moved into the one-time ring setup
> code, but that's work for later.
>
> Cc: Dave Gordon
> Cc: Thomas Daniel
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 4
> drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +-
> 2 files changed, 17 insertions(+), 5 deletions(-)
LGTM :)
Reviewed-by: Dave Gordon
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5cd2b97aa76e..2acf5803cf32 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -651,10 +651,6 @@ done:
> if (ret)
> DRM_ERROR("ring init context: %d\n", ret);
> }
> -
> - ret = i915_gem_render_state_init(ring);
> - if (ret)
> - DRM_ERROR("init render state: %d\n", ret);
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 79b4ca5dc65f..79fe3d0a6442 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -710,6 +710,22 @@ static int intel_ring_workarounds_emit(struct
> intel_engine_cs *ring,
> return 0;
> }
>
> +static int intel_rcs_ctx_init(struct intel_engine_cs *ring,
> + struct intel_context *ctx)
> +{
> + int ret;
> +
> + ret = intel_ring_workarounds_emit(ring, ctx);
> + if (ret != 0)
> + return ret;
> +
> + ret = i915_gem_render_state_init(ring);
> + if (ret)
> + DRM_ERROR("init render state: %d\n", ret);
> +
> + return ret;
> +}
> +
> static int wa_add(struct drm_i915_private *dev_priv,
> const u32 addr, const u32 val, const u32 mask)
> {
> @@ -2341,7 +2357,7 @@ int intel_init_render_ring_buffer(struct drm_device
> *dev)
> }
> }
>
> - ring->init_context = intel_ring_workarounds_emit;
> + ring->init_context = intel_rcs_ctx_init;
> ring->add_request = gen6_add_request;
> ring->flush = gen8_render_ring_flush;
> ring->irq_get = gen8_ring_get_irq;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> > +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
>
> Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
> special cases of _MASKED_FIELD...? ;)
That's because we're not just enabling or disabling bits here but
setting a multi-bits value.
_MASKED_FIELD(2 << 4, 0x3 << 4);
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/20] drm/i915: fix misspelling of current function in string
On Mon, Dec 08, 2014 at 12:24:27PM +0200, Jani Nikula wrote: > On Sun, 07 Dec 2014, Julia Lawall wrote: > > Replace a misspelled function name by %s and then __func__. > > > > This was done using Coccinelle, including the use of Levenshtein distance, > > as proposed by Rasmus Villemoes. > > > > Signed-off-by: Julia Lawall > > > > --- > > The semantic patch is difficult to summarize, but is available in the cover > > letter of this patch series. > > > > The message is sort of ambiguous, but I assume that it is intended to refer > > to the function in which the problem is detected. > > Hmm, DRM_DEBUG prints __func__ too. We've killed the pin ioctl for 3.20 hence didn't even bother to come up with an opinion ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote: > 2014-12-08 6:42 GMT-02:00 Daniel Vetter : > > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: > >> Remove the function intel_output_name() that is not used anywhere. > >> > >> This was partially found by using a static code analysis program called > >> cppcheck. > >> > >> Signed-off-by: Rickard Strandqvist > > > > Queued for 3.20, thanks for the patch. > > This function was created for the "DDI personality" patches. We merged > the function but never ended up merging the patch containing the > callers... Oops, I've thought this is a renmant from the very first days of kms that somehow stuck around. That's what I get for once not using git blame excessively :( Want me to drop the patch again? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move golden context init into ->init_context
On Mon, Dec 08, 2014 at 01:51:01PM +, Dave Gordon wrote: > On 02/12/14 15:19, Daniel Vetter wrote: > > Similar to a patch from Thomas Daniel for lrc contexts. This keeps > > both sides somewhat in sync and should make Dave Gordon happy. > > > > Note that both the wa and the golden context init code suffer a bit > > from an inssuficient split into driver load and hw init code. Which > > means we have a bunch of tests all over the place to check whether the > > one-time initialization has been done already or not. > > > > All that one-tim code should be moved into the one-time ring setup > > code, but that's work for later. > > > > Cc: Dave Gordon > > Cc: Thomas Daniel > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/i915/i915_gem_context.c | 4 > > drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +- > > 2 files changed, 17 insertions(+), 5 deletions(-) > > LGTM :) > Reviewed-by: Dave Gordon Queued for -next, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On 08/12/14 13:59, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
>>> #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
>>> #define _MASKED_BIT_DISABLE(a) ((a) << 16)
>>> +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
>>
>> Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
>> special cases of _MASKED_FIELD...? ;)
>
> That's because we're not just enabling or disabling bits here but
> setting a multi-bits value.
>
> _MASKED_FIELD(2 << 4, 0x3 << 4);
>
So you could
#define __MASKED_BIT_DISABLE(a) (__MASKED_FIELD(0, (a)))
#define __MASKED_BIT_ENABLE(a) (__MASKED_FIELD((a), (a)))
which I think is what Jani was referring to ...
Bikeshed++: do we care about the double evaluation of (a) in these macros?
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 01:59:50PM +, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > > #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> > > +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
> >
> > Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
> > special cases of _MASKED_FIELD...? ;)
>
> That's because we're not just enabling or disabling bits here but
> setting a multi-bits value.
>
> _MASKED_FIELD(2 << 4, 0x3 << 4);
#define _MASKED_BIT_ENABLE(a) _MASKED_FIELD(a, a)
#define _MASKED_BIT_DISABLE(a) _MASKED_FIELD(a, 0)
is what I guess Jani thought of.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 03:21:02PM +0100, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 01:59:50PM +, Damien Lespiau wrote:
> > On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> > > > #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> > > > #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> > > > +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
> > >
> > > Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
> > > special cases of _MASKED_FIELD...? ;)
> >
> > That's because we're not just enabling or disabling bits here but
> > setting a multi-bits value.
> >
> > _MASKED_FIELD(2 << 4, 0x3 << 4);
>
> #define _MASKED_BIT_ENABLE(a) _MASKED_FIELD(a, a)
> #define _MASKED_BIT_DISABLE(a) _MASKED_FIELD(a, 0)
Ok and I right away screwed up the argument ordering in the DISABLE one
because the bits we set are before the mask. All the bitmasking functions
we have in e.g. i915_irq.c ilk_update_gt_irq so for consistency I think we
should flip it in this one here, too. Otherwise that bit of inconsistency
will trip up tons of people in the future.
Jani, can you please apply that fixup if Damien acks it?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 03:23:49PM +0100, Daniel Vetter wrote: > > #define _MASKED_BIT_ENABLE(a) _MASKED_FIELD(a, a) > > #define _MASKED_BIT_DISABLE(a) _MASKED_FIELD(a, 0) > > Ok and I right away screwed up the argument ordering in the DISABLE one > because the bits we set are before the mask. All the bitmasking functions > we have in e.g. i915_irq.c ilk_update_gt_irq so for consistency I think we > should flip it in this one here, too. Otherwise that bit of inconsistency > will trip up tons of people in the future. > > Jani, can you please apply that fixup if Damien acks it? (for the record ack'ed) -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 02:17:45PM +, Dave Gordon wrote:
> On 08/12/14 13:59, Damien Lespiau wrote:
> > On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
> >>> #define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> >>> #define _MASKED_BIT_DISABLE(a) ((a) << 16)
> >>> +#define _MASKED_FIELD(value, mask) (((mask) << 16) | (value))
> >>
> >> Obligatory bikeshed, wouldn't you say _MASKED_BIT_{ENABLE,DISABLE} are
> >> special cases of _MASKED_FIELD...? ;)
> >
> > That's because we're not just enabling or disabling bits here but
> > setting a multi-bits value.
> >
> > _MASKED_FIELD(2 << 4, 0x3 << 4);
> >
>
> So you could
>
> #define __MASKED_BIT_DISABLE(a) (__MASKED_FIELD(0, (a)))
> #define __MASKED_BIT_ENABLE(a) (__MASKED_FIELD((a), (a)))
>
> which I think is what Jani was referring to ...
>
> Bikeshed++: do we care about the double evaluation of (a) in these macros?
Oh of course, misread that. We could also avoid the double evaluation
indeed and chris suggests (on IRC) BUILD_BUG_ON(bit & ~mask); (super
good!)
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: s/MI_STORE_DWORD_IMM_GEN8/MI_STORE_DWORD_IMM_GEN4/
On 05/12/14 12:51, Ville Syrjälä wrote: > On Fri, Nov 14, 2014 at 06:16:56PM +0200, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename >> the define to avoid potential confusion if someone tries to use this >> on pre-gen8. >> >> Also correct the comment on MI_MEM_VIRTUAL bit. It's present on 945,g33 >> and 965 only. >> >> Cc: Oscar Mateo >> Signed-off-by: Ville Syrjälä > > ping > >> --- >> drivers/gpu/drm/i915/i915_reg.h | 4 ++-- >> drivers/gpu/drm/i915/intel_lrc.c | 2 +- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index 3de58ac..5228493 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -280,8 +280,8 @@ >> #define MI_SEMAPHORE_POLL (1<<15) >> #define MI_SEMAPHORE_SAD_GTE_SDD (1<<12) >> #define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1) >> -#define MI_STORE_DWORD_IMM_GEN8 MI_INSTR(0x20, 2) >> -#define MI_MEM_VIRTUAL(1 << 22) /* 965+ only */ >> +#define MI_STORE_DWORD_IMM_GEN4 MI_INSTR(0x20, 2) >> +#define MI_MEM_VIRTUAL(1 << 22) /* 945,g33,965 */ >> #define MI_STORE_DWORD_INDEXMI_INSTR(0x21, 1) >> #define MI_STORE_DWORD_INDEX_SHIFT 2 >> /* Official intel docs are somewhat sloppy concerning MI_LOAD_REGISTER_IMM: >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c >> b/drivers/gpu/drm/i915/intel_lrc.c >> index 6025ac7..649d9ba 100644 >> --- a/drivers/gpu/drm/i915/intel_lrc.c >> +++ b/drivers/gpu/drm/i915/intel_lrc.c >> @@ -1188,7 +1188,7 @@ static int gen8_emit_request(struct intel_ringbuffer >> *ringbuf) >> if (ret) >> return ret; >> >> -cmd = MI_STORE_DWORD_IMM_GEN8; >> +cmd = MI_STORE_DWORD_IMM_GEN4; >> cmd |= MI_GLOBAL_GTT; >> >> intel_logical_ring_emit(ringbuf, cmd); >> -- >> 2.0.4 The GEN8->GEN4 change looks sensible to me. But I was puzzled over the definition of MI_STORE_DWORD_IMM -- presumably this apparently more generic definition is actually a pre-GEN4 legacy from the days when the instruction had only 3 words? Perhaps a comment here from somebody who knows -- or even something like #define MI_STORE_DWORD_IMM_LEGACY MI_INSTR(0x20, 1) /* pre-GEN4 */ #define MI_STORE_DWORD_IMM_GEN4 MI_INSTR(0x20, 2) /* GEN4+ */ #define MI_STORE_DWORD_IMM MI_STORE_DWORD_IMM_LEGACY /* for source backward compatibility */ so it's clearer that (for now) the generic definition is actually the legacy one. The above bikeshedding notwithstanding, it gets my R-b anyway: Reviewed-by: Dave Gordon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
After a bit of irc discussion we've concluded that it would be prudent
to check that callers use the mask/enable paramters correctly. So add
a WARN_ON.
Now most callers have static parameters, so even better would be if we
could bug at compile-time. Hence improve the i915 WARN_ON to
BUILD_BUG_ON if the condition can be statically determined. Thanks to
Chris for this suggestion.
All this spurred by Damien's bugfix which added _MASKED_FIELD.
Cc: Damien Lespiau
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gpu/drm/i915/i915_irq.c | 6 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..e5d9d6642b09 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,8 +57,15 @@
#define DRIVER_DESC"Intel Graphics"
#define DRIVER_DATE"20141205"
+static inline bool __i915_warn_on(bool cond, const char *str)
+{
+ if (__builtin_constant_p(cond))
+ BUILD_BUG_ON(cond);
+ return WARN(cond, str);
+}
+
#undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+#define WARN_ON(x) __i915_warn_on((x), "WARN_ON(" #x ")")
enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 08a5a4ba52ac..e6a1db36928e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
*dev_priv,
{
assert_spin_locked(&dev_priv->irq_lock);
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
if (WARN_ON(!intel_irqs_enabled(dev_priv)))
return;
@@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
*dev_priv,
{
uint32_t new_val;
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
assert_spin_locked(&dev_priv->irq_lock);
new_val = dev_priv->pm_irq_mask;
@@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct drm_i915_private
*dev_priv,
sdeimr &= ~interrupt_mask;
sdeimr |= (~enabled_irq_mask & interrupt_mask);
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
assert_spin_locked(&dev_priv->irq_lock);
if (WARN_ON(!intel_irqs_enabled(dev_priv)))
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, Dec 08, 2014 at 04:00:29PM +0100, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Now most callers have static parameters, so even better would be if we
> could bug at compile-time. Hence improve the i915 WARN_ON to
> BUILD_BUG_ON if the condition can be statically determined. Thanks to
> Chris for this suggestion.
>
> All this spurred by Damien's bugfix which added _MASKED_FIELD.
>
> Cc: Damien Lespiau
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 95dfa2dd35b9..e5d9d6642b09 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -57,8 +57,15 @@
> #define DRIVER_DESC "Intel Graphics"
> #define DRIVER_DATE "20141205"
>
> +static inline bool __i915_warn_on(bool cond, const char *str)
> +{
> + if (__builtin_constant_p(cond))
> + BUILD_BUG_ON(cond);
> + return WARN(cond, str);
> +}
- Can we have BUILD_BUG_ON_MSG()?
- We could avoid emitting the WARN() part if __builtin_constant_p() is
true, we don't really need to run-time code in there in that case.
> #undef WARN_ON
> -#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
> +#define WARN_ON(x) __i915_warn_on((x), "WARN_ON(" #x ")")
>
> enum pipe {
> INVALID_PIPE = -1,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 08a5a4ba52ac..e6a1db36928e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
> *dev_priv,
> {
> assert_spin_locked(&dev_priv->irq_lock);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> return;
>
> @@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
> *dev_priv,
> {
> uint32_t new_val;
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> new_val = dev_priv->pm_irq_mask;
> @@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct drm_i915_private
> *dev_priv,
> sdeimr &= ~interrupt_mask;
> sdeimr |= (~enabled_irq_mask & interrupt_mask);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> --
> 2.1.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, 08 Dec 2014, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Now most callers have static parameters, so even better would be if we
> could bug at compile-time. Hence improve the i915 WARN_ON to
> BUILD_BUG_ON if the condition can be statically determined. Thanks to
> Chris for this suggestion.
>
> All this spurred by Damien's bugfix which added _MASKED_FIELD.
>
> Cc: Damien Lespiau
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 -
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 95dfa2dd35b9..e5d9d6642b09 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -57,8 +57,15 @@
> #define DRIVER_DESC "Intel Graphics"
> #define DRIVER_DATE "20141205"
>
> +static inline bool __i915_warn_on(bool cond, const char *str)
> +{
> + if (__builtin_constant_p(cond))
> + BUILD_BUG_ON(cond);
> + return WARN(cond, str);
Won't this screw up the __FILE__ and __LINE__ in the backtrace?
BR,
Jani.
> +}
> +
> #undef WARN_ON
> -#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
> +#define WARN_ON(x) __i915_warn_on((x), "WARN_ON(" #x ")")
>
> enum pipe {
> INVALID_PIPE = -1,
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 08a5a4ba52ac..e6a1db36928e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
> *dev_priv,
> {
> assert_spin_locked(&dev_priv->irq_lock);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> return;
>
> @@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
> *dev_priv,
> {
> uint32_t new_val;
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> new_val = dev_priv->pm_irq_mask;
> @@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct drm_i915_private
> *dev_priv,
> sdeimr &= ~interrupt_mask;
> sdeimr |= (~enabled_irq_mask & interrupt_mask);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, Dec 8, 2014 at 4:14 PM, Damien Lespiau wrote:
> On Mon, Dec 08, 2014 at 04:00:29PM +0100, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Now most callers have static parameters, so even better would be if we
>> could bug at compile-time. Hence improve the i915 WARN_ON to
>> BUILD_BUG_ON if the condition can be statically determined. Thanks to
>> Chris for this suggestion.
>>
>> All this spurred by Damien's bugfix which added _MASKED_FIELD.
>>
>> Cc: Damien Lespiau
>> Cc: Chris Wilson
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 9 -
>> drivers/gpu/drm/i915/i915_irq.c | 6 ++
>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 95dfa2dd35b9..e5d9d6642b09 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -57,8 +57,15 @@
>> #define DRIVER_DESC "Intel Graphics"
>> #define DRIVER_DATE "20141205"
>>
>> +static inline bool __i915_warn_on(bool cond, const char *str)
>> +{
>> + if (__builtin_constant_p(cond))
>> + BUILD_BUG_ON(cond);
>> + return WARN(cond, str);
>> +}
>
> - Can we have BUILD_BUG_ON_MSG()?
We added the message for fighting slight discrepancies between a bug
reporters and developers source tree. If you build locally and
actually hit the BUILD_BUG gcc will dump you the entire
preprocessor/macro chain and so precisely tell you where you've
screwed up. So imo no need for this.
> - We could avoid emitting the WARN() part if __builtin_constant_p() is
> true, we don't really need to run-time code in there in that case.
When compilation fails it doesn't really matter what we do - you'll
never see that WARN_ON getting executed. And we need to return
something to avoid pissing up gcc early (i.e. before it'll see that
it's dead code), so doing an else WARN(); doesn't actually save any
lines at all.
-Daniel
>
>> #undef WARN_ON
>> -#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
>> +#define WARN_ON(x) __i915_warn_on((x), "WARN_ON(" #x ")")
>>
>> enum pipe {
>> INVALID_PIPE = -1,
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 08a5a4ba52ac..e6a1db36928e 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
>> *dev_priv,
>> {
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
>> return;
>>
>> @@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
>> *dev_priv,
>> {
>> uint32_t new_val;
>>
>> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> new_val = dev_priv->pm_irq_mask;
>> @@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct
>> drm_i915_private *dev_priv,
>> sdeimr &= ~interrupt_mask;
>> sdeimr |= (~enabled_irq_mask & interrupt_mask);
>>
>> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
>> --
>> 2.1.1
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, Dec 8, 2014 at 4:18 PM, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Now most callers have static parameters, so even better would be if we
>> could bug at compile-time. Hence improve the i915 WARN_ON to
>> BUILD_BUG_ON if the condition can be statically determined. Thanks to
>> Chris for this suggestion.
>>
>> All this spurred by Damien's bugfix which added _MASKED_FIELD.
>>
>> Cc: Damien Lespiau
>> Cc: Chris Wilson
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 9 -
>> drivers/gpu/drm/i915/i915_irq.c | 6 ++
>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 95dfa2dd35b9..e5d9d6642b09 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -57,8 +57,15 @@
>> #define DRIVER_DESC "Intel Graphics"
>> #define DRIVER_DATE "20141205"
>>
>> +static inline bool __i915_warn_on(bool cond, const char *str)
>> +{
>> + if (__builtin_constant_p(cond))
>> + BUILD_BUG_ON(cond);
>> + return WARN(cond, str);
>
> Won't this screw up the __FILE__ and __LINE__ in the backtrace
It will. Back to the drawing board :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 4/8] drm/i915: Use local pipe_config varariable when available
In function that define a local pipe_config variable to point to
crtc->config, replace remaining references to crtc->config with
the local variable. This makes the code more consistent and easier
to change in an automated manner.
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3bceacb..da5af23 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4602,7 +4602,7 @@ static void i9xx_pfit_enable(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_state *pipe_config = &crtc->config;
- if (!crtc->config.gmch_pfit.control)
+ if (!pipe_config->gmch_pfit.control)
return;
/*
@@ -5925,7 +5925,7 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW10(pipe),
0x00df);
- if (crtc->config.has_dp_encoder) {
+ if (pipe_config->has_dp_encoder) {
/* Use SSC source */
if (pipe == PIPE_A)
vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW5(pipe),
@@ -7541,7 +7541,7 @@ static void intel_cpu_transcoder_get_m_n(struct
intel_crtc *crtc,
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
- if (crtc->config.has_pch_encoder)
+ if (pipe_config->has_pch_encoder)
intel_pch_transcoder_get_m_n(crtc, &pipe_config->dp_m_n);
else
intel_cpu_transcoder_get_m_n(crtc, pipe_config->cpu_transcoder,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 3/8] drm/i915: Pass new_config down do crtc_compute_clock
This reduces the number of direct users of crtc->new_config. At some
point we'll be able to get rid of that pointer altogether, in favor
of drm core state structs.
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_ddi.c | 29
drivers/gpu/drm/i915/intel_display.c | 131 +++
drivers/gpu/drm/i915/intel_drv.h | 6 +-
4 files changed, 94 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d60d38..c1a9af9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -500,7 +500,8 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *);
void (*get_plane_config)(struct intel_crtc *,
struct intel_plane_config *);
- int (*crtc_compute_clock)(struct intel_crtc *crtc);
+ int (*crtc_compute_clock)(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
void (*off)(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 79c9776..970ca30 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -904,6 +904,7 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
static bool
hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *crtc_state,
struct intel_encoder *intel_encoder,
int clock)
{
@@ -918,16 +919,16 @@ hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
WRPLL_DIVIDER_POST(p);
- intel_crtc->new_config->dpll_hw_state.wrpll = val;
+ crtc_state->dpll_hw_state.wrpll = val;
- pll = intel_get_shared_dpll(intel_crtc);
+ pll = intel_get_shared_dpll(intel_crtc, crtc_state);
if (pll == NULL) {
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
pipe_name(intel_crtc->pipe));
return false;
}
- intel_crtc->new_config->ddi_pll_sel =
PORT_CLK_SEL_WRPLL(pll->id);
+ crtc_state->ddi_pll_sel = PORT_CLK_SEL_WRPLL(pll->id);
}
return true;
@@ -1090,6 +1091,7 @@ found:
static bool
skl_ddi_pll_select(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *crtc_state,
struct intel_encoder *intel_encoder,
int clock)
{
@@ -1139,11 +1141,11 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
} else /* eDP */
return true;
- intel_crtc->new_config->dpll_hw_state.ctrl1 = ctrl1;
- intel_crtc->new_config->dpll_hw_state.cfgcr1 = cfgcr1;
- intel_crtc->new_config->dpll_hw_state.cfgcr2 = cfgcr2;
+ crtc_state->dpll_hw_state.ctrl1 = ctrl1;
+ crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
+ crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
- pll = intel_get_shared_dpll(intel_crtc);
+ pll = intel_get_shared_dpll(intel_crtc, crtc_state);
if (pll == NULL) {
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
pipe_name(intel_crtc->pipe));
@@ -1151,7 +1153,7 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
}
/* shared DPLL id 0 is DPLL 1 */
- intel_crtc->new_config->ddi_pll_sel = pll->id + 1;
+ crtc_state->ddi_pll_sel = pll->id + 1;
return true;
}
@@ -1163,17 +1165,20 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
* For private DPLLs, compute_config() should do the selection for us. This
* function should be folded into compute_config() eventually.
*/
-bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
+bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
+ struct intel_crtc_state *crtc_state)
{
struct drm_device *dev = intel_crtc->base.dev;
struct intel_encoder *intel_encoder =
intel_ddi_get_crtc_new_encoder(intel_crtc);
- int clock = intel_crtc->new_config->port_clock;
+ int clock = crtc_state->port_clock;
if (IS_SKYLAKE(dev))
- return skl_ddi_pll_select(intel_crtc, intel_encoder, clock);
+ return skl_ddi_pll_select(intel_crtc, crtc_state,
+ intel_encoder, clock);
else
- return hsw_ddi_pll_select(intel_crtc, intel_encoder, clock);
+ return hsw_ddi_pll_select(intel_crtc, crtc_state,
+ intel_encoder, clock);
}
void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i
[Intel-gfx] [RFC][PATCH 5/8] drm/i915: Don't access to crtc->new_config from intel_mode_max_pixclk()
So that we can get rid of the new_config pointer later.
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index da5af23..a9f3034 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4897,27 +4897,39 @@ static int valleyview_calc_cdclk(struct
drm_i915_private *dev_priv,
}
/* compute the max pixel clock for new configuration */
-static int intel_mode_max_pixclk(struct drm_i915_private *dev_priv)
+static int intel_mode_max_pixclk(struct drm_i915_private *dev_priv,
+struct intel_crtc *mode_set_crtc,
+struct intel_crtc_state *crtc_new_state)
{
struct drm_device *dev = dev_priv->dev;
struct intel_crtc *intel_crtc;
int max_pixclk = 0;
+ int pixclk;
for_each_intel_crtc(dev, intel_crtc) {
- if (intel_crtc->new_enabled)
- max_pixclk = max(max_pixclk,
-
intel_crtc->new_config->base.adjusted_mode.crtc_clock);
+ if (!intel_crtc->new_enabled)
+ continue;
+
+ if (intel_crtc == mode_set_crtc)
+ pixclk = crtc_new_state->base.adjusted_mode.crtc_clock;
+ else
+ pixclk =
intel_crtc->config->base.adjusted_mode.crtc_clock;
+
+ max_pixclk = max(max_pixclk, pixclk);
}
return max_pixclk;
}
static void valleyview_modeset_global_pipes(struct drm_device *dev,
- unsigned *prepare_pipes)
+ unsigned *prepare_pipes,
+ struct intel_crtc *mode_set_crtc,
+ struct intel_crtc_state
*crtc_new_state)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc;
- int max_pixclk = intel_mode_max_pixclk(dev_priv);
+ int max_pixclk =
+ intel_mode_max_pixclk(dev_priv, mode_set_crtc, crtc_new_state);
if (valleyview_calc_cdclk(dev_priv, max_pixclk) ==
dev_priv->vlv_cdclk_freq)
@@ -4932,7 +4944,7 @@ static void valleyview_modeset_global_pipes(struct
drm_device *dev,
static void valleyview_modeset_global_resources(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- int max_pixclk = intel_mode_max_pixclk(dev_priv);
+ int max_pixclk = intel_mode_max_pixclk(dev_priv, NULL, NULL);
int req_cdclk = valleyview_calc_cdclk(dev_priv, max_pixclk);
if (req_cdclk != dev_priv->vlv_cdclk_freq) {
@@ -10956,7 +10968,9 @@ static int __intel_set_mode(struct drm_crtc *crtc,
* adjusted_mode bits in the crtc directly.
*/
if (IS_VALLEYVIEW(dev)) {
- valleyview_modeset_global_pipes(dev, &prepare_pipes);
+ valleyview_modeset_global_pipes(dev, &prepare_pipes,
+ to_intel_crtc(crtc),
+ pipe_config);
/* may have added more to prepare_pipes than we should */
prepare_pipes &= ~disable_pipes;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 6/8] drm/i915: Remove intel_crtc->new_config pointer
There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (state) should be derived from an
atomic state structure.
---
drivers/gpu/drm/i915/intel_display.c | 46
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 10 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a9f3034..a032a1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8583,7 +8583,6 @@ retry:
intel_crtc = to_intel_crtc(crtc);
intel_crtc->new_enabled = true;
- intel_crtc->new_config = &intel_crtc->config;
old->dpms_mode = connector->dpms;
old->load_detect_temp = true;
old->release_fb = NULL;
@@ -8623,10 +8622,6 @@ retry:
fail:
intel_crtc->new_enabled = crtc->enabled;
- if (intel_crtc->new_enabled)
- intel_crtc->new_config = &intel_crtc->config;
- else
- intel_crtc->new_config = NULL;
fail_unlock:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
@@ -8653,7 +8648,6 @@ void intel_release_load_detect_pipe(struct drm_connector
*connector,
to_intel_connector(connector)->new_encoder = NULL;
intel_encoder->new_crtc = NULL;
intel_crtc->new_enabled = false;
- intel_crtc->new_config = NULL;
intel_set_mode(crtc, NULL, 0, 0, NULL);
if (old->release_fb) {
@@ -9839,14 +9833,8 @@ static void
intel_modeset_update_staged_output_state(struct drm_device *dev)
to_intel_crtc(encoder->base.crtc);
}
- for_each_intel_crtc(dev, crtc) {
+ for_each_intel_crtc(dev, crtc)
crtc->new_enabled = crtc->base.enabled;
-
- if (crtc->new_enabled)
- crtc->new_config = &crtc->config;
- else
- crtc->new_config = NULL;
- }
}
/**
@@ -10355,12 +10343,8 @@ intel_modeset_update_state(struct drm_device *dev,
unsigned prepare_pipes)
intel_modeset_commit_output_state(dev);
/* Double check state. */
- for_each_intel_crtc(dev, intel_crtc) {
+ for_each_intel_crtc(dev, intel_crtc)
WARN_ON(intel_crtc->base.enabled !=
intel_crtc_in_use(&intel_crtc->base));
- WARN_ON(intel_crtc->new_config &&
- intel_crtc->new_config != &intel_crtc->config);
- WARN_ON(intel_crtc->base.enabled != !!intel_crtc->new_config);
- }
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (!connector->encoder || !connector->encoder->crtc)
@@ -10957,9 +10941,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
*saved_mode = crtc->mode;
- if (modeset_pipes)
- to_intel_crtc(crtc)->new_config = pipe_config;
-
/*
* See if the config requires any additional preparation, e.g.
* to adjust global state with pipes off. We need to do this
@@ -10984,7 +10965,13 @@ static int __intel_set_mode(struct drm_crtc *crtc,
goto done;
for_each_intel_crtc_masked(dev, modeset_pipes, intel_crtc) {
- struct intel_crtc_state *state = intel_crtc->new_config;
+ struct intel_crtc_state *state;
+
+ if (&intel_crtc->base == crtc)
+ state = pipe_config;
+ else
+ state = intel_crtc->config;
+
ret = dev_priv->display.crtc_compute_clock(intel_crtc,
state);
if (ret) {
@@ -11014,7 +11001,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
/* mode_set/enable/disable functions rely on a correct pipe
* config. */
to_intel_crtc(crtc)->config = *pipe_config;
- to_intel_crtc(crtc)->new_config = &to_intel_crtc(crtc)->config;
/*
* Calculate and store various constants which
@@ -11177,15 +11163,9 @@ static void intel_set_config_restore_state(struct
drm_device *dev,
int count;
count = 0;
- for_each_intel_crtc(dev, crtc) {
+ for_each_intel_crtc(dev, crtc)
crtc->new_enabled = config->save_crtc_enabled[count++];
- if (crtc->new_enabled)
- crtc->new_config = &crtc->config;
- else
- crtc->new_config = NULL;
- }
-
count = 0;
for_each_intel_encoder(dev, encoder) {
encoder->new_crtc =
@@ -11391,11 +11371,6 @@ intel_modeset_stage_output_state(struct drm_device
*dev,
[Intel-gfx] [RFC][PATCH 8/8] drm/i915: Keep drm_crtc->state in sync with intel_crtc->config
So that atomic operations will reference the right crtc state.
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 462f22a..20b9e9b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10926,6 +10926,7 @@ static void intel_crtc_set_state(struct intel_crtc
*crtc,
{
kfree(crtc->config);
crtc->config = crtc_state;
+ crtc->base.state = &crtc_state->base;
}
static int __intel_set_mode(struct drm_crtc *crtc,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 7/8] drm/i915: Make intel_crtc->config a pointer
To match the semantics of drm_crtc->state, which this will eventually
become. Following coccinelle script did most of the work.
@@ struct intel_crtc *crtc; @@
-&crtc->config
+crtc->config
@@ struct intel_crtc *crtc; identifier member; @@
-crtc->config.member
+crtc->config->member
@@ struct drm_crtc *crtc; @@
-&to_intel_crtc(crtc)->config
+to_intel_crtc(crtc)->config
@@ struct drm_crtc *crtc; identifier member; @@
-to_intel_crtc(crtc)->config.member
+to_intel_crtc(crtc)->config->member
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_irq.c | 8 +-
drivers/gpu/drm/i915/intel_audio.c | 2 +-
drivers/gpu/drm/i915/intel_crt.c | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 52 +++
drivers/gpu/drm/i915/intel_display.c | 275 ++-
drivers/gpu/drm/i915/intel_dp.c | 16 +-
drivers/gpu/drm/i915/intel_dp_mst.c | 7 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dsi.c | 8 +-
drivers/gpu/drm/i915/intel_dvo.c | 8 +-
drivers/gpu/drm/i915/intel_fbdev.c | 10 +-
drivers/gpu/drm/i915/intel_hdmi.c| 36 ++---
drivers/gpu/drm/i915/intel_lvds.c| 6 +-
drivers/gpu/drm/i915/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 56 +++
drivers/gpu/drm/i915/intel_psr.c | 8 +-
drivers/gpu/drm/i915/intel_sdvo.c| 14 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
19 files changed, 270 insertions(+), 256 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445e..a724e8c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2572,7 +2572,7 @@ static int i915_display_info(struct seq_file *m, void
*unused)
seq_printf(m, "CRTC %d: pipe: %c, active=%s (size=%dx%d)\n",
crtc->base.base.id, pipe_name(crtc->pipe),
- yesno(crtc->active), crtc->config.pipe_src_w,
crtc->config.pipe_src_h);
+ yesno(crtc->active), crtc->config->pipe_src_w,
crtc->config->pipe_src_h);
if (crtc->active) {
intel_crtc_info(m, crtc);
@@ -3280,9 +3280,9 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct drm_device
*dev)
* relevant on hsw with pipe A when using the always-on power well
* routing.
*/
- if (crtc->config.cpu_transcoder == TRANSCODER_EDP &&
- !crtc->config.pch_pfit.enabled) {
- crtc->config.pch_pfit.force_thru = true;
+ if (crtc->config->cpu_transcoder == TRANSCODER_EDP &&
+ !crtc->config->pch_pfit.enabled) {
+ crtc->config->pch_pfit.force_thru = true;
intel_display_power_get(dev_priv,
POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
@@ -3306,8 +3306,8 @@ static void hsw_undo_trans_edp_pipe_A_crc_wa(struct
drm_device *dev)
* relevant on hsw with pipe A when using the always-on power well
* routing.
*/
- if (crtc->config.pch_pfit.force_thru) {
- crtc->config.pch_pfit.force_thru = false;
+ if (crtc->config->pch_pfit.force_thru) {
+ crtc->config->pch_pfit.force_thru = false;
dev_priv->display.crtc_disable(&crtc->base);
dev_priv->display.crtc_enable(&crtc->base);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 11e209e..e55b275 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -567,7 +567,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev,
int pipe)
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
const struct drm_display_mode *mode =
- &intel_crtc->config.base.adjusted_mode;
+ &intel_crtc->config->base.adjusted_mode;
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
@@ -638,7 +638,7 @@ static int __intel_get_crtc_scanline(struct intel_crtc
*crtc)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- const struct drm_display_mode *mode = &crtc->config.base.adjusted_mode;
+ const struct drm_display_mode *mode = &crtc->config->base.adjusted_mode;
enum pipe pipe = crtc->pipe;
int position, vtotal;
@@ -665,7 +665,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device *dev,
int pipe,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- const struct drm_display_mode *mode =
&intel_crtc->config.base.adjusted_mode;
+ const struct drm_display_mode *mode =
&intel_crtc->config->base.adjusted_mode;
int positio
[Intel-gfx] [RFC][PATCH 1/8] drm/i915: Rename struct intel_crtc_config to intel_crtc_state
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_crt.c | 6 +--
drivers/gpu/drm/i915/intel_ddi.c | 10 ++--
drivers/gpu/drm/i915/intel_display.c | 100 +--
drivers/gpu/drm/i915/intel_dp.c | 12 ++---
drivers/gpu/drm/i915/intel_dp_mst.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 28 +-
drivers/gpu/drm/i915/intel_dsi.c | 4 +-
drivers/gpu/drm/i915/intel_dvo.c | 6 +--
drivers/gpu/drm/i915/intel_hdmi.c| 4 +-
drivers/gpu/drm/i915/intel_lvds.c| 4 +-
drivers/gpu/drm/i915/intel_panel.c | 8 +--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c| 6 +--
drivers/gpu/drm/i915/intel_tv.c | 4 +-
15 files changed, 101 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11e85cb..7d60d38 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -458,7 +458,7 @@ struct drm_i915_error_state {
struct intel_connector;
struct intel_encoder;
-struct intel_crtc_config;
+struct intel_crtc_state;
struct intel_plane_config;
struct intel_crtc;
struct intel_limit;
@@ -497,7 +497,7 @@ struct drm_i915_display_funcs {
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */
bool (*get_pipe_config)(struct intel_crtc *,
- struct intel_crtc_config *);
+ struct intel_crtc_state *);
void (*get_plane_config)(struct intel_crtc *,
struct intel_plane_config *);
int (*crtc_compute_clock)(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index a9af9a4..675b85a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -110,7 +110,7 @@ static unsigned int intel_crt_get_flags(struct
intel_encoder *encoder)
}
static void intel_crt_get_config(struct intel_encoder *encoder,
-struct intel_crtc_config *pipe_config)
+struct intel_crtc_state *pipe_config)
{
struct drm_device *dev = encoder->base.dev;
int dotclock;
@@ -126,7 +126,7 @@ static void intel_crt_get_config(struct intel_encoder
*encoder,
}
static void hsw_crt_get_config(struct intel_encoder *encoder,
- struct intel_crtc_config *pipe_config)
+ struct intel_crtc_state *pipe_config)
{
intel_ddi_get_config(encoder, pipe_config);
@@ -303,7 +303,7 @@ intel_crt_mode_valid(struct drm_connector *connector,
}
static bool intel_crt_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_config *pipe_config)
+struct intel_crtc_state *pipe_config)
{
struct drm_device *dev = encoder->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4e2e860..9d69b61 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -732,7 +732,7 @@ static int skl_calc_wrpll_link(struct drm_i915_private
*dev_priv,
static void skl_ddi_clock_get(struct intel_encoder *encoder,
- struct intel_crtc_config *pipe_config)
+ struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
int link_clock = 0;
@@ -776,7 +776,7 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder,
}
static void hsw_ddi_clock_get(struct intel_encoder *encoder,
- struct intel_crtc_config *pipe_config)
+ struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
int link_clock = 0;
@@ -832,7 +832,7 @@ static void hsw_ddi_clock_get(struct intel_encoder *encoder,
}
void intel_ddi_clock_get(struct intel_encoder *encoder,
-struct intel_crtc_config *pipe_config)
+struct intel_crtc_state *pipe_config)
{
hsw_ddi_clock_get(encoder, pipe_config);
}
@@ -2022,7 +2022,7 @@ static void intel_ddi_hot_plug(struct intel_encoder
*intel_encoder)
}
void intel_ddi_get_config(struct intel_encoder *encoder,
- struct intel_crtc_config *pipe_config)
+ struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
@@ -2119,7 +2119,7 @@ st
Re: [Intel-gfx] [PATCH v5 1/7] drm/i915: Implement a framework for batch buffer pools
> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, November 26, 2014 9:54 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Bloomfield, Jon; Volkin, Bradley D
> Subject: [PATCH v5 1/7] drm/i915: Implement a framework for batch buffer
> pools
>
> From: Brad Volkin
>
> This adds a small module for managing a pool of batch buffers.
> The only current use case is for the command parser, as described in the
> kerneldoc in the patch. The code is simple, but separating it out makes it
> easier to change the underlying algorithms and to extend to future use cases
> should they arise.
>
> The interface is simple: init to create an empty pool, fini to clean it up,
> get to
> obtain a new buffer. Note that all buffers are expected to be inactive before
> cleaning up the pool.
>
> Locking is currently based on the caller holding the struct_mutex.
> We already do that in the places where we will use the batch pool for the
> command parser.
>
> v2:
> - s/BUG_ON/WARN_ON/ for locking assertions
> - Remove the cap on pool size
> - Switch from alloc/free to init/fini
>
> v3:
> - Idiomatic looping structure in _fini
> - Correct handling of purged objects
> - Don't return a buffer that's too much larger than needed
>
> v4:
> - Rebased to latest -nightly
>
> v5:
> - Remove _put() function and clean up comments to match
>
> v6:
> - Move purged check inside the loop (danvet, from v4 1/7 feedback)
>
> Issue: VIZ-4719
> Signed-off-by: Brad Volkin
> ---
> Documentation/DocBook/drm.tmpl | 5 +
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_drv.h| 15 +++
> drivers/gpu/drm/i915/i915_gem.c| 1 +
> drivers/gpu/drm/i915/i915_gem_batch_pool.c | 152
> +
> 5 files changed, 174 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c
>
> diff --git a/Documentation/DocBook/drm.tmpl
> b/Documentation/DocBook/drm.tmpl index 944e8ed..b5943d4 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -4028,6 +4028,11 @@ int num_ioctls;
> !Idrivers/gpu/drm/i915/i915_cmd_parser.c
>
>
> +Batchbuffer Pools
> +!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
> +!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
> +
> +
> Logical Rings, Logical Ring Contexts and Execlists
> !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and
> Execlists !Idrivers/gpu/drm/i915/intel_lrc.c
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index e4083e4..c8dbb37d 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
>
> # GEM code
> i915-y += i915_cmd_parser.o \
> + i915_gem_batch_pool.o \
> i915_gem_context.o \
> i915_gem_render_state.o \
> i915_gem_debug.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index c4f2cb6..b12a062 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1154,6 +1154,12 @@ struct intel_l3_parity {
> int which_slice;
> };
>
> +struct i915_gem_batch_pool {
> + struct drm_device *dev;
> + struct list_head active_list;
> + struct list_head inactive_list;
> +};
> +
> struct i915_gem_mm {
> /** Memory allocator for GTT stolen memory */
> struct drm_mm stolen;
> @@ -1885,6 +1891,8 @@ struct drm_i915_gem_object {
> /** Used in execbuf to temporarily hold a ref */
> struct list_head obj_exec_link;
>
> + struct list_head batch_pool_list;
> +
> /**
>* This is set if the object is on the active lists (has pending
>* rendering and so a non-zero seqno), and is not set if it i s on @@ -
> 2849,6 +2857,13 @@ void i915_destroy_error_state(struct drm_device
> *dev); void i915_get_extra_instdone(struct drm_device *dev, uint32_t
> *instdone); const char *i915_cache_level_str(struct drm_i915_private *i915,
> int type);
>
> +/* i915_gem_batch_pool.c */
> +void i915_gem_batch_pool_init(struct drm_device *dev,
> + struct i915_gem_batch_pool *pool); void
> +i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool); struct
> +drm_i915_gem_object* i915_gem_batch_pool_get(struct
> i915_gem_batch_pool
> +*pool, size_t size);
> +
> /* i915_cmd_parser.c */
> int i915_cmd_parser_get_version(void);
> int i915_cmd_parser_init_ring(struct intel_engine_cs *ring); diff --git
> a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 86cf428..b19dd06 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4433,6 +4433,7 @@ void i915_gem_object_init(struct
> drm_i915_gem_object *obj,
> INIT_LIST_HEAD(&obj->ring_list);
> INIT_LIST_HEAD(&obj->obj_exec_link);
> INIT_LIST_HEAD(&obj->vma_list);
> + INIT_LIST_HEAD(&obj->batch
[Intel-gfx] [RFC][PATCH 0/8] drm/i915: Keep drm_crtc->state in sync
When we implement atomic support, we'll need to keep a crtc current state in the drm_crtc->state pointer, and save the new config into a separate state object passed down the call chain. This series moves in that direction by making struct intel_crtc_config the state struct for our driver, and by getting rid of intel_crtc->new_config and passing it down the call chain. I'm not sure if this actually goes in the right direction, so I'm sending this RFC. Thanks, Ander Ander Conselvan de Oliveira (8): drm/i915: Rename struct intel_crtc_config to intel_crtc_state drm/i915: Embedded struct drm_crtc_state in intel_crtc_state drm/i915: Pass new_config down do crtc_compute_clock drm/i915: Use local pipe_config varariable when available drm/i915: Don't access to crtc->new_config from intel_mode_max_pixclk() drm/i915: Remove intel_crtc->new_config pointer drm/i915: Make intel_crtc->config a pointer drm/i915: Keep drm_crtc->state in sync with intel_crtc->config drivers/gpu/drm/i915/i915_debugfs.c | 12 +- drivers/gpu/drm/i915/i915_drv.h | 7 +- drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/intel_audio.c | 2 +- drivers/gpu/drm/i915/intel_crt.c | 16 +- drivers/gpu/drm/i915/intel_ddi.c | 103 ++--- drivers/gpu/drm/i915/intel_display.c | 714 ++- drivers/gpu/drm/i915/intel_dp.c | 34 +- drivers/gpu/drm/i915/intel_dp_mst.c | 15 +- drivers/gpu/drm/i915/intel_drv.h | 45 +-- drivers/gpu/drm/i915/intel_dsi.c | 18 +- drivers/gpu/drm/i915/intel_dvo.c | 20 +- drivers/gpu/drm/i915/intel_fbdev.c | 10 +- drivers/gpu/drm/i915/intel_hdmi.c| 48 +-- drivers/gpu/drm/i915/intel_lvds.c| 16 +- drivers/gpu/drm/i915/intel_overlay.c | 2 +- drivers/gpu/drm/i915/intel_panel.c | 16 +- drivers/gpu/drm/i915/intel_pm.c | 60 +-- drivers/gpu/drm/i915/intel_psr.c | 8 +- drivers/gpu/drm/i915/intel_sdvo.c| 28 +- drivers/gpu/drm/i915/intel_sprite.c | 2 +- drivers/gpu/drm/i915/intel_tv.c | 10 +- 22 files changed, 604 insertions(+), 590 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC][PATCH 2/8] drm/i915: Embedded struct drm_crtc_state in intel_crtc_state
And get rid of the duplicate mode structures. The bulk of the patch
was generated with the following semantic patch.
@@ struct intel_crtc_state *state; @@
-state->adjusted_mode
+state->base.adjusted_mode
@@ struct intel_crtc_state *state; @@
-state->requested_mode
+state->base.mode
@@ struct intel_crtc_state state; @@
-state.adjusted_mode
+state.base.adjusted_mode
@@ struct intel_crtc_state state; @@
-state.requested_mode
+state.base.mode
---
drivers/gpu/drm/i915/i915_irq.c | 8 +-
drivers/gpu/drm/i915/intel_audio.c | 2 +-
drivers/gpu/drm/i915/intel_crt.c | 10 +--
drivers/gpu/drm/i915/intel_ddi.c | 18 ++---
drivers/gpu/drm/i915/intel_display.c | 147 ++-
drivers/gpu/drm/i915/intel_dp.c | 8 +-
drivers/gpu/drm/i915/intel_dp_mst.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 12 +--
drivers/gpu/drm/i915/intel_dsi.c | 8 +-
drivers/gpu/drm/i915/intel_dvo.c | 12 +--
drivers/gpu/drm/i915/intel_fbdev.c | 8 +-
drivers/gpu/drm/i915/intel_hdmi.c| 16 ++--
drivers/gpu/drm/i915/intel_lvds.c| 8 +-
drivers/gpu/drm/i915/intel_panel.c | 8 +-
drivers/gpu/drm/i915/intel_pm.c | 30 +++
drivers/gpu/drm/i915/intel_psr.c | 2 +-
drivers/gpu/drm/i915/intel_sdvo.c| 12 +--
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 6 +-
19 files changed, 157 insertions(+), 164 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 08a5a4b..11e209e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -567,7 +567,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev,
int pipe)
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
const struct drm_display_mode *mode =
- &intel_crtc->config.adjusted_mode;
+ &intel_crtc->config.base.adjusted_mode;
htotal = mode->crtc_htotal;
hsync_start = mode->crtc_hsync_start;
@@ -638,7 +638,7 @@ static int __intel_get_crtc_scanline(struct intel_crtc
*crtc)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- const struct drm_display_mode *mode = &crtc->config.adjusted_mode;
+ const struct drm_display_mode *mode = &crtc->config.base.adjusted_mode;
enum pipe pipe = crtc->pipe;
int position, vtotal;
@@ -665,7 +665,7 @@ static int i915_get_crtc_scanoutpos(struct drm_device *dev,
int pipe,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc = dev_priv->pipe_to_crtc_mapping[pipe];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- const struct drm_display_mode *mode = &intel_crtc->config.adjusted_mode;
+ const struct drm_display_mode *mode =
&intel_crtc->config.base.adjusted_mode;
int position;
int vbl_start, vbl_end, hsync_start, htotal, vtotal;
bool in_vbl = true;
@@ -823,7 +823,7 @@ static int i915_get_vblank_timestamp(struct drm_device
*dev, int pipe,
return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error,
vblank_time, flags,
crtc,
-
&to_intel_crtc(crtc)->config.adjusted_mode);
+
&to_intel_crtc(crtc)->config.base.adjusted_mode);
}
static bool intel_hpd_irq_event(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 2c7ed5c..fe8c496 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -397,7 +397,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
{
struct drm_encoder *encoder = &intel_encoder->base;
struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
- struct drm_display_mode *mode = &crtc->config.adjusted_mode;
+ struct drm_display_mode *mode = &crtc->config.base.adjusted_mode;
struct drm_connector *connector;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 675b85a..e4f6d49 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -115,14 +115,14 @@ static void intel_crt_get_config(struct intel_encoder
*encoder,
struct drm_device *dev = encoder->base.dev;
int dotclock;
- pipe_config->adjusted_mode.flags |= intel_crt_get_flags(encoder);
+ pipe_config->base.adjusted_mode.flags |= intel_crt_get_flags(encoder);
dotclock = pipe_config->port_clock;
if (HAS_PCH_SPLIT(dev))
ironlake_check_encoder_
[Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
After a bit of irc discussion we've concluded that it would be prudent
to check that callers use the mask/enable paramters correctly. So add
a WARN_ON.
Spurred by Damien's bugfix which added _MASKED_FIELD.
v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
which should always be extended. So this doesn't work really. Dunno
why gcc only started complaining when I've moved the WARN out of the
static inline helper to address a feedback from Jani.
Cc: Damien Lespiau
Cc: Chris Wilson
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 08a5a4ba52ac..e6a1db36928e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
*dev_priv,
{
assert_spin_locked(&dev_priv->irq_lock);
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
if (WARN_ON(!intel_irqs_enabled(dev_priv)))
return;
@@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
*dev_priv,
{
uint32_t new_val;
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
assert_spin_locked(&dev_priv->irq_lock);
new_val = dev_priv->pm_irq_mask;
@@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct drm_i915_private
*dev_priv,
sdeimr &= ~interrupt_mask;
sdeimr |= (~enabled_irq_mask & interrupt_mask);
+ WARN_ON(enabled_irq_mask & ~interrupt_mask);
+
assert_spin_locked(&dev_priv->irq_lock);
if (WARN_ON(!intel_irqs_enabled(dev_priv)))
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, 08 Dec 2014, Daniel Vetter wrote:
> After a bit of irc discussion we've concluded that it would be prudent
> to check that callers use the mask/enable paramters correctly. So add
> a WARN_ON.
>
> Spurred by Damien's bugfix which added _MASKED_FIELD.
>
> v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
> which should always be extended. So this doesn't work really. Dunno
> why gcc only started complaining when I've moved the WARN out of the
> static inline helper to address a feedback from Jani.
Ah, that would be precisely because of the static inline helper. The
function parameter is never a builtin constant!
BR,
Jani.
>
> Cc: Damien Lespiau
> Cc: Chris Wilson
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 08a5a4ba52ac..e6a1db36928e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
> *dev_priv,
> {
> assert_spin_locked(&dev_priv->irq_lock);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> return;
>
> @@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
> *dev_priv,
> {
> uint32_t new_val;
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> new_val = dev_priv->pm_irq_mask;
> @@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct drm_i915_private
> *dev_priv,
> sdeimr &= ~interrupt_mask;
> sdeimr |= (~enabled_irq_mask & interrupt_mask);
>
> + WARN_ON(enabled_irq_mask & ~interrupt_mask);
> +
> assert_spin_locked(&dev_priv->irq_lock);
>
> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
> --
> 2.1.1
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.
The idea to use __builtin_constant_p is from Chris Wilson.
Cc: Damien Lespiau
Cc: Chris Wilson
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
5 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
- WARN_ON(1);
+ MISSING_CASE();
return "?";
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..b2ddc121654d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,8 +57,16 @@
#define DRIVER_DESC"Intel Graphics"
#define DRIVER_DATE"20141205"
+static inline void __i915_warn_on(bool cond)
+{
+ if (__builtin_constant_p(cond))
+ BUILD_BUG_ON(cond);
+}
+
#undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+#define WARN_ON(x) (__i915_warn_on((x)), WARN((x), "WARN_ON(" #x ")"))
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
}
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
}
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
- WARN_ON(1);
+ MISSING_CASE();
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev,
int cdclk)
cmd = 0;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
}
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202,7 @@ void intel_uncore_init(struct drm_device *dev)
switch (INTEL_INFO(dev)->gen) {
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
case 9:
ASSIGN_WRITE_MMIO_VFUNCS(gen9);
@@ -1300,7 +1300,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
reg->val = I915_READ8(reg->offset);
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
ret = -EINVAL;
goto out;
}
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: s/MI_STORE_DWORD_IMM_GEN8/MI_STORE_DWORD_IMM_GEN4/
On Mon, Dec 08, 2014 at 02:57:31PM +, Dave Gordon wrote: > On 05/12/14 12:51, Ville Syrjälä wrote: > > On Fri, Nov 14, 2014 at 06:16:56PM +0200, ville.syrj...@linux.intel.com > > wrote: > >> From: Ville Syrjälä > >> > >> MI_STORE_DWORD_IMM length has been the same ever since gen4. Rename > >> the define to avoid potential confusion if someone tries to use this > >> on pre-gen8. > >> > >> Also correct the comment on MI_MEM_VIRTUAL bit. It's present on 945,g33 > >> and 965 only. > >> > >> Cc: Oscar Mateo > >> Signed-off-by: Ville Syrjälä > > > > ping > > > >> --- > >> drivers/gpu/drm/i915/i915_reg.h | 4 ++-- > >> drivers/gpu/drm/i915/intel_lrc.c | 2 +- > >> 2 files changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_reg.h > >> b/drivers/gpu/drm/i915/i915_reg.h > >> index 3de58ac..5228493 100644 > >> --- a/drivers/gpu/drm/i915/i915_reg.h > >> +++ b/drivers/gpu/drm/i915/i915_reg.h > >> @@ -280,8 +280,8 @@ > >> #define MI_SEMAPHORE_POLL (1<<15) > >> #define MI_SEMAPHORE_SAD_GTE_SDD(1<<12) > >> #define MI_STORE_DWORD_IMMMI_INSTR(0x20, 1) > >> -#define MI_STORE_DWORD_IMM_GEN8 MI_INSTR(0x20, 2) > >> -#define MI_MEM_VIRTUAL (1 << 22) /* 965+ only */ > >> +#define MI_STORE_DWORD_IMM_GEN4 MI_INSTR(0x20, 2) > >> +#define MI_MEM_VIRTUAL (1 << 22) /* 945,g33,965 */ > >> #define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1) > >> #define MI_STORE_DWORD_INDEX_SHIFT 2 > >> /* Official intel docs are somewhat sloppy concerning > >> MI_LOAD_REGISTER_IMM: > >> diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >> b/drivers/gpu/drm/i915/intel_lrc.c > >> index 6025ac7..649d9ba 100644 > >> --- a/drivers/gpu/drm/i915/intel_lrc.c > >> +++ b/drivers/gpu/drm/i915/intel_lrc.c > >> @@ -1188,7 +1188,7 @@ static int gen8_emit_request(struct intel_ringbuffer > >> *ringbuf) > >>if (ret) > >>return ret; > >> > >> - cmd = MI_STORE_DWORD_IMM_GEN8; > >> + cmd = MI_STORE_DWORD_IMM_GEN4; > >>cmd |= MI_GLOBAL_GTT; > >> > >>intel_logical_ring_emit(ringbuf, cmd); > >> -- > >> 2.0.4 > > The GEN8->GEN4 change looks sensible to me. But I was puzzled over the > definition of MI_STORE_DWORD_IMM -- presumably this apparently more > generic definition is actually a pre-GEN4 legacy from the days when the > instruction had only 3 words? Perhaps a comment here from somebody who > knows -- or even something like > > #define MI_STORE_DWORD_IMM_LEGACY MI_INSTR(0x20, 1) /* > pre-GEN4 */ > #define MI_STORE_DWORD_IMM_GEN4 MI_INSTR(0x20, 2) /* > GEN4+ */ > #define MI_STORE_DWORD_IMM MI_STORE_DWORD_IMM_LEGACY /* for > source > backward compatibility */ > > so it's clearer that (for now) the generic definition is actually the > legacy one. We tend to name things based on the oldest platform supporting it, so I think it's fairly clear the _IMM is for old stuff, and _IMM_GEN4 is for gen4+. To make it more clear we could add a _GEN2 suffix for the old platform define, but I don't see much point with that myself. Oh and source backwards compatibility is something we never really have to worry about. All the code is in the same tree, so we can just change all the users at the same time. Doing otherwise would just lead to a mess. > > The above bikeshedding notwithstanding, it gets my R-b anyway: > > Reviewed-by: Dave Gordon -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/i915: don't keep reassigning FBC_UNSUPPORTED
From: Paulo Zanoni
This may save a few picoseconds on !HAS_FBC platforms. And it also
satisfies my OCD.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 4647d57..f3d5764 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -516,10 +516,8 @@ void intel_fbc_update(struct drm_device *dev)
const struct drm_display_mode *adjusted_mode;
unsigned int max_width, max_height;
- if (!HAS_FBC(dev)) {
- set_no_fbc_reason(dev_priv, FBC_UNSUPPORTED);
+ if (!HAS_FBC(dev))
return;
- }
if (i915.enable_fbc < 0) {
if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
@@ -684,6 +682,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
{
if (!HAS_FBC(dev_priv)) {
dev_priv->fbc.enabled = false;
+ dev_priv->fbc.no_fbc_reason = FBC_UNSUPPORTED;
return;
}
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] FBC improvements + frontbuffer tracking conversion
From: Paulo Zanoni Hi This series does some minor fixes to the FBC code and also ports it to use the new front buffer tracking infrastructure. Patches 1-2 are the transition from intel_pm.c to intel_fbc.c. Rodrigo's point is that it's better to move to intel_fbc.c first because then it's going to be easier to bisect any changes introduced by the series, and I agree with him. Also, I don't think we're going to bisect any FBC changes that happened before this series anyway. I tested this series both on IGT's kms_fbc_crc.c and on another set of tests that I wrote on my own (yes, NIH syndrome). I plan to move all the new tests that I wrote to kms_fbc_crc, but I still didn't do this and it will take some time. With the series applied, HSW passes all the tests. I still see some FIFO underruns on my BDW machine - not introduced by the series - so I don't think we should enable FBC by default yet. Thanks, Paulo Paulo Zanoni (9): drm/i915: don't try to find crtcs for FBC if it's disabled drm/i915: don't keep reassigning FBC_UNSUPPORTED drm/i915: change dev_priv->fbc.plane to dev_priv->fbc.crtc drm/i915: pass which operation triggered the frontbuffer tracking drm/i915: also do frontbuffer tracking on pwrites drm/i915: add fronbuffer tracking to FBC drm/i915: extract intel_fbc_find_crtc() drm/i915: HSW+ FBC is tied to pipe A drm/i915: gen5+ can have FBC with multiple pipes Rodrigo Vivi (2): drm/i915: Move FBC stuff to intel_fbc.c drm/i915: Introduce FBC DocBook. Documentation/DocBook/drm.tmpl | 5 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_drv.h| 21 +- drivers/gpu/drm/i915/i915_gem.c| 14 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- drivers/gpu/drm/i915/i915_suspend.c| 2 +- drivers/gpu/drm/i915/intel_display.c | 27 +- drivers/gpu/drm/i915/intel_drv.h | 24 +- drivers/gpu/drm/i915/intel_fbc.c | 758 + drivers/gpu/drm/i915/intel_frontbuffer.c | 29 +- drivers/gpu/drm/i915/intel_pm.c| 651 + drivers/gpu/drm/i915/intel_ringbuffer.c| 41 +- drivers/gpu/drm/i915/intel_ringbuffer.h| 1 - drivers/gpu/drm/i915/intel_sprite.c| 6 +- 14 files changed, 833 insertions(+), 749 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_fbc.c -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915: don't try to find crtcs for FBC if it's disabled
From: Paulo Zanoni
.. because it would be a waste of time, so move the place where the
check is done. Also, with this we won't risk printing "more than one
pipe active, disabling compression" or "no output, disabling" when FBC
is actually disabled.
This patch also represents a small behavior difference when using
i915.powersave=0: it is now exactly the same as i915.enable_fbc=0 on
this part of the code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 7686573..4647d57 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -521,10 +521,16 @@ void intel_fbc_update(struct drm_device *dev)
return;
}
- if (!i915.powersave) {
+ if (i915.enable_fbc < 0) {
+ if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
+ DRM_DEBUG_KMS("disabled per chip default\n");
+ goto out_disable;
+ }
+
+ if (!i915.enable_fbc || !i915.powersave) {
if (set_no_fbc_reason(dev_priv, FBC_MODULE_PARAM))
DRM_DEBUG_KMS("fbc disabled per module param\n");
- return;
+ goto out_disable;
}
/*
@@ -559,16 +565,6 @@ void intel_fbc_update(struct drm_device *dev)
obj = intel_fb_obj(fb);
adjusted_mode = &intel_crtc->config.adjusted_mode;
- if (i915.enable_fbc < 0) {
- if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
- DRM_DEBUG_KMS("disabled per chip default\n");
- goto out_disable;
- }
- if (!i915.enable_fbc) {
- if (set_no_fbc_reason(dev_priv, FBC_MODULE_PARAM))
- DRM_DEBUG_KMS("fbc disabled per module param\n");
- goto out_disable;
- }
if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
(adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
if (set_no_fbc_reason(dev_priv, FBC_UNSUPPORTED_MODE))
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915: Introduce FBC DocBook.
From: Rodrigo Vivi
No functional changes.
v2 (Paulo): Rebase.
Signed-off-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
Documentation/DocBook/drm.tmpl | 5
drivers/gpu/drm/i915/intel_fbc.c | 57 ++--
2 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 85287cb..8b780ab 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3926,6 +3926,11 @@ int num_ioctls;
!Idrivers/gpu/drm/i915/intel_psr.c
+ Frame Buffer Compression (FBC)
+!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
+!Idrivers/gpu/drm/i915/intel_fbc.c
+
+
DPIO
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index f1eeb86..7686573 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -21,20 +21,31 @@
* DEALINGS IN THE SOFTWARE.
*/
-#include "intel_drv.h"
-#include "i915_drv.h"
-
-/* FBC, or Frame Buffer Compression, is a technique employed to compress the
- * framebuffer contents in-memory, aiming at reducing the required bandwidth
+/**
+ * DOC: Frame Buffer Compression (FBC)
+ *
+ * FBC is a technique employed to compress the framebuffer contents
+ * in-memory, aiming at reducing the required bandwidth
* during in-memory transfers and, therefore, reduce the power packet.
*
+ * FBC is primarily a memory power savings technology. That is the major
+ * benefit is to the memory power while displaying the processor graphics
+ * information to the display. FBC works by compressing the amount of memory
+ * used by the display. It means that it is total transparent to user space.
+ *
* The benefits of FBC are mostly visible with solid backgrounds and
- * variation-less patterns.
+ * variation-less patterns. It comes from keeping the memory footprint small
+ * and having fewer memory pages opened and accessed for refreshing the
display.
*
- * FBC-related functionality can be enabled by the means of the
- * i915.i915_fbc_enable parameter
+ * i915 is responsible to reserve stolen memory for FBC and configure its
+ * offset on proper register. The hardware takes care of all
+ * compress/decompress. However there are many known cases where we have to
+ * forcibly disable it to allow proper screen updates.
*/
+#include "intel_drv.h"
+#include "i915_drv.h"
+
static void i8xx_fbc_disable(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -318,6 +329,12 @@ static void gen7_fbc_enable(struct drm_crtc *crtc)
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
}
+/**
+ * intel_fbc_enabled - Is FBC enabled?
+ * @dev: the drm_device
+ *
+ * This function is used to verify the current state of FBC.
+ */
bool intel_fbc_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -325,6 +342,18 @@ bool intel_fbc_enabled(struct drm_device *dev)
return dev_priv->fbc.enabled;
}
+/**
+ * bdw_fbc_sw_flush - FBC Software Flush for Broadwell.
+ * @dev: the drm_device
+ * @value: Value to be set on MSG_FBC_REND_STATE. Possible values are
+ * FBC_REND_NUKE and FBC_REND_CACHE_CLEAN.
+ *
+ * This function is needed on Broadwell to perform Nuke or Cache clean on
+ * software side over MMIO.
+ * On Broadwell, due a hardware bug, MSG_FBC_REND_STATE stay in a forbidden
+ * address that has a huge risk of causing GPU Hangs if set with LRI on some
+ * command streamers.
+ */
void bdw_fbc_sw_flush(struct drm_device *dev, u32 value)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -429,6 +458,12 @@ static void intel_fbc_enable(struct drm_crtc *crtc)
schedule_delayed_work(&work->work, msecs_to_jiffies(50));
}
+/**
+ * intel_fbc_disable - disable FBC
+ * @dev: the drm_device
+ *
+ * This function disables FBC.
+ */
void intel_fbc_disable(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -643,6 +678,12 @@ out_disable:
i915_gem_stolen_cleanup_compression(dev);
}
+/**
+ * intel_fbc_init - Initialize FBC
+ * @dev_priv: the i915 device
+ *
+ * This function might be called during PM init process.
+ */
void intel_fbc_init(struct drm_i915_private *dev_priv)
{
if (!HAS_FBC(dev_priv)) {
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Move FBC stuff to intel_fbc.c
From: Rodrigo Vivi No functional changes. This is just the begin of a FBC rework. v2 (Paulo): - Revert intel_fbc_init() changed parameter. - Revert set_no_fbc_reason() rename. - Rebase. Cc: Paulo Zanoni Signed-off-by: Rodrigo Vivi Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_drv.h | 3 - drivers/gpu/drm/i915/i915_suspend.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 22 +- drivers/gpu/drm/i915/intel_drv.h | 9 +- drivers/gpu/drm/i915/intel_fbc.c | 675 +++ drivers/gpu/drm/i915/intel_pm.c | 651 + drivers/gpu/drm/i915/intel_sprite.c | 4 +- 8 files changed, 698 insertions(+), 669 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_fbc.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index e4083e4..3cf70a6 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -47,6 +47,7 @@ i915-y += intel_renderstate_gen6.o \ i915-y += intel_audio.o \ intel_bios.o \ intel_display.o \ + intel_fbc.o \ intel_fifo_underrun.o \ intel_frontbuffer.o \ intel_modes.o \ diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 11e85cb..b5260bf 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2963,9 +2963,6 @@ extern void intel_modeset_setup_hw_state(struct drm_device *dev, bool force_restore); extern void i915_redisable_vga(struct drm_device *dev); extern void i915_redisable_vga_power_on(struct drm_device *dev); -extern bool intel_fbc_enabled(struct drm_device *dev); -extern void bdw_fbc_sw_flush(struct drm_device *dev, u32 value); -extern void intel_disable_fbc(struct drm_device *dev); extern bool ironlake_set_drps(struct drm_device *dev, u8 val); extern void intel_init_pch_refclk(struct drm_device *dev); extern void gen6_set_rps(struct drm_device *dev, u8 val); diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c index dfe6617..1e4999d 100644 --- a/drivers/gpu/drm/i915/i915_suspend.c +++ b/drivers/gpu/drm/i915/i915_suspend.c @@ -264,7 +264,7 @@ static void i915_restore_display(struct drm_device *dev) } /* only restore FBC info on the platform that supports FBC*/ - intel_disable_fbc(dev); + intel_fbc_disable(dev); /* restore FBC interval */ if (HAS_FBC(dev) && INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev)) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a9bdc12..e4789f4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4201,7 +4201,7 @@ static void intel_crtc_enable_planes(struct drm_crtc *crtc) hsw_enable_ips(intel_crtc); mutex_lock(&dev->struct_mutex); - intel_update_fbc(dev); + intel_fbc_update(dev); mutex_unlock(&dev->struct_mutex); /* @@ -4223,7 +4223,7 @@ static void intel_crtc_disable_planes(struct drm_crtc *crtc) intel_crtc_wait_for_pending_flips(crtc); if (dev_priv->fbc.plane == plane) - intel_disable_fbc(dev); + intel_fbc_disable(dev); hsw_disable_ips(intel_crtc); @@ -4526,7 +4526,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc) intel_update_watermarks(crtc); mutex_lock(&dev->struct_mutex); - intel_update_fbc(dev); + intel_fbc_update(dev); mutex_unlock(&dev->struct_mutex); } @@ -4581,7 +4581,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc) intel_update_watermarks(crtc); mutex_lock(&dev->struct_mutex); - intel_update_fbc(dev); + intel_fbc_update(dev); mutex_unlock(&dev->struct_mutex); if (intel_crtc_to_shared_dpll(intel_crtc)) @@ -5186,7 +5186,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc) intel_update_watermarks(crtc); mutex_lock(&dev->struct_mutex); - intel_update_fbc(dev); + intel_fbc_update(dev); mutex_unlock(&dev->struct_mutex); } @@ -8947,7 +8947,7 @@ static void intel_unpin_work_fn(struct work_struct *__work) drm_gem_object_unreference(&work->pending_flip_obj->base); drm_gem_object_unreference(&work->old_fb_obj->base); - intel_update_fbc(dev); + intel_fbc_update(dev); if (work->flip_queued_req) i915_gem_request_assign(&work->flip_queued_req, NULL); @@ -9744,7 +9744,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, i915_gem_track_fb(work->old_fb_obj, obj, INTEL_FRONTBUFFER_PRIMARY(pipe)); - intel_disable_fbc(dev); + intel_fbc_disable(dev); intel_frontbuffer_flip_prepare(dev, INTEL_FRONTBUFFER_PRIMARY(pipe)); mutex_unlock(&dev->struct_mutex); @@ -11815
[Intel-gfx] [PATCH 06/11] drm/i915: pass which operation triggered the frontbuffer tracking
From: Paulo Zanoni
We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation/flush so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h| 7 +++
drivers/gpu/drm/i915/i915_gem.c| 10 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 11 +++
drivers/gpu/drm/i915/intel_frontbuffer.c | 15 ++-
5 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d694f1..ea3cc81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -685,6 +685,13 @@ struct intel_context {
struct list_head link;
};
+enum fb_op_origin {
+ ORIGIN_GTT,
+ ORIGIN_CPU,
+ ORIGIN_RENDER,
+ ORIGIN_FLIP,
+};
+
struct i915_fbc {
unsigned long size;
unsigned threshold;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index de241eb..7ef12e8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2321,7 +2321,7 @@ i915_gem_object_move_to_inactive(struct
drm_i915_gem_object *obj)
list_move_tail(&vma->mm_list, &vm->inactive_list);
}
- intel_fb_obj_flush(obj, true);
+ intel_fb_obj_flush(obj, true, ORIGIN_RENDER);
list_del_init(&obj->ring_list);
@@ -3665,7 +3665,7 @@ i915_gem_object_flush_gtt_write_domain(struct
drm_i915_gem_object *obj)
old_write_domain = obj->base.write_domain;
obj->base.write_domain = 0;
- intel_fb_obj_flush(obj, false);
+ intel_fb_obj_flush(obj, false, ORIGIN_GTT);
trace_i915_gem_object_change_domain(obj,
obj->base.read_domains,
@@ -3688,7 +3688,7 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_i915_gem_object *obj,
old_write_domain = obj->base.write_domain;
obj->base.write_domain = 0;
- intel_fb_obj_flush(obj, false);
+ intel_fb_obj_flush(obj, false, ORIGIN_CPU);
trace_i915_gem_object_change_domain(obj,
obj->base.read_domains,
@@ -3745,7 +3745,7 @@ i915_gem_object_set_to_gtt_domain(struct
drm_i915_gem_object *obj, bool write)
}
if (write)
- intel_fb_obj_invalidate(obj, NULL);
+ intel_fb_obj_invalidate(obj, NULL, ORIGIN_GTT);
trace_i915_gem_object_change_domain(obj,
old_read_domains,
@@ -4072,7 +4072,7 @@ i915_gem_object_set_to_cpu_domain(struct
drm_i915_gem_object *obj, bool write)
}
if (write)
- intel_fb_obj_invalidate(obj, NULL);
+ intel_fb_obj_invalidate(obj, NULL, ORIGIN_CPU);
trace_i915_gem_object_change_domain(obj,
old_read_domains,
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0c25f62..af290e6 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -965,7 +965,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
obj->dirty = 1;
i915_gem_request_assign(&obj->last_write_req, req);
- intel_fb_obj_invalidate(obj, ring);
+ intel_fb_obj_invalidate(obj, ring, ORIGIN_RENDER);
/* update for the implicit flush after a batch */
obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 588b618..633fb9a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -841,13 +841,15 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc
*crtc, bool state);
/* intel_frontbuffer.c */
void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *ring);
+struct intel_engine_cs *ring,
+enum fb_op_origin origin);
void intel_frontbuffer_flip_prepare(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_frontbuffer_flip_complete(struct drm_device *dev,
unsigned frontbuffer_bits);
void intel_frontbuffer_flush(struct drm_device *dev,
-unsigned frontbuffer_bits);
+unsigned frontbuffer_bits,
+enum fb_op_origin origin);
/**
* intel_frontbuffer_flip - synchronous frontbuffer flip
* @dev: DRM device
@@ -863,10 +865,11 @@ static inline
void intel_fron
[Intel-gfx] [PATCH 09/11] drm/i915: extract intel_fbc_find_crtc()
From: Paulo Zanoni
I want to make this code a little more complicated, so let's extract
the function first.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 46 +---
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 03ba43d..450d0be 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -444,6 +444,32 @@ static bool set_no_fbc_reason(struct drm_i915_private
*dev_priv,
return true;
}
+static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv->dev;
+ struct drm_crtc *crtc = NULL, *tmp_crtc;
+
+ for_each_crtc(dev, tmp_crtc) {
+ if (intel_crtc_active(tmp_crtc) &&
+ to_intel_crtc(tmp_crtc)->primary_enabled) {
+ if (crtc) {
+ if (set_no_fbc_reason(dev_priv,
FBC_MULTIPLE_PIPES))
+ DRM_DEBUG_KMS("more than one pipe
active, disabling compression\n");
+ return NULL;
+ }
+ crtc = tmp_crtc;
+ }
+ }
+
+ if (!crtc || crtc->primary->fb == NULL) {
+ if (set_no_fbc_reason(dev_priv, FBC_NO_OUTPUT))
+ DRM_DEBUG_KMS("no output, disabling\n");
+ return NULL;
+ }
+
+ return crtc;
+}
+
/**
* intel_fbc_update - enable/disable FBC as needed
* @dev: the drm_device
@@ -466,7 +492,7 @@ static bool set_no_fbc_reason(struct drm_i915_private
*dev_priv,
void intel_fbc_update(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_crtc *crtc = NULL, *tmp_crtc;
+ struct drm_crtc *crtc = NULL;
struct intel_crtc *intel_crtc;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
@@ -497,23 +523,9 @@ void intel_fbc_update(struct drm_device *dev)
* - new fb is too large to fit in compressed buffer
* - going to an unsupported config (interlace, pixel multiply, etc.)
*/
- for_each_crtc(dev, tmp_crtc) {
- if (intel_crtc_active(tmp_crtc) &&
- to_intel_crtc(tmp_crtc)->primary_enabled) {
- if (crtc) {
- if (set_no_fbc_reason(dev_priv,
FBC_MULTIPLE_PIPES))
- DRM_DEBUG_KMS("more than one pipe
active, disabling compression\n");
- goto out_disable;
- }
- crtc = tmp_crtc;
- }
- }
-
- if (!crtc || crtc->primary->fb == NULL) {
- if (set_no_fbc_reason(dev_priv, FBC_NO_OUTPUT))
- DRM_DEBUG_KMS("no output, disabling\n");
+ crtc = intel_fbc_find_crtc(dev_priv);
+ if (!crtc)
goto out_disable;
- }
intel_crtc = to_intel_crtc(crtc);
fb = crtc->primary->fb;
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: HSW+ FBC is tied to pipe A
From: Paulo Zanoni
So add code to consider this case.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 450d0be..e8dc1d5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -446,10 +446,16 @@ static bool set_no_fbc_reason(struct drm_i915_private
*dev_priv,
static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = dev_priv->dev;
struct drm_crtc *crtc = NULL, *tmp_crtc;
+ enum pipe pipe;
+ bool pipe_a_only = false;
+
+ if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
+ pipe_a_only = true;
+
+ for_each_pipe(dev_priv, pipe) {
+ tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
- for_each_crtc(dev, tmp_crtc) {
if (intel_crtc_active(tmp_crtc) &&
to_intel_crtc(tmp_crtc)->primary_enabled) {
if (crtc) {
@@ -459,6 +465,9 @@ static struct drm_crtc *intel_fbc_find_crtc(struct
drm_i915_private *dev_priv)
}
crtc = tmp_crtc;
}
+
+ if (pipe_a_only)
+ break;
}
if (!crtc || crtc->primary->fb == NULL) {
@@ -714,11 +723,14 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
return;
}
- /* TODO: some platforms have FBC tied to a specific plane! */
- for_each_pipe(dev_priv, pipe)
+ for_each_pipe(dev_priv, pipe) {
dev_priv->fbc.possible_framebuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(pipe);
+ if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
+ break;
+ }
+
if (INTEL_INFO(dev_priv)->gen >= 7) {
dev_priv->display.fbc_enabled = ilk_fbc_enabled;
dev_priv->display.enable_fbc = gen7_fbc_enable;
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/11] drm/i915: change dev_priv->fbc.plane to dev_priv->fbc.crtc
From: Paulo Zanoni
Since the mapping from CRTCs to planes is fixed, looking at the CRTC
is essentially the same as looking at the plane. Also, the next
patches wil start using the frontbuffer_bits macros, and they take the
pipe as the parameter instead of the plane, and this could differ on
gens 2 and 3.
Another nice thing is that we don't risk accidentally initializing
things to PLANE_A if we don't set the value before it is used for the
first time. But this shouldn't be a problem with the current code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 5 ++---
drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
4 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5260bf..9d694f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -689,7 +689,7 @@ struct i915_fbc {
unsigned long size;
unsigned threshold;
unsigned int fb_id;
- enum plane plane;
+ struct intel_crtc *crtc;
int y;
struct drm_mm_node compressed_fb;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e4789f4..88f3652 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4218,11 +4218,10 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc->pipe;
- int plane = intel_crtc->plane;
intel_crtc_wait_for_pending_flips(crtc);
- if (dev_priv->fbc.plane == plane)
+ if (dev_priv->fbc.crtc == intel_crtc)
intel_fbc_disable(dev);
hsw_disable_ips(intel_crtc);
@@ -11813,7 +11812,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
*/
if (intel_crtc->primary_enabled &&
INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev) &&
- dev_priv->fbc.plane == intel_crtc->plane &&
+ dev_priv->fbc.crtc == intel_crtc &&
intel_plane->rotation != BIT(DRM_ROTATE_0)) {
intel_fbc_disable(dev);
}
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index f3d5764..88d00d3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -383,7 +383,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
if (work->crtc->primary->fb == work->fb) {
dev_priv->display.enable_fbc(work->crtc);
- dev_priv->fbc.plane = to_intel_crtc(work->crtc)->plane;
+ dev_priv->fbc.crtc = to_intel_crtc(work->crtc);
dev_priv->fbc.fb_id = work->crtc->primary->fb->base.id;
dev_priv->fbc.y = work->crtc->y;
}
@@ -474,7 +474,7 @@ void intel_fbc_disable(struct drm_device *dev)
return;
dev_priv->display.disable_fbc(dev);
- dev_priv->fbc.plane = -1;
+ dev_priv->fbc.crtc = NULL;
}
static bool set_no_fbc_reason(struct drm_i915_private *dev_priv,
@@ -626,7 +626,7 @@ void intel_fbc_update(struct drm_device *dev)
* cannot be unpinned (and have its GTT offset and fence revoked)
* without first being decoupled from the scanout and FBC disabled.
*/
- if (dev_priv->fbc.plane == intel_crtc->plane &&
+ if (dev_priv->fbc.crtc == intel_crtc &&
dev_priv->fbc.fb_id == fb->base.id &&
dev_priv->fbc.y == crtc->y)
return;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c18e57d..942daca 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1016,7 +1016,7 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
mutex_lock(&dev->struct_mutex);
- if (dev_priv->fbc.plane == intel_crtc->plane)
+ if (dev_priv->fbc.crtc == intel_crtc)
intel_fbc_disable(dev);
mutex_unlock(&dev->struct_mutex);
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/11] drm/i915: add fronbuffer tracking to FBC
From: Paulo Zanoni
Kill the blt/render tracking we currently have and use the frontbuffer
tracking infrastructure.
Don't enable things by default yet.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 9 +--
drivers/gpu/drm/i915/intel_drv.h | 6 +-
drivers/gpu/drm/i915/intel_fbc.c | 119 ++-
drivers/gpu/drm/i915/intel_frontbuffer.c | 14 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 41 +--
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
6 files changed, 80 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea3cc81..22285c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -696,6 +696,7 @@ struct i915_fbc {
unsigned long size;
unsigned threshold;
unsigned int fb_id;
+ unsigned int possible_framebuffer_bits;
struct intel_crtc *crtc;
int y;
@@ -708,14 +709,6 @@ struct i915_fbc {
* possible. */
bool enabled;
- /* On gen8 some rings cannont perform fbc clean operation so for now
-* we are doing this on SW with mmio.
-* This variable works in the opposite information direction
-* of ring->fbc_dirty telling software on frontbuffer tracking
-* to perform the cache clean on sw side.
-*/
- bool need_sw_cache_clean;
-
struct intel_fbc_work {
struct delayed_work work;
struct drm_crtc *crtc;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 633fb9a..3a1c3d82 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1071,7 +1071,11 @@ bool intel_fbc_enabled(struct drm_device *dev);
void intel_fbc_update(struct drm_device *dev);
void intel_fbc_init(struct drm_i915_private *dev_priv);
void intel_fbc_disable(struct drm_device *dev);
-void bdw_fbc_sw_flush(struct drm_device *dev, u32 value);
+void intel_fbc_invalidate(struct drm_i915_private *dev_priv,
+ unsigned int frontbuffer_bits,
+ enum fb_op_origin origin);
+void intel_fbc_flush(struct drm_i915_private *dev_priv,
+unsigned int frontbuffer_bits, enum fb_op_origin origin);
/* intel_hdmi.c */
void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 88d00d3..03ba43d 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -178,29 +178,10 @@ static bool g4x_fbc_enabled(struct drm_device *dev)
return I915_READ(DPFC_CONTROL) & DPFC_CTL_EN;
}
-static void snb_fbc_blit_update(struct drm_device *dev)
+static void intel_fbc_nuke(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 blt_ecoskpd;
-
- /* Make sure blitter notifies FBC of writes */
-
- /* Blitter is part of Media powerwell on VLV. No impact of
-* his param in other platforms for now */
- gen6_gt_force_wake_get(dev_priv, FORCEWAKE_MEDIA);
-
- blt_ecoskpd = I915_READ(GEN6_BLITTER_ECOSKPD);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY <<
- GEN6_BLITTER_LOCK_SHIFT;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY;
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- blt_ecoskpd &= ~(GEN6_BLITTER_FBC_NOTIFY <<
-GEN6_BLITTER_LOCK_SHIFT);
- I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
- POSTING_READ(GEN6_BLITTER_ECOSKPD);
-
- gen6_gt_force_wake_put(dev_priv, FORCEWAKE_MEDIA);
+ I915_WRITE(MSG_FBC_REND_STATE, FBC_REND_NUKE);
+ POSTING_READ(MSG_FBC_REND_STATE);
}
static void ilk_fbc_enable(struct drm_crtc *crtc)
@@ -243,9 +224,10 @@ static void ilk_fbc_enable(struct drm_crtc *crtc)
I915_WRITE(SNB_DPFC_CTL_SA,
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- snb_fbc_blit_update(dev);
}
+ intel_fbc_nuke(dev_priv);
+
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
}
@@ -324,7 +306,7 @@ static void gen7_fbc_enable(struct drm_crtc *crtc)
SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc->y);
- snb_fbc_blit_update(dev);
+ intel_fbc_nuke(dev_priv);
DRM_DEBUG_KMS("enabled fbc on plane %c\n",
plane_name(intel_crtc->plane));
}
@@ -342,31 +324,6 @@ bool intel_fbc_enabled(struct drm_device *dev)
return dev_priv->fbc.enabled;
}
-/**
- * bdw_fbc_sw_flush - FBC Software Flush for Broadwell.
- * @dev: the drm_device
- * @value: Value to be set on MSG_FBC_REND_STATE. Possible values are
- * FBC_REND_NUKE and FBC_REND_CACH
[Intel-gfx] [PATCH 07/11] drm/i915: also do frontbuffer tracking on pwrites
From: Paulo Zanoni
We need this for FBC, and possibly for PSR too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ef12e8..b8c906e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1117,6 +1117,10 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
ret = i915_gem_phys_pwrite(obj, args, file);
else
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
+
+ intel_fb_obj_flush(obj, false, ORIGIN_CPU);
+ } else {
+ intel_fb_obj_flush(obj, false, ORIGIN_GTT);
}
out:
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: gen5+ can have FBC with multiple pipes
From: Paulo Zanoni
So allow it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e8dc1d5..1c22922 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -448,17 +448,19 @@ static struct drm_crtc *intel_fbc_find_crtc(struct
drm_i915_private *dev_priv)
{
struct drm_crtc *crtc = NULL, *tmp_crtc;
enum pipe pipe;
- bool pipe_a_only = false;
+ bool pipe_a_only = false, one_pipe_only = false;
if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
pipe_a_only = true;
+ else if (INTEL_INFO(dev_priv)->gen <= 4)
+ one_pipe_only = true;
for_each_pipe(dev_priv, pipe) {
tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
if (intel_crtc_active(tmp_crtc) &&
to_intel_crtc(tmp_crtc)->primary_enabled) {
- if (crtc) {
+ if (one_pipe_only && crtc) {
if (set_no_fbc_reason(dev_priv,
FBC_MULTIPLE_PIPES))
DRM_DEBUG_KMS("more than one pipe
active, disabling compression\n");
return NULL;
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 1/4] lib: add igt_wait()
From: Paulo Zanoni
Just a little helper for code that needs to wait for a certain
condition to happen. It has the nice advantage that it can survive the
signal helper.
Despite the callers added in this patch, there is another that will go
in a separate patch, and another in a new IGT test file that I plan to
push later.
Signed-off-by: Paulo Zanoni
---
lib/igt_aux.c | 18 +-
lib/igt_aux.h | 40
tests/pm_rpm.c | 28 +---
3 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 3051d84..180141e 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -518,29 +518,13 @@ enum igt_runtime_pm_status igt_get_runtime_pm_status(void)
* Waits until for the driver to switch to into the desired runtime PM status,
* with a 10 second timeout.
*
- * Some subtests call this function while the signal helper is active, so we
- * can't assume each usleep() call will sleep for 100ms.
- *
* Returns:
* True if the desired runtime PM status was attained, false if the operation
* timed out.
*/
bool igt_wait_for_pm_status(enum igt_runtime_pm_status status)
{
- struct timeval start, end, diff;
-
- igt_assert(gettimeofday(&start, NULL) == 0);
- do {
- if (igt_get_runtime_pm_status() == status)
- return true;
-
- usleep(100 * 1000);
-
- igt_assert(gettimeofday(&end, NULL) == 0);
- timersub(&end, &start, &diff);
- } while (diff.tv_sec < 10);
-
- return false;
+ return igt_wait(igt_get_runtime_pm_status() == status, 1, 100);
}
/* Functions with prefix kmstest_ independent of cairo library are pulled out
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 6c83c53..48c495b 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -30,6 +30,7 @@
#include
#include
+#include
extern drm_intel_bo **trash_bos;
extern int num_trash_bos;
@@ -90,4 +91,43 @@ void intel_require_memory(uint32_t count, uint32_t size,
unsigned mode);
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
+/**
+ * igt_wait:
+ * @COND: condition to wait
+ * @timeout_ms: timeout in milliseconds
+ * @interval_ms: amount of time we try to sleep between COND checks
+ *
+ * Waits until COND evaluates to true or the timeout passes.
+ *
+ * It is safe to call this macro if the signal helper is active. The only
+ * problem is that the usleep() calls will return early, making us evaluate
COND
+ * too often, possibly eating valuable CPU cycles.
+ *
+ * Returns:
+ * True of COND evaluated to true, false otherwise.
+ */
+#define igt_wait(COND, timeout_ms, interval_ms) ({ \
+ struct timeval start_, end_, diff_; \
+ int elapsed_ms_;\
+ bool ret_ = false; \
+ \
+ igt_assert(gettimeofday(&start_, NULL) == 0); \
+ do {\
+ if (COND) { \
+ ret_ = true;\
+ break; \
+ } \
+ \
+ usleep(interval_ms * 1000); \
+ \
+ igt_assert(gettimeofday(&end_, NULL) == 0); \
+ timersub(&end_, &start_, &diff_); \
+ \
+ elapsed_ms_ = diff_.tv_sec * 1000 + \
+ diff_.tv_usec / 1000; \
+ } while (elapsed_ms_ < timeout_ms); \
+ \
+ ret_; \
+})
+
#endif /* IGT_AUX_H */
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index c120d75..b7f9635 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -153,24 +153,16 @@ static uint64_t get_residency(uint32_t type)
static bool pc8_plus_residency_changed(unsigned int timeout_sec)
{
- unsigned int i;
uint64_t res_pc8, res_pc9, res_pc10;
- int to_sleep = 100 * 1000;
res_pc8 = get_residency(MSR_PC8_RES);
res_pc9 = get_residency(MSR_PC9_RES);
res_pc10 = get_residency(MSR_PC10_RES);
- for (i = 0; i < timeout_sec * 1000 * 1000; i += to_sleep) {
- if (res_pc8 != get_residency(MSR_PC8_RES) ||
- res_
[Intel-gfx] [PATCH igt 3/4] tests/kms_fbc_crc: add wait_for_fbc_enabled()
From: Paulo Zanoni
The code has a common pattern of "wait 300ms, then check if FBC is
enabled". Most of the time FBC is enabled in either 50ms or 0ms, so
introduce wait_for_fbc_enabled(), which can return much earlier if FBC
is actually enabled before the 300ms timeout.
Signed-off-by: Paulo Zanoni
---
tests/kms_fbc_crc.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 7c3a412..354a2b7 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -28,6 +28,7 @@
#include
#include "drmtest.h"
+#include "igt_aux.h"
#include "igt_debugfs.h"
#include "igt_kms.h"
#include "intel_chipset.h"
@@ -203,6 +204,11 @@ static bool fbc_enabled(data_t *data)
return strstr(str, "FBC enabled") != NULL;
}
+static bool wait_for_fbc_enabled(data_t *data)
+{
+ return igt_wait(fbc_enabled(data), 300, 30);
+}
+
static void test_crc(data_t *data, enum test_mode mode)
{
uint32_t crtc_id = data->output->config.crtc->crtc_id;
@@ -216,9 +222,8 @@ static void test_crc(data_t *data, enum test_mode mode)
handle = data->handle[1];
igt_assert(drmModePageFlip(data->drm_fd, crtc_id,
data->fb_id[1], 0, NULL) == 0);
- usleep(30);
- igt_assert(fbc_enabled(data));
+ igt_assert(wait_for_fbc_enabled(data));
}
switch (mode) {
@@ -278,9 +283,7 @@ static void test_crc(data_t *data, enum test_mode mode)
* Allow time for FBC to kick in again if it
* got disabled during dirtyfb or page flip.
*/
- usleep(30);
-
- igt_assert(fbc_enabled(data));
+ igt_assert(wait_for_fbc_enabled(data));
igt_pipe_crc_start(pipe_crc);
igt_pipe_crc_get_crcs(pipe_crc, 1, &crcs);
@@ -340,9 +343,8 @@ static bool prepare_test(data_t *data, enum test_mode
test_mode)
/* scanout = fb[1] */
igt_plane_set_fb(data->primary, &data->fb[1]);
igt_display_commit(display);
- usleep(30);
- if (!fbc_enabled(data)) {
+ if (!wait_for_fbc_enabled(data)) {
igt_info("FBC not enabled\n");
igt_plane_set_fb(data->primary, NULL);
@@ -390,9 +392,8 @@ static bool prepare_test(data_t *data, enum test_mode
test_mode)
/* scanout = fb[0] */
igt_plane_set_fb(data->primary, &data->fb[0]);
igt_display_commit(display);
- usleep(30);
- igt_assert(fbc_enabled(data));
+ igt_assert(wait_for_fbc_enabled(data));
if (test_mode == TEST_CONTEXT || test_mode ==
TEST_PAGE_FLIP_AND_CONTEXT) {
/*
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 4/4] tests/kms_fbc_crc: also gem_sync() on exec_nop()
From: Paulo Zanoni When we're doing the context subtest, at the end of prepare_test() we exec a single nop batch on the front buffer, which invalidates FBC. With the new frontbuffer tracking scheme it may take a while for FBC to be reenabled, so we end up failing the first fbc_enabled() assertion inside test_crc(). Other possible implementations: - Call gem_sync() at the specific prepare_test() point, not at every exec_nop() call. - Change the fbc_enabled() assertion to wait_for_fbc_enabled() and give it a bigger timeout value. Cc: Ville Syrjälä Signed-off-by: Paulo Zanoni --- tests/kms_fbc_crc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c index 354a2b7..decb83e 100644 --- a/tests/kms_fbc_crc.c +++ b/tests/kms_fbc_crc.c @@ -155,6 +155,8 @@ static void exec_nop(data_t *data, uint32_t handle, drm_intel_context *context) intel_batchbuffer_flush_with_context(batch, context); intel_batchbuffer_free(batch); + + gem_sync(data->drm_fd, handle); } static void fill_render(data_t *data, uint32_t handle, -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt 2/4] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy()
From: Paulo Zanoni The way kms_fbc_crc works is that it does an operation that may trigger/invalidate/update FBC, then it sleeps for 300ms to wait for FBC to kick in again, then it calls "igt_assert(fbc_enabled())". This was causing problems where the BLT test would eventually fail in the fbc_eanbled() assertion. With the recent FBC move to front buffer rendering tracking, if we don't call gem_sync() after submitting render and blt commands, it may take much more than 300ms for FBC to be reenabled: i915_gem_execbuffer2() indirectly calls intel_fb_obj_invalidate(), which disables FBC, and then it is only reenabled when i915_gem_retire_work_handler() happens and indirectly calls intel_frontbuffer_flush(). Notice that while FBC is not yet enabled, the screen contents are correct, so this shouldn't really be a "bug". The gem_sync() call will make sure the long waits don't happen. With this, 300ms should be much more than enough: either we wait about 50ms for FBC to be re-enabled - intel_enable_fbc() uses a delayed work - or it's instantaneous - on the cases where we just do the nuke. Cc: Ville Syrjälä Signed-off-by: Paulo Zanoni --- tests/kms_fbc_crc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c index 32c3d98..7c3a412 100644 --- a/tests/kms_fbc_crc.c +++ b/tests/kms_fbc_crc.c @@ -122,7 +122,7 @@ static void fill_blt(data_t *data, intel_batchbuffer_flush(batch); intel_batchbuffer_free(batch); - gem_bo_busy(data->drm_fd, handle); + gem_sync(data->drm_fd, handle); } static void scratch_buf_init(struct igt_buf *buf, drm_intel_bo *bo) @@ -187,7 +187,7 @@ static void fill_render(data_t *data, uint32_t handle, intel_batchbuffer_free(batch); - gem_bo_busy(data->drm_fd, handle); + gem_sync(data->drm_fd, handle); } static bool fbc_enabled(data_t *data) -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON
On Mon, Dec 08, 2014 at 05:06:34PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static.
>
> We use WARN_ON(1) a lot in default switch statements though where we
> should always handle all cases. So add a new macro specifically for
> that.
>
> The idea to use __builtin_constant_p is from Chris Wilson.
>
> Cc: Damien Lespiau
> Cc: Chris Wilson
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 10 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
> 5 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d0e445eca9ce..f44a844a48db 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum
> intel_display_power_domain domain)
> case POWER_DOMAIN_INIT:
> return "INIT";
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> return "?";
> }
> }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 95dfa2dd35b9..b2ddc121654d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -57,8 +57,16 @@
> #define DRIVER_DESC "Intel Graphics"
> #define DRIVER_DATE "20141205"
>
> +static inline void __i915_warn_on(bool cond)
> +{
> + if (__builtin_constant_p(cond))
> + BUILD_BUG_ON(cond);
> +}
> +
> #undef WARN_ON
> -#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
> +#define WARN_ON(x) (__i915_warn_on((x)), WARN((x), "WARN_ON(" #x ")"))
> +
We're now evaluating x twice.
> +#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
>
> enum pipe {
> INVALID_PIPE = -1,
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index ac03a382000b..3b5807c11427 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
> pte |= GEN6_PTE_UNCACHED;
> break;
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> }
>
> return pte;
> @@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
> pte |= GEN6_PTE_UNCACHED;
> break;
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> }
>
> return pte;
> @@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
> else if (INTEL_INFO(dev)->gen >= 8)
> gen8_ppgtt_enable(dev);
> else
> - WARN_ON(1);
> + MISSING_CASE();
>
> if (ppgtt) {
> for_each_ring(ring, dev_priv, i) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d5153a4f90fe..b7155d5efc10 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
> cmd = 0;
> break;
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> return;
> }
>
> @@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc,
> u32 base)
> cntl |= CURSOR_MODE_256_ARGB_AX;
> break;
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> return;
> }
> cntl |= pipe << 28; /* Connect to correct pipe */
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 46de8d75b4bf..83ab530fee06 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1202,7 +1202,7 @@ void intel_uncore_init(struct drm_device *dev)
>
> switch (INTEL_INFO(dev)->gen) {
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> return;
> case 9:
> ASSIGN_WRITE_MMIO_VFUNCS(gen9);
> @@ -1300,7 +1300,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
> reg->val = I915_READ8(reg->offset);
> break;
> default:
> - WARN_ON(1);
> + MISSING_CASE();
> ret = -EINVAL;
> goto out;
> }
> --
> 2.1.1
>
_
Re: [Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
2014-12-08 12:17 GMT-02:00 Daniel Vetter : > On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote: >> 2014-12-08 6:42 GMT-02:00 Daniel Vetter : >> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: >> >> Remove the function intel_output_name() that is not used anywhere. >> >> >> >> This was partially found by using a static code analysis program called >> >> cppcheck. >> >> >> >> Signed-off-by: Rickard Strandqvist >> >> >> > >> > Queued for 3.20, thanks for the patch. >> >> This function was created for the "DDI personality" patches. We merged >> the function but never ended up merging the patch containing the >> callers... > > Oops, I've thought this is a renmant from the very first days of kms that > somehow stuck around. That's what I get for once not using git blame > excessively :( Want me to drop the patch again? I am not opposed to the removal of an unused function: I understand the value in the removal, and I also understand the reasons to keep it. I was just pointing the reason of why we got here: we merged patch 1/2 but ended up never merging patch 2/2 because we always spot some additional work required and it's a very low priority bug. If this function is removed, the next person to try to ressurrect the ddi personality patch can quickly resurrect it or even write a new implementation from scratch. It is your decision :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON
Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.
We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.
The idea to use __builtin_constant_p is from Chris Wilson.
v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.
Also use a temporary variable to only evaluate the condition once,
suggested by Damien.
Cc: Damien Lespiau
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Dave Gordon
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 8 +++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
5 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
- WARN_ON(1);
+ MISSING_CASE();
return "?";
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..9fac6344856e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,13 @@
#define DRIVER_DATE"20141205"
#undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+#define WARN_ON(x) ({ \
+ bool __i915_warn_cond = (x); \
+ if (__builtin_constant_p(__i915_warn_cond)) \
+ BUILD_BUG_ON(__i915_warn_cond); \
+ WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
}
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
}
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
- WARN_ON(1);
+ MISSING_CASE();
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev,
int cdclk)
cmd = 0;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
}
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202,7 @@ void intel_uncore_init(struct drm_device *dev)
switch (INTEL_INFO(dev)->gen) {
default:
- WARN_ON(1);
+ MISSING_CASE();
return;
case 9:
ASSIGN_WRITE_MMIO_VFUNCS(gen9);
@@ -1300,7 +1300,7 @@ int i915_reg_read_ioctl(struct drm_device *dev,
reg->val = I915_READ8(reg->offset);
break;
default:
- WARN_ON(1);
+ MISSING_CASE();
ret = -EINVAL;
goto o
[Intel-gfx] [PATCH v2] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
I was playing with clang and oh surprise! a warning trigerred by
-Wshift-overflow (gcc doesn't have this one):
WA_SET_BIT_MASKED(GEN7_GT_MODE,
GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift result
(0x2800200) requires 43 bits to represent, but 'int' only has 32 bits
[-Wshift-overflow]
WA_SET_BIT_MASKED(GEN7_GT_MODE,
^~~
drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
'WA_SET_BIT_MASKED'
WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0x)
Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
trying to shift it a bit more.
The other thing is that it's not the usual case of setting WA bits here, we
need to have separate mask and value.
To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
(unshifted) mask and the desired value and the rest of the patch ripples
through from it.
This bug was introduced when reworking the WA emission in:
Commit 7225342ab501befdb64bcec76ded41f5897c0855
Author: Mika Kuoppala
Date: Tue Oct 7 17:21:26 2014 +0300
drm/i915: Build workaround list in ring initialization
v2: Invert the order of the mask and value arguments (Daniel Vetter)
Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with
_MASKED_FIELD() (Jani Nikula)
Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
Add check to ensure the value is within the mask boundaries (Chris Wilson)
Cc: Mika Kuoppala
Cc: Arun Siluvery
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 13 ++---
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8 ++--
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc03fac..e0cd461 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -34,8 +34,15 @@
#define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
(port) == PORT_B ? (b) : (c))
-#define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
-#define _MASKED_BIT_DISABLE(a) ((a) << 16)
+#define _MASKED_FIELD(mask, value) ({ \
+ if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
+ BUILD_BUG_ON_MSG((value) & ~(mask), \
+"Incorrect value for mask"); \
+ (mask) << 16 | (value); })
+#define _MASKED_BIT_ENABLE(a) ({ typeof(a) _a = (a); _MASKED_FIELD(_a, _a); })
+#define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
+
+
/* PCI config space */
@@ -1284,7 +1291,7 @@ enum punit_power_well {
#define GEN6_WIZ_HASHING_8x8 GEN6_WIZ_HASHING(0, 0)
#define GEN6_WIZ_HASHING_8x4 GEN6_WIZ_HASHING(0, 1)
#define GEN6_WIZ_HASHING_16x4
GEN6_WIZ_HASHING(1, 0)
-#define GEN6_WIZ_HASHING_MASK
(GEN6_WIZ_HASHING(1, 1) << 16)
+#define GEN6_WIZ_HASHING_MASK
GEN6_WIZ_HASHING(1, 1)
#define GEN6_TD_FOUR_ROW_DISPATCH_DISABLE(1 << 5)
#define GFX_MODE 0x02520
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 78911e2..0f2febd 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6389,7 +6389,7 @@ static void gen6_init_clock_gating(struct drm_device *dev)
* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
*/
I915_WRITE(GEN6_GT_MODE,
- GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
ilk_init_lp_watermarks(dev);
@@ -6587,7 +6587,7 @@ static void haswell_init_clock_gating(struct drm_device
*dev)
* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
*/
I915_WRITE(GEN7_GT_MODE,
- GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
/* WaSwitchSolVfFArbitrationPriority:hsw */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
@@ -6684,7 +6684,7 @@ static void ivybridge_init_clock_gating(struct drm_device
*dev)
* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
*/
I915_WRITE(GEN7_GT_MODE,
- GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
snpcr = I915_READ(GEN6_MBCUNIT_SNPCR);
snpcr &= ~GEN6_MBC_SNPCR_MASK;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 79b4ca5..9deb152 100644
--- a/drivers/gpu/dr
Re: [Intel-gfx] [PATCH] drm/i915: Check mask/bit helper functions
On Mon, 08 Dec 2014, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Daniel Vetter wrote:
>> After a bit of irc discussion we've concluded that it would be prudent
>> to check that callers use the mask/enable paramters correctly. So add
>> a WARN_ON.
>>
>> Spurred by Damien's bugfix which added _MASKED_FIELD.
>>
>> v2: We use WARN_ON(1) a lot to catch default cases in switch blocks
>> which should always be extended. So this doesn't work really. Dunno
>> why gcc only started complaining when I've moved the WARN out of the
>> static inline helper to address a feedback from Jani.
>
> Ah, that would be precisely because of the static inline helper. The
> function parameter is never a builtin constant!
What I learned today: This holds for -O0.
>
> BR,
> Jani.
>
>
>>
>> Cc: Damien Lespiau
>> Cc: Chris Wilson
>> Cc: Jani Nikula
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 08a5a4ba52ac..e6a1db36928e 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -183,6 +183,8 @@ static void ilk_update_gt_irq(struct drm_i915_private
>> *dev_priv,
>> {
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> +WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
>> return;
>>
>> @@ -229,6 +231,8 @@ static void snb_update_pm_irq(struct drm_i915_private
>> *dev_priv,
>> {
>> uint32_t new_val;
>>
>> +WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> new_val = dev_priv->pm_irq_mask;
>> @@ -328,6 +332,8 @@ void ibx_display_interrupt_update(struct
>> drm_i915_private *dev_priv,
>> sdeimr &= ~interrupt_mask;
>> sdeimr |= (~enabled_irq_mask & interrupt_mask);
>>
>> +WARN_ON(enabled_irq_mask & ~interrupt_mask);
>> +
>> assert_spin_locked(&dev_priv->irq_lock);
>>
>> if (WARN_ON(!intel_irqs_enabled(dev_priv)))
>> --
>> 2.1.1
>>
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift
> result
> (0x2800200) requires 43 bits to represent, but 'int' only has 32
> bits
> [-Wshift-overflow]
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> ^~~
> drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
> 'WA_SET_BIT_MASKED'
> WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0x)
>
> Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
> trying to shift it a bit more.
>
> The other thing is that it's not the usual case of setting WA bits here, we
> need to have separate mask and value.
>
> To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
> (unshifted) mask and the desired value and the rest of the patch ripples
> through from it.
>
> This bug was introduced when reworking the WA emission in:
>
> Commit 7225342ab501befdb64bcec76ded41f5897c0855
> Author: Mika Kuoppala
> Date: Tue Oct 7 17:21:26 2014 +0300
>
> drm/i915: Build workaround list in ring initialization
>
> v2: Invert the order of the mask and value arguments (Daniel Vetter)
> Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with
> _MASKED_FIELD() (Jani Nikula)
> Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
> Add check to ensure the value is within the mask boundaries (Chris Wilson)
>
> Cc: Mika Kuoppala
> Cc: Arun Siluvery
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 ++---
> drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 ++--
> 3 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc03fac..e0cd461 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -34,8 +34,15 @@
> #define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
> (port) == PORT_B ? (b) : (c))
>
> -#define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> -#define _MASKED_BIT_DISABLE(a) ((a) << 16)
> +#define _MASKED_FIELD(mask, value) ({
> \
> + if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
> + BUILD_BUG_ON_MSG((value) & ~(mask), \
> + "Incorrect value for mask"); \
Imo just use WARN_ON, with my patch it'll do the right thing. And maybe
we'll use this in some context once where it's not a compile-time
constant and then the runtime check would be better.
With that addressed it's Reviewed-by: Daniel Vetter
I just realized that WA_REG has the order the other way round too, maybe
throw a follow-up on top?
-Daniel
> + (mask) << 16 | (value); })
> +#define _MASKED_BIT_ENABLE(a)({ typeof(a) _a = (a);
> _MASKED_FIELD(_a, _a); })
> +#define _MASKED_BIT_DISABLE(a) (_MASKED_FIELD((a), 0))
> +
> +
>
> /* PCI config space */
>
> @@ -1284,7 +1291,7 @@ enum punit_power_well {
> #define GEN6_WIZ_HASHING_8x8
> GEN6_WIZ_HASHING(0, 0)
> #define GEN6_WIZ_HASHING_8x4
> GEN6_WIZ_HASHING(0, 1)
> #define GEN6_WIZ_HASHING_16x4
> GEN6_WIZ_HASHING(1, 0)
> -#define GEN6_WIZ_HASHING_MASK
> (GEN6_WIZ_HASHING(1, 1) << 16)
> +#define GEN6_WIZ_HASHING_MASK
> GEN6_WIZ_HASHING(1, 1)
> #define GEN6_TD_FOUR_ROW_DISPATCH_DISABLE (1 << 5)
>
> #define GFX_MODE 0x02520
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 78911e2..0f2febd 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6389,7 +6389,7 @@ static void gen6_init_clock_gating(struct drm_device
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
> I915_WRITE(GEN6_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
>
> ilk_init_lp_watermarks(dev);
>
> @@ -6587,7 +6587,7 @@ static void haswell_init_clock_gating(struct drm_device
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
> I915_WRITE(GEN7_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
>
> /* WaSwitchSolVfFArbitrationPriority:hsw */
> I915_WRITE(GA
Re: [Intel-gfx] [RFC][PATCH 3/8] drm/i915: Pass new_config down do crtc_compute_clock
On Mon, Dec 08, 2014 at 05:21:04PM +0200, Ander Conselvan de Oliveira wrote:
> This reduces the number of direct users of crtc->new_config. At some
> point we'll be able to get rid of that pointer altogether, in favor
> of drm core state structs.
Just an aside: If we want to use drm_obj->state instead of new_config then
we deviate a bit from the helpers: The helpers only apply the new state to
state pointers in ->commit, we have our ->new_config pointer already set
in the compute/check config phase. Essentially it's not the same thing.
Now with the drm core you can just look up any state object you need, but
that'll lead to a bit more cumbersome code maybe. Otoh if we keep using
->new_config we need those in our ->atomic_check and then reapply in
->atomic_commit.
I'm ok with either approach really, so will leave it to you.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +-
> drivers/gpu/drm/i915/intel_ddi.c | 29
> drivers/gpu/drm/i915/intel_display.c | 131
> +++
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> 4 files changed, 94 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7d60d38..c1a9af9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -500,7 +500,8 @@ struct drm_i915_display_funcs {
> struct intel_crtc_state *);
> void (*get_plane_config)(struct intel_crtc *,
>struct intel_plane_config *);
> - int (*crtc_compute_clock)(struct intel_crtc *crtc);
> + int (*crtc_compute_clock)(struct intel_crtc *crtc,
> + struct intel_crtc_state *crtc_state);
> void (*crtc_enable)(struct drm_crtc *crtc);
> void (*crtc_disable)(struct drm_crtc *crtc);
> void (*off)(struct drm_crtc *crtc);
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 79c9776..970ca30 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -904,6 +904,7 @@ hsw_ddi_calculate_wrpll(int clock /* in Hz */,
>
> static bool
> hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
> +struct intel_crtc_state *crtc_state,
> struct intel_encoder *intel_encoder,
> int clock)
> {
> @@ -918,16 +919,16 @@ hsw_ddi_pll_select(struct intel_crtc *intel_crtc,
> WRPLL_DIVIDER_REFERENCE(r2) | WRPLL_DIVIDER_FEEDBACK(n2) |
> WRPLL_DIVIDER_POST(p);
>
> - intel_crtc->new_config->dpll_hw_state.wrpll = val;
> + crtc_state->dpll_hw_state.wrpll = val;
>
> - pll = intel_get_shared_dpll(intel_crtc);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state);
> if (pll == NULL) {
> DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> return false;
> }
>
> - intel_crtc->new_config->ddi_pll_sel =
> PORT_CLK_SEL_WRPLL(pll->id);
> + crtc_state->ddi_pll_sel = PORT_CLK_SEL_WRPLL(pll->id);
> }
>
> return true;
> @@ -1090,6 +1091,7 @@ found:
>
> static bool
> skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> +struct intel_crtc_state *crtc_state,
> struct intel_encoder *intel_encoder,
> int clock)
> {
> @@ -1139,11 +1141,11 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> } else /* eDP */
> return true;
>
> - intel_crtc->new_config->dpll_hw_state.ctrl1 = ctrl1;
> - intel_crtc->new_config->dpll_hw_state.cfgcr1 = cfgcr1;
> - intel_crtc->new_config->dpll_hw_state.cfgcr2 = cfgcr2;
> + crtc_state->dpll_hw_state.ctrl1 = ctrl1;
> + crtc_state->dpll_hw_state.cfgcr1 = cfgcr1;
> + crtc_state->dpll_hw_state.cfgcr2 = cfgcr2;
>
> - pll = intel_get_shared_dpll(intel_crtc);
> + pll = intel_get_shared_dpll(intel_crtc, crtc_state);
> if (pll == NULL) {
> DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(intel_crtc->pipe));
> @@ -1151,7 +1153,7 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> }
>
> /* shared DPLL id 0 is DPLL 1 */
> - intel_crtc->new_config->ddi_pll_sel = pll->id + 1;
> + crtc_state->ddi_pll_sel = pll->id + 1;
>
> return true;
> }
> @@ -1163,17 +1165,20 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> * For private DPLLs, compute_config() should do the selection for us. This
> * function should be folded into compute_config() eventually.
> */
> -bool intel_ddi_pll_select(struct intel_crtc *intel_crtc)
> +bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
> + struct intel_crtc_state *crtc_state)
> {
> struct drm_device *dev =
Re: [Intel-gfx] [RFC][PATCH 6/8] drm/i915: Remove intel_crtc->new_config pointer
On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:
> There are no more users of that pointer since the new config is now
> passed down the call chain during mode set. Also, when the switch to
> atomic happens, the right config (state) should be derived from an
> atomic state structure.
Ah, doesn't seem much work actually to remove our usage of ->new_config.
Which is nice since it'll align us more with how the helpers work.
So overall I think this patch series is good to go (but I've done only a
rather cursory high-level reading).
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 46
>
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 2 files changed, 10 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a9f3034..a032a1d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8583,7 +8583,6 @@ retry:
>
> intel_crtc = to_intel_crtc(crtc);
> intel_crtc->new_enabled = true;
> - intel_crtc->new_config = &intel_crtc->config;
> old->dpms_mode = connector->dpms;
> old->load_detect_temp = true;
> old->release_fb = NULL;
> @@ -8623,10 +8622,6 @@ retry:
>
> fail:
> intel_crtc->new_enabled = crtc->enabled;
> - if (intel_crtc->new_enabled)
> - intel_crtc->new_config = &intel_crtc->config;
> - else
> - intel_crtc->new_config = NULL;
> fail_unlock:
> if (ret == -EDEADLK) {
> drm_modeset_backoff(ctx);
> @@ -8653,7 +8648,6 @@ void intel_release_load_detect_pipe(struct
> drm_connector *connector,
> to_intel_connector(connector)->new_encoder = NULL;
> intel_encoder->new_crtc = NULL;
> intel_crtc->new_enabled = false;
> - intel_crtc->new_config = NULL;
> intel_set_mode(crtc, NULL, 0, 0, NULL);
>
> if (old->release_fb) {
> @@ -9839,14 +9833,8 @@ static void
> intel_modeset_update_staged_output_state(struct drm_device *dev)
> to_intel_crtc(encoder->base.crtc);
> }
>
> - for_each_intel_crtc(dev, crtc) {
> + for_each_intel_crtc(dev, crtc)
> crtc->new_enabled = crtc->base.enabled;
> -
> - if (crtc->new_enabled)
> - crtc->new_config = &crtc->config;
> - else
> - crtc->new_config = NULL;
> - }
> }
>
> /**
> @@ -10355,12 +10343,8 @@ intel_modeset_update_state(struct drm_device *dev,
> unsigned prepare_pipes)
> intel_modeset_commit_output_state(dev);
>
> /* Double check state. */
> - for_each_intel_crtc(dev, intel_crtc) {
> + for_each_intel_crtc(dev, intel_crtc)
> WARN_ON(intel_crtc->base.enabled !=
> intel_crtc_in_use(&intel_crtc->base));
> - WARN_ON(intel_crtc->new_config &&
> - intel_crtc->new_config != &intel_crtc->config);
> - WARN_ON(intel_crtc->base.enabled != !!intel_crtc->new_config);
> - }
>
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> if (!connector->encoder || !connector->encoder->crtc)
> @@ -10957,9 +10941,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
>
> *saved_mode = crtc->mode;
>
> - if (modeset_pipes)
> - to_intel_crtc(crtc)->new_config = pipe_config;
> -
> /*
>* See if the config requires any additional preparation, e.g.
>* to adjust global state with pipes off. We need to do this
> @@ -10984,7 +10965,13 @@ static int __intel_set_mode(struct drm_crtc *crtc,
> goto done;
>
> for_each_intel_crtc_masked(dev, modeset_pipes, intel_crtc) {
> - struct intel_crtc_state *state = intel_crtc->new_config;
> + struct intel_crtc_state *state;
> +
> + if (&intel_crtc->base == crtc)
> + state = pipe_config;
> + else
> + state = intel_crtc->config;
> +
> ret = dev_priv->display.crtc_compute_clock(intel_crtc,
> state);
> if (ret) {
> @@ -11014,7 +11001,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
> /* mode_set/enable/disable functions rely on a correct pipe
>* config. */
> to_intel_crtc(crtc)->config = *pipe_config;
> - to_intel_crtc(crtc)->new_config = &to_intel_crtc(crtc)->config;
>
> /*
>* Calculate and store various constants which
> @@ -11177,15 +11163,9 @@ static void intel_set_config_restore_state(struct
> drm_device *dev,
> int count;
>
> count = 0;
> - for_each_intel_crtc(dev, crtc) {
> + for_each_intel_crtc(dev, crtc)
>
Re: [Intel-gfx] [PATCH igt 1/4] lib: add igt_wait()
On Mon, Dec 08, 2014 at 02:12:41PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Just a little helper for code that needs to wait for a certain
> condition to happen. It has the nice advantage that it can survive the
> signal helper.
>
> Despite the callers added in this patch, there is another that will go
> in a separate patch, and another in a new IGT test file that I plan to
> push later.
>
> Signed-off-by: Paulo Zanoni
A library unit test in lib/tests would be awesome for igt_wait. You can
run them with $ make check. If you're a bit bored, that is ;-)
-Daniel
> ---
> lib/igt_aux.c | 18 +-
> lib/igt_aux.h | 40
> tests/pm_rpm.c | 28 +---
> 3 files changed, 46 insertions(+), 40 deletions(-)
>
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 3051d84..180141e 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -518,29 +518,13 @@ enum igt_runtime_pm_status
> igt_get_runtime_pm_status(void)
> * Waits until for the driver to switch to into the desired runtime PM
> status,
> * with a 10 second timeout.
> *
> - * Some subtests call this function while the signal helper is active, so we
> - * can't assume each usleep() call will sleep for 100ms.
> - *
> * Returns:
> * True if the desired runtime PM status was attained, false if the operation
> * timed out.
> */
> bool igt_wait_for_pm_status(enum igt_runtime_pm_status status)
> {
> - struct timeval start, end, diff;
> -
> - igt_assert(gettimeofday(&start, NULL) == 0);
> - do {
> - if (igt_get_runtime_pm_status() == status)
> - return true;
> -
> - usleep(100 * 1000);
> -
> - igt_assert(gettimeofday(&end, NULL) == 0);
> - timersub(&end, &start, &diff);
> - } while (diff.tv_sec < 10);
> -
> - return false;
> + return igt_wait(igt_get_runtime_pm_status() == status, 1, 100);
> }
>
> /* Functions with prefix kmstest_ independent of cairo library are pulled out
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index 6c83c53..48c495b 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -30,6 +30,7 @@
>
> #include
> #include
> +#include
>
> extern drm_intel_bo **trash_bos;
> extern int num_trash_bos;
> @@ -90,4 +91,43 @@ void intel_require_memory(uint32_t count, uint32_t size,
> unsigned mode);
> #define min(a, b) ((a) < (b) ? (a) : (b))
> #define max(a, b) ((a) > (b) ? (a) : (b))
>
> +/**
> + * igt_wait:
> + * @COND: condition to wait
> + * @timeout_ms: timeout in milliseconds
> + * @interval_ms: amount of time we try to sleep between COND checks
> + *
> + * Waits until COND evaluates to true or the timeout passes.
> + *
> + * It is safe to call this macro if the signal helper is active. The only
> + * problem is that the usleep() calls will return early, making us evaluate
> COND
> + * too often, possibly eating valuable CPU cycles.
> + *
> + * Returns:
> + * True of COND evaluated to true, false otherwise.
> + */
> +#define igt_wait(COND, timeout_ms, interval_ms) ({ \
> + struct timeval start_, end_, diff_; \
> + int elapsed_ms_;\
> + bool ret_ = false; \
> + \
> + igt_assert(gettimeofday(&start_, NULL) == 0); \
> + do {\
> + if (COND) { \
> + ret_ = true;\
> + break; \
> + } \
> + \
> + usleep(interval_ms * 1000); \
> + \
> + igt_assert(gettimeofday(&end_, NULL) == 0); \
> + timersub(&end_, &start_, &diff_); \
> + \
> + elapsed_ms_ = diff_.tv_sec * 1000 + \
> + diff_.tv_usec / 1000; \
> + } while (elapsed_ms_ < timeout_ms); \
> + \
> + ret_; \
> +})
> +
> #endif /* IGT_AUX_H */
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index c120d75..b7f9635 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -153,24 +153,16 @@ static uint64_t get_residency(uint32_t type)
>
> static bool pc8_plus_residency_changed(unsigned int timeout_sec)
> {
> - unsigned i
[Intel-gfx] [PATCH 0/5] sanitize hda/i915 interface using the component fw
The current hda/i915 interface to enable/disable power wells and query the CD clock rate is based on looking up the relevant i915 module symbols from the hda driver. By using the component framework we can get rid of some global state tracking in the i915 driver and pave the way to fully decouple the two drivers: once support is added to enable/disable the HDMI functionality dynamically in the hda driver, it can bind/unbind itself from the i915 component master, without the need to keep a reference on the i915 module. This also gets rid of the problem that currently the i915 driver exposes the interface only on HSW and BDW, while it's also needed at least on VLV/CHV. Imre Deak (5): drm/i915: add dev_to_i915_priv helper drm/i915: add component support ALSA: hda: pass chip to all i915 interface functions ALSA: hda: add component support drm/i915: remove unused power_well/get_cdclk_freq api drivers/gpu/drm/i915/i915_dma.c | 80 drivers/gpu/drm/i915/i915_drv.c | 15 ++-- drivers/gpu/drm/i915/intel_drv.h| 8 ++ drivers/gpu/drm/i915/intel_runtime_pm.c | 56 -- include/drm/i915_component.h| 38 ++ include/drm/i915_powerwell.h| 37 -- sound/pci/hda/hda_i915.c| 126 +--- sound/pci/hda/hda_i915.h| 12 +-- sound/pci/hda/hda_intel.c | 16 ++-- sound/pci/hda/hda_priv.h| 7 ++ 10 files changed, 238 insertions(+), 157 deletions(-) create mode 100644 include/drm/i915_component.h delete mode 100644 include/drm/i915_powerwell.h -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: remove unused power_well/get_cdclk_freq api
After switching to using the component interface this API isn't needed
any more.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 56 -
include/drm/i915_powerwell.h| 37 --
2 files changed, 93 deletions(-)
delete mode 100644 include/drm/i915_powerwell.h
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8a2bd18..0c9ab32 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -31,7 +31,6 @@
#include "i915_drv.h"
#include "intel_drv.h"
-#include
/**
* DOC: runtime pm
@@ -50,8 +49,6 @@
* present for a given platform.
*/
-static struct i915_power_domains *hsw_pwr;
-
#define for_each_power_well(i, power_well, domain_mask, power_domains) \
for (i = 0; \
i < (power_domains)->power_well_count && \
@@ -1098,10 +1095,8 @@ int intel_power_domains_init(struct drm_i915_private
*dev_priv)
*/
if (IS_HASWELL(dev_priv->dev)) {
set_power_wells(power_domains, hsw_power_wells);
- hsw_pwr = power_domains;
} else if (IS_BROADWELL(dev_priv->dev)) {
set_power_wells(power_domains, bdw_power_wells);
- hsw_pwr = power_domains;
} else if (IS_CHERRYVIEW(dev_priv->dev)) {
set_power_wells(power_domains, chv_power_wells);
} else if (IS_VALLEYVIEW(dev_priv->dev)) {
@@ -1145,8 +1140,6 @@ void intel_power_domains_fini(struct drm_i915_private
*dev_priv)
* the power well is not enabled, so just enable it in case
* we're going to unload/reload. */
intel_display_set_init_power(dev_priv, true);
-
- hsw_pwr = NULL;
}
static void intel_power_domains_resume(struct drm_i915_private *dev_priv)
@@ -1355,52 +1348,3 @@ void intel_runtime_pm_enable(struct drm_i915_private
*dev_priv)
pm_runtime_put_autosuspend(device);
}
-/* Display audio driver power well request */
-int i915_request_power_well(void)
-{
- struct drm_i915_private *dev_priv;
-
- if (!hsw_pwr)
- return -ENODEV;
-
- dev_priv = container_of(hsw_pwr, struct drm_i915_private,
- power_domains);
- intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
- return 0;
-}
-EXPORT_SYMBOL_GPL(i915_request_power_well);
-
-/* Display audio driver power well release */
-int i915_release_power_well(void)
-{
- struct drm_i915_private *dev_priv;
-
- if (!hsw_pwr)
- return -ENODEV;
-
- dev_priv = container_of(hsw_pwr, struct drm_i915_private,
- power_domains);
- intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
- return 0;
-}
-EXPORT_SYMBOL_GPL(i915_release_power_well);
-
-/*
- * Private interface for the audio driver to get CDCLK in kHz.
- *
- * Caller must request power well using i915_request_power_well() prior to
- * making the call.
- */
-int i915_get_cdclk_freq(void)
-{
- struct drm_i915_private *dev_priv;
-
- if (!hsw_pwr)
- return -ENODEV;
-
- dev_priv = container_of(hsw_pwr, struct drm_i915_private,
- power_domains);
-
- return intel_ddi_get_cdclk_freq(dev_priv);
-}
-EXPORT_SYMBOL_GPL(i915_get_cdclk_freq);
diff --git a/include/drm/i915_powerwell.h b/include/drm/i915_powerwell.h
deleted file mode 100644
index baa6f11..000
--- a/include/drm/i915_powerwell.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/**
- *
- * Copyright 2013 Intel Inc.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- *
- *
[Intel-gfx] [PATCH 3/5] ALSA: hda: pass chip to all i915 interface functions
chip is already passed to most of the i915 interface functions, unify
things by passing it also to the rest. This will be needed by an
upcoming patch adding component support.
No functional change.
Signed-off-by: Imre Deak
---
sound/pci/hda/hda_i915.c | 6 +++---
sound/pci/hda/hda_i915.h | 12 ++--
sound/pci/hda/hda_intel.c | 16
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index d4d0375..4e4b733 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -35,7 +35,7 @@ static int (*get_power)(void);
static int (*put_power)(void);
static int (*get_cdclk)(void);
-int hda_display_power(bool enable)
+int hda_display_power(struct azx *chip, bool enable)
{
if (!get_power || !put_power)
return -ENODEV;
@@ -85,7 +85,7 @@ void haswell_set_bclk(struct azx *chip)
}
-int hda_i915_init(void)
+int hda_i915_init(struct azx *chip)
{
int err = 0;
@@ -111,7 +111,7 @@ int hda_i915_init(void)
return err;
}
-int hda_i915_exit(void)
+int hda_i915_exit(struct azx *chip)
{
if (get_power) {
symbol_put(i915_request_power_well);
diff --git a/sound/pci/hda/hda_i915.h b/sound/pci/hda/hda_i915.h
index e6072c6..4d77d73 100644
--- a/sound/pci/hda/hda_i915.h
+++ b/sound/pci/hda/hda_i915.h
@@ -17,18 +17,18 @@
#define __SOUND_HDA_I915_H
#ifdef CONFIG_SND_HDA_I915
-int hda_display_power(bool enable);
+int hda_display_power(struct azx *chip, bool enable);
void haswell_set_bclk(struct azx *chip);
-int hda_i915_init(void);
-int hda_i915_exit(void);
+int hda_i915_init(struct azx *chip);
+int hda_i915_exit(struct azx *chip);
#else
-static inline int hda_display_power(bool enable) { return 0; }
+static inline int hda_display_power(struct azx *chip, bool enable) { return 0;
}
static inline void haswell_set_bclk(struct azx *chip) { return; }
-static inline int hda_i915_init(void)
+static inline int hda_i915_init(struct azx *chip);
{
return -ENODEV;
}
-static inline int hda_i915_exit(void)
+static inline int hda_i915_exit(struct azx *chip)
{
return 0;
}
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 5ac0d39..f3b5dcd 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -825,7 +825,7 @@ static int azx_suspend(struct device *dev)
pci_save_state(pci);
pci_set_power_state(pci, PCI_D3hot);
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
- hda_display_power(false);
+ hda_display_power(chip, false);
return 0;
}
@@ -845,7 +845,7 @@ static int azx_resume(struct device *dev)
return 0;
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
- hda_display_power(true);
+ hda_display_power(chip, true);
haswell_set_bclk(chip);
}
pci_set_power_state(pci, PCI_D0);
@@ -898,7 +898,7 @@ static int azx_runtime_suspend(struct device *dev)
azx_enter_link_reset(chip);
azx_clear_irq_pending(chip);
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL)
- hda_display_power(false);
+ hda_display_power(chip, false);
return 0;
}
@@ -924,7 +924,7 @@ static int azx_runtime_resume(struct device *dev)
return 0;
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
- hda_display_power(true);
+ hda_display_power(chip, true);
haswell_set_bclk(chip);
}
@@ -1150,8 +1150,8 @@ static int azx_free(struct azx *chip)
release_firmware(chip->fw);
#endif
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
- hda_display_power(false);
- hda_i915_exit();
+ hda_display_power(chip, false);
+ hda_i915_exit(chip);
}
kfree(hda);
@@ -1910,13 +1910,13 @@ static int azx_probe_continue(struct azx *chip)
/* Request power well for Haswell HDA controller and codec */
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
#ifdef CONFIG_SND_HDA_I915
- err = hda_i915_init();
+ err = hda_i915_init(chip);
if (err < 0) {
dev_err(chip->card->dev,
"Error request power-well from i915\n");
goto out_free;
}
- err = hda_display_power(true);
+ err = hda_display_power(chip, true);
if (err < 0) {
dev_err(chip->card->dev,
"Cannot turn on display power on i915\n");
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: add dev_to_i915_priv helper
This will be needed by later patches, so factor it out.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.c | 15 ++-
drivers/gpu/drm/i915/intel_drv.h | 8
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 71be3c9..32c2e33 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -923,10 +923,10 @@ i915_pci_remove(struct pci_dev *pdev)
static int i915_pm_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct drm_i915_private *dev_priv = dev_to_i915_priv(dev);
+ struct drm_device *drm_dev = dev_priv->dev;
- if (!drm_dev || !drm_dev->dev_private) {
+ if (!drm_dev || !dev_priv) {
dev_err(dev, "DRM not initialized, aborting suspend.\n");
return -ENODEV;
}
@@ -939,8 +939,7 @@ static int i915_pm_suspend(struct device *dev)
static int i915_pm_suspend_late(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct drm_device *drm_dev = dev_to_i915_priv(dev)->dev;
/*
* We have a suspedn ordering issue with the snd-hda driver also
@@ -959,8 +958,7 @@ static int i915_pm_suspend_late(struct device *dev)
static int i915_pm_resume_early(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct drm_device *drm_dev = dev_to_i915_priv(dev)->dev;
if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
@@ -970,8 +968,7 @@ static int i915_pm_resume_early(struct device *dev)
static int i915_pm_resume(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct drm_device *drm_dev = dev_to_i915_priv(dev)->dev;
if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 61a88fa..3de7a55 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -775,6 +775,14 @@ static inline unsigned int intel_num_planes(struct
intel_crtc *crtc)
return INTEL_INFO(crtc->base.dev)->num_sprites[crtc->pipe] + 1;
}
+static inline struct drm_i915_private *dev_to_i915_priv(struct device *dev)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct drm_device *drm_dev = pci_get_drvdata(pdev);
+
+ return drm_dev->dev_private;
+}
+
/* intel_fifo_underrun.c */
bool intel_set_cpu_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
enum pipe pipe, bool enable);
--
1.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/i915: pass which operation triggered the frontbuffer tracking
On Mon, Dec 08, 2014 at 02:09:15PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to port FBC to the frontbuffer tracking infrastructure, but
> for that we need to know what caused the object invalidation/flush so
> we can react accordingly: CPU mmaps need manual, GTT mmaps and
> flips don't need handling and ring rendering needs nukes.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h| 7 +++
> drivers/gpu/drm/i915/i915_gem.c| 10 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 11 +++
> drivers/gpu/drm/i915/intel_frontbuffer.c | 15 ++-
> 5 files changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9d694f1..ea3cc81 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -685,6 +685,13 @@ struct intel_context {
> struct list_head link;
> };
>
> +enum fb_op_origin {
> + ORIGIN_GTT,
> + ORIGIN_CPU,
> + ORIGIN_RENDER,
Maybe GPU instead of RENDER since it includes the blitter? Render
typically only means the render ring in gem code. And maybe add an I915_
prefix or so at least to the enum.
Anyway that's it from me with bikesheds, lgtm overall.
-Daniel
> + ORIGIN_FLIP,
> +};
> +
> struct i915_fbc {
> unsigned long size;
> unsigned threshold;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index de241eb..7ef12e8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2321,7 +2321,7 @@ i915_gem_object_move_to_inactive(struct
> drm_i915_gem_object *obj)
> list_move_tail(&vma->mm_list, &vm->inactive_list);
> }
>
> - intel_fb_obj_flush(obj, true);
> + intel_fb_obj_flush(obj, true, ORIGIN_RENDER);
>
> list_del_init(&obj->ring_list);
>
> @@ -3665,7 +3665,7 @@ i915_gem_object_flush_gtt_write_domain(struct
> drm_i915_gem_object *obj)
> old_write_domain = obj->base.write_domain;
> obj->base.write_domain = 0;
>
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
>
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> @@ -3688,7 +3688,7 @@ i915_gem_object_flush_cpu_write_domain(struct
> drm_i915_gem_object *obj,
> old_write_domain = obj->base.write_domain;
> obj->base.write_domain = 0;
>
> - intel_fb_obj_flush(obj, false);
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
>
> trace_i915_gem_object_change_domain(obj,
> obj->base.read_domains,
> @@ -3745,7 +3745,7 @@ i915_gem_object_set_to_gtt_domain(struct
> drm_i915_gem_object *obj, bool write)
> }
>
> if (write)
> - intel_fb_obj_invalidate(obj, NULL);
> + intel_fb_obj_invalidate(obj, NULL, ORIGIN_GTT);
>
> trace_i915_gem_object_change_domain(obj,
> old_read_domains,
> @@ -4072,7 +4072,7 @@ i915_gem_object_set_to_cpu_domain(struct
> drm_i915_gem_object *obj, bool write)
> }
>
> if (write)
> - intel_fb_obj_invalidate(obj, NULL);
> + intel_fb_obj_invalidate(obj, NULL, ORIGIN_CPU);
>
> trace_i915_gem_object_change_domain(obj,
> old_read_domains,
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 0c25f62..af290e6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -965,7 +965,7 @@ i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> obj->dirty = 1;
> i915_gem_request_assign(&obj->last_write_req, req);
>
> - intel_fb_obj_invalidate(obj, ring);
> + intel_fb_obj_invalidate(obj, ring, ORIGIN_RENDER);
>
> /* update for the implicit flush after a batch */
> obj->base.write_domain &= ~I915_GEM_GPU_DOMAINS;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 588b618..633fb9a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -841,13 +841,15 @@ void intel_ddi_set_vc_payload_alloc(struct drm_crtc
> *crtc, bool state);
>
> /* intel_frontbuffer.c */
> void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
> - struct intel_engine_cs *ring);
> + struct intel_engine_cs *ring,
> + enum fb_op_origin origin);
> void intel_frontbuffer_flip_prepare(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_frontbuffer_flip_complete(s
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On 08/12/14 16:27, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
>> I was playing with clang and oh surprise! a warning trigerred by
>> -Wshift-overflow (gcc doesn't have this one):
[snip]
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 79b4ca5..9deb152 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -739,6 +739,9 @@ static int wa_add(struct drm_i915_private *dev_priv,
>> #define WA_CLR_BIT_MASKED(addr, mask) \
>> WA_REG(addr, _MASKED_BIT_DISABLE(mask), (mask) & 0x)
>>
>> +#define WA_SET_FIELD_MASKED(addr, mask, value) \
>> +WA_REG(addr, _MASKED_FIELD(mask, value), mask)
>> +
>> #define WA_SET_BIT(addr, mask) WA_REG(addr, I915_READ(addr) | (mask), mask)
>> #define WA_CLR_BIT(addr, mask) WA_REG(addr, I915_READ(addr) & ~(mask), mask)
Not your changes, but:
* WA_{SET,CLR}_BIT() above look dubious and don't seem to be used anyway
* dev_priv->workarounds.reg[idx].mask = mask;
The mask field is set but not used in intel_ring_workarounds_emit() or
intel_logical_ring_workarounds_emit(), only in debugfs printout.
And it's redundant since the 'value' incorporates the bit(field) mask
and the new target value into one parameter, hence 3rd parameter of
WA_REG() is surplus and calculating it in WA_{SET,CLR_BIT_MASKED() is
also redundant.
Unless I've missed something?
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/i915: also do frontbuffer tracking on pwrites
On Mon, Dec 08, 2014 at 02:09:16PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need this for FBC, and possibly for PSR too.
>
> Signed-off-by: Paulo Zanoni
Hm, this might fix some cursor update failures if userspace only pwrites
and doesn't follow suite with a cursor ioctl update call. Not sure this
ever happens, but definitely makes sense.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7ef12e8..b8c906e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1117,6 +1117,10 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
> *data,
> ret = i915_gem_phys_pwrite(obj, args, file);
> else
> ret = i915_gem_shmem_pwrite(dev, obj, args, file);
> +
> + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> + } else {
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> }
>
> out:
> --
> 2.1.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: add component support
Register a component master to be used to interface with the
snd_hda_intel driver. This is meant to replace the same interface that
is currently based on module symbol lookup.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 80 +
include/drm/i915_component.h| 38
2 files changed, 118 insertions(+)
create mode 100644 include/drm/i915_component.h
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 887d88f..6e0f3be 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -35,6 +35,8 @@
#include
#include "intel_drv.h"
#include
+#include
+#include
#include "i915_drv.h"
#include "i915_trace.h"
#include
@@ -600,6 +602,80 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
}
}
+static void i915_component_get_power(struct device *dev)
+{
+ intel_display_power_get(dev_to_i915_priv(dev), POWER_DOMAIN_AUDIO);
+}
+
+static void i915_component_put_power(struct device *dev)
+{
+ intel_display_power_put(dev_to_i915_priv(dev), POWER_DOMAIN_AUDIO);
+}
+
+/* Get CDCLK in kHz */
+static int i915_component_get_cdclk_freq(struct device *dev)
+{
+ struct drm_i915_private *dev_priv = dev_to_i915_priv(dev);
+ int ret;
+
+ if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
+ return -ENODEV;
+
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
+ ret = intel_ddi_get_cdclk_freq(dev_priv);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
+
+ return ret;
+}
+
+static struct i915_component_ops component_ops = {
+ .owner = THIS_MODULE,
+ .get_power = i915_component_get_power,
+ .put_power = i915_component_put_power,
+ .get_cdclk = i915_component_get_cdclk_freq,
+};
+
+static int i915_component_master_bind(struct device *dev)
+{
+ return component_bind_all(dev, &component_ops);
+}
+
+static void i915_component_master_unbind(struct device *dev)
+{
+ return component_unbind_all(dev, &component_ops);
+}
+
+static const struct component_master_ops i915_component_master_ops = {
+ .bind = i915_component_master_bind,
+ .unbind = i915_component_master_unbind,
+};
+
+static int i915_component_master_match(struct device *dev, void *data)
+{
+ /* snd_hda_intel is the only supported component */
+ return !strcmp(dev->driver->name, "snd_hda_intel");
+}
+
+static void i915_component_master_init(struct drm_i915_private *dev_priv)
+{
+ struct device *dev = dev_priv->dev->dev;
+ struct component_match *match = NULL;
+ int ret;
+
+ component_match_add(dev, &match, i915_component_master_match, NULL);
+ ret = component_master_add_with_match(dev, &i915_component_master_ops,
+ match);
+ if (ret < 0)
+ DRM_ERROR("failed to add component master (%d)\n", ret);
+ /* continue with reduced functionality */
+}
+
+static void i915_component_master_cleanup(struct drm_i915_private *dev_priv)
+{
+ /* the following is ok to call even if component_master_add failed */
+ component_master_del(dev_priv->dev->dev, &i915_component_master_ops);
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @dev: DRM device
@@ -830,6 +906,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_runtime_pm_enable(dev_priv);
+ i915_component_master_init(dev_priv);
+
return 0;
out_power_well:
@@ -870,6 +948,8 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
+ i915_component_master_cleanup(dev_priv);
+
ret = i915_gem_suspend(dev);
if (ret) {
DRM_ERROR("failed to idle hardware: %d\n", ret);
diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h
new file mode 100644
index 000..44542c2
--- /dev/null
+++ b/include/drm/i915_component.h
@@ -0,0 +1,38 @@
+/**
+ *
+ * Copyright 2014 Intel Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE
[Intel-gfx] [PATCH 4/5] ALSA: hda: add component support
Register a component to be used to interface with the i915 driver. This
is meant to replace the current interface which is based on module
symbol lookups.
Note that currently we keep the existing behavior and pin the i915
module while the hda driver is loaded. Using the component interface
allows us to remove this dependency once support for dynamically
enabling / disabling the HDMI functionality from the bind/unbind hooks
is added.
Signed-off-by: Imre Deak
---
sound/pci/hda/hda_i915.c | 120 ---
sound/pci/hda/hda_priv.h | 7 +++
2 files changed, 89 insertions(+), 38 deletions(-)
diff --git a/sound/pci/hda/hda_i915.c b/sound/pci/hda/hda_i915.c
index 4e4b733..01f5a5d 100644
--- a/sound/pci/hda/hda_i915.c
+++ b/sound/pci/hda/hda_i915.c
@@ -18,8 +18,10 @@
#include
#include
+#include
+#include
+#include
#include
-#include
#include "hda_priv.h"
#include "hda_i915.h"
@@ -31,32 +33,33 @@
#define AZX_REG_EM40x100c
#define AZX_REG_EM50x1010
-static int (*get_power)(void);
-static int (*put_power)(void);
-static int (*get_cdclk)(void);
-
int hda_display_power(struct azx *chip, bool enable)
{
- if (!get_power || !put_power)
+ struct hda_component *hdac = &chip->component;
+
+ if (!hdac->i915_ops)
return -ENODEV;
pr_debug("HDA display power %s \n",
enable ? "Enable" : "Disable");
if (enable)
- return get_power();
+ hdac->i915_ops->get_power(hdac->i915_dev);
else
- return put_power();
+ hdac->i915_ops->put_power(hdac->i915_dev);
+
+ return 0;
}
void haswell_set_bclk(struct azx *chip)
{
int cdclk_freq;
unsigned int bclk_m, bclk_n;
+ struct hda_component *hdac = &chip->component;
- if (!get_cdclk)
+ if (!hdac->i915_ops)
return;
- cdclk_freq = get_cdclk();
+ cdclk_freq = hdac->i915_ops->get_cdclk(hdac->i915_dev);
switch (cdclk_freq) {
case 337500:
bclk_m = 16;
@@ -84,47 +87,87 @@ void haswell_set_bclk(struct azx *chip)
azx_writew(chip, EM5, bclk_n);
}
+static int hda_component_bind(struct device *hda_dev,
+ struct device *i915_dev, void *data)
+{
+ struct snd_card *card = dev_get_drvdata(hda_dev);
+ struct azx *chip = card->private_data;
+ struct i915_component_ops *i915_ops = data;
+ struct hda_component *hdac = &chip->component;
+
+ if (WARN_ON(!(i915_ops->get_power && i915_ops->put_power &&
+ i915_ops->get_cdclk)))
+ return -EINVAL;
+
+ /*
+* Atm, we don't support dynamic unbinding initiated by the component
+* master, so pin its containing module until we unbind.
+*/
+ if (!try_module_get(i915_ops->owner))
+ return -ENODEV;
+
+ hdac->i915_dev = i915_dev;
+ hdac->i915_ops = i915_ops;
+
+ return 0;
+}
+
+static void hda_component_unbind(struct device *hda_dev,
+struct device *i915_dev, void *data)
+{
+ struct snd_card *card = dev_get_drvdata(hda_dev);
+ struct azx *chip = card->private_data;
+ struct hda_component *hdac = &chip->component;
+
+ module_put(hdac->i915_ops->owner);
+
+ hdac->i915_dev = NULL;
+ hdac->i915_ops = NULL;
+}
+
+static struct component_ops hda_component_ops = {
+ .bind = hda_component_bind,
+ .unbind = hda_component_unbind,
+};
int hda_i915_init(struct azx *chip)
{
- int err = 0;
+ struct device *dev = &chip->pci->dev;
+ int ret;
- get_power = symbol_request(i915_request_power_well);
- if (!get_power) {
- pr_warn("hda-i915: get_power symbol get fail\n");
- return -ENODEV;
- }
-
- put_power = symbol_request(i915_release_power_well);
- if (!put_power) {
- symbol_put(i915_request_power_well);
- get_power = NULL;
- return -ENODEV;
- }
-
- get_cdclk = symbol_request(i915_get_cdclk_freq);
- if (!get_cdclk) /* may have abnormal BCLK and audio playback rate */
- pr_warn("hda-i915: get_cdclk symbol get fail\n");
-
+ ret = component_add(dev, &hda_component_ops);
+ if (ret < 0)
+ goto out_err;
+
+ /*
+* Atm, we don't support deferring the component binding, so make sure
+* i915 is loaded and that the binding successfully completes.
+*/
+ ret = request_module("i915");
+ if (ret < 0)
+ goto out_err;
+
+ if (!chip->component.i915_ops) {
+ ret = -ENODEV;
+ goto out_component_del;
+ }
+
- pr_debug("HDA driver get symbol successfully from i915 module\n");
+ pr_debug("hda-i915: bound to component master\n");
+
+ return 0;
+
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On Mon, Dec 08, 2014 at 04:50:13PM +, Dave Gordon wrote:
> On 08/12/14 16:27, Daniel Vetter wrote:
> > On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
> >> I was playing with clang and oh surprise! a warning trigerred by
> >> -Wshift-overflow (gcc doesn't have this one):
>
> [snip]
>
> >> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> index 79b4ca5..9deb152 100644
> >> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >> @@ -739,6 +739,9 @@ static int wa_add(struct drm_i915_private *dev_priv,
> >> #define WA_CLR_BIT_MASKED(addr, mask) \
> >>WA_REG(addr, _MASKED_BIT_DISABLE(mask), (mask) & 0x)
> >>
> >> +#define WA_SET_FIELD_MASKED(addr, mask, value) \
> >> + WA_REG(addr, _MASKED_FIELD(mask, value), mask)
> >> +
> >> #define WA_SET_BIT(addr, mask) WA_REG(addr, I915_READ(addr) | (mask),
> >> mask)
> >> #define WA_CLR_BIT(addr, mask) WA_REG(addr, I915_READ(addr) & ~(mask),
> >> mask)
>
> Not your changes, but:
>
> * WA_{SET,CLR}_BIT() above look dubious and don't seem to be used anyway
>
> * dev_priv->workarounds.reg[idx].mask = mask;
>
> The mask field is set but not used in intel_ring_workarounds_emit() or
> intel_logical_ring_workarounds_emit(), only in debugfs printout.
> And it's redundant since the 'value' incorporates the bit(field) mask
> and the new target value into one parameter, hence 3rd parameter of
> WA_REG() is surplus and calculating it in WA_{SET,CLR_BIT_MASKED() is
> also redundant.
>
> Unless I've missed something?
The mask is used to test that we correctly set/clear W/A values in i-g-t
tests. Imagine the W/A being "clear bit 2", we have a generic (value,
mask) to check that we do indeed do that.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Fix the write setting up the WIZ hashing mode
On 08/12/14 16:22, Damien Lespiau wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift
> result
> (0x2800200) requires 43 bits to represent, but 'int' only has 32
> bits
> [-Wshift-overflow]
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> ^~~
> drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
> 'WA_SET_BIT_MASKED'
> WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0x)
>
> Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
> trying to shift it a bit more.
>
> The other thing is that it's not the usual case of setting WA bits here, we
> need to have separate mask and value.
>
> To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
> (unshifted) mask and the desired value and the rest of the patch ripples
> through from it.
>
> This bug was introduced when reworking the WA emission in:
>
> Commit 7225342ab501befdb64bcec76ded41f5897c0855
> Author: Mika Kuoppala
> Date: Tue Oct 7 17:21:26 2014 +0300
>
> drm/i915: Build workaround list in ring initialization
>
> v2: Invert the order of the mask and value arguments (Daniel Vetter)
> Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with
> _MASKED_FIELD() (Jani Nikula)
> Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
> Add check to ensure the value is within the mask boundaries (Chris Wilson)
>
> Cc: Mika Kuoppala
> Cc: Arun Siluvery
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 ++---
> drivers/gpu/drm/i915/intel_pm.c | 6 +++---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 ++--
> 3 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc03fac..e0cd461 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -34,8 +34,15 @@
> #define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
> (port) == PORT_B ? (b) : (c))
>
> -#define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> -#define _MASKED_BIT_DISABLE(a) ((a) << 16)
> +#define _MASKED_FIELD(mask, value) ({
> \
> + if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
> + BUILD_BUG_ON_MSG((value) & ~(mask), \
> + "Incorrect value for mask"); \
> + (mask) << 16 | (value); })
For even more compile- and run-time robustness we could check that
'mask' and 'value' each fit in 16 bits, as we have an explicit '16' in
there already.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm/i915: Introduce FBC DocBook.
On Mon, Dec 08, 2014 at 02:09:11PM -0200, Paulo Zanoni wrote:
> From: Rodrigo Vivi
>
> No functional changes.
>
> v2 (Paulo): Rebase.
>
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Paulo Zanoni
Some suggestions to polish the documentation a bit below. I've merged
patch 1 right away to avoid further rebase pain.
Thanks, Daniel
> ---
> Documentation/DocBook/drm.tmpl | 5
> drivers/gpu/drm/i915/intel_fbc.c | 57
> ++--
> 2 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 85287cb..8b780ab 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3926,6 +3926,11 @@ int num_ioctls;
> !Idrivers/gpu/drm/i915/intel_psr.c
>
>
> + Frame Buffer Compression (FBC)
> +!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
> +!Idrivers/gpu/drm/i915/intel_fbc.c
> +
> +
> DPIO
> !Pdrivers/gpu/drm/i915/i915_reg.h DPIO
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index f1eeb86..7686573 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -21,20 +21,31 @@
> * DEALINGS IN THE SOFTWARE.
> */
>
> -#include "intel_drv.h"
> -#include "i915_drv.h"
> -
> -/* FBC, or Frame Buffer Compression, is a technique employed to compress the
> - * framebuffer contents in-memory, aiming at reducing the required bandwidth
> +/**
> + * DOC: Frame Buffer Compression (FBC)
> + *
> + * FBC is a technique employed to compress the framebuffer contents
> + * in-memory, aiming at reducing the required bandwidth
> * during in-memory transfers and, therefore, reduce the power packet.
The above paragraph imo doesn't make sense. And duplicates what's below,
so just delete it.
> *
> + * FBC is primarily a memory power savings technology. That is the major
> + * benefit is to the memory power while displaying the processor graphics
> + * information to the display. FBC works by compressing the amount of memory
> + * used by the display. It means that it is total transparent to user space.
This reads a bit too much like marketing for my taste ;-) What about:
* FBC tries to save memory bandwidth (and so power consumption) by
* compressing the amount of memory used by the display. It is total
* transparent to user space and completely handled in the kernel.
> + *
> * The benefits of FBC are mostly visible with solid backgrounds and
> - * variation-less patterns.
> + * variation-less patterns. It comes from keeping the memory footprint small
> + * and having fewer memory pages opened and accessed for refreshing the
> display.
> *
> - * FBC-related functionality can be enabled by the means of the
> - * i915.i915_fbc_enable parameter
> + * i915 is responsible to reserve stolen memory for FBC and configure its
> + * offset on proper register. The hardware takes care of all
^registers
> + * compress/decompress. However there are many known cases where we have to
> + * forcibly disable it to allow proper screen updates.
Mayb add "... using the frontbuffer tracking infrastructure." At least
when that's the case ;-)
> */
>
> +#include "intel_drv.h"
> +#include "i915_drv.h"
> +
> static void i8xx_fbc_disable(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -318,6 +329,12 @@ static void gen7_fbc_enable(struct drm_crtc *crtc)
> DRM_DEBUG_KMS("enabled fbc on plane %c\n",
> plane_name(intel_crtc->plane));
> }
>
> +/**
> + * intel_fbc_enabled - Is FBC enabled?
> + * @dev: the drm_device
> + *
> + * This function is used to verify the current state of FBC.
This needs a FIXME: This should be tracked in the plane config eventually
instead of queried at runtime for most callers.
> + */
> bool intel_fbc_enabled(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -325,6 +342,18 @@ bool intel_fbc_enabled(struct drm_device *dev)
> return dev_priv->fbc.enabled;
> }
>
> +/**
> + * bdw_fbc_sw_flush - FBC Software Flush for Broadwell.
> + * @dev: the drm_device
> + * @value: Value to be set on MSG_FBC_REND_STATE. Possible values are
> + * FBC_REND_NUKE and FBC_REND_CACHE_CLEAN.
> + *
> + * This function is needed on Broadwell to perform Nuke or Cache clean on
> + * software side over MMIO.
> + * On Broadwell, due a hardware bug, MSG_FBC_REND_STATE stay in a forbidden
> + * address that has a huge risk of causing GPU Hangs if set with LRI on some
> + * command streamers.
> + */
I guess with the frontbuffer tracking we'll just have invalidate/flush
entry points and this becomes a static function? In that case I wouldn't
bother documenting it - maybe do a comment referencing the wa name if
there is one.
> void bdw_fbc_sw_flush(struct drm_device *dev, u32 value)
> {
> struct drm_i915_private *d
