Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
Hi Jani, > -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Wednesday, August 12, 2015 2:20 PM > To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > modeset > > On Wed, 12 Aug 2015, "Yang, Libin" wrote: > > Hi Jani, > > > >> -Original Message- > >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> Sent: Tuesday, August 11, 2015 4:14 PM > >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> modeset > >> > >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> > Hi Jani, > >> > > >> >> -Original Message- > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> Sent: Tuesday, August 11, 2015 3:14 PM > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS > in > >> >> modeset > >> >> > >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> > Hi Jani, > >> >> > > >> >> > Thanks for careful reviewing for all the patches, please > >> >> > see my comments. > >> >> > > >> >> >> -Original Message- > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> Sent: Monday, August 10, 2015 8:10 PM > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > intel- > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper > N/CTS > >> in > >> >> >> modeset > >> >> >> > >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > >> >> >> > From: Libin Yang > >> >> >> > > >> >> >> > When modeset occurs and the TMDS frequency is set to > some > >> >> >> > speical value, the N/CTS need to be set manually if audio > >> >> >> > is playing. > >> >> >> > >> >> >> When modeset occurs, we disable everything, and then re- > enable > >> >> >> everything, and notify the audio driver every step of the way. > IIUC > >> >> >> there should be no audio playing across the modeset, and > when > >> the > >> >> >> modeset is complete and we've set the valid ELD, the audio > driver > >> >> >> should > >> >> >> call the callback from the earlier patches to set the correct > audio > >> >> >> rate. > >> >> >> > >> >> >> Why is this patch needed? Please enlighten me. > >> >> > > >> >> > Please image this scenario: when audio is playing, the gfx driver > >> >> > does the modeset. In this situation, after modeset, audio driver > >> >> > will do nothing and continue playing. And audio driver will not > call > >> >> > set_ncts. > >> >> > >> >> Why does the audio driver not do anything here? Whenever > there's > >> a > >> >> modeset, the graphics driver will disable audio and invalidate the > >> ELD, > >> >> which should cause an interrupt to notify the audio driver about > >> >> this. This is no different from a hot-unplug, in fact I can't see how > >> >> the audio driver could even detect whether there's been a > hotplug > >> or > >> >> not > >> >> when there's a codec disable/enable. > >> > > >> > Yes, it will trigger an interrupt to audio driver when unplug > >> > and another interrupt for hotplug. But from audio driver, > >> > we will not stop the playing and resume the playing based > >> > on the hotplug or modeset. The audio is always playing during > >> > the hotplug/modeset. > >> > >> But the whole display, and consequently ELD, might have changed > >> during > >> the hotplug, why do you assume you can just keep playing?! The > >> display > >> might even have changed from HDMI to DP or vice versa. > > > > The eld info changing will not impact the audio playing. > > Actually, you can image the monitor as a digital speaker, just > > like the headphone to the analog audio. Unplug the speaker > > will not impact on the audio playing. Of course , there is a > > little difference, when monitor hotplug, in the interrupt, > > we may change the codec configuration dynamically. > > > > And audio driver supply the mechanism to stop the > > audio playing when hotplug if the HW requires. > > > >> > >> We've also been putting a lot of effort into not depending on > previous > >> state when enabling the outputs, for more reliability. We generally > >> don't do partial changes, we disable everything and then enable > >> again. And now you're suggesting we look at some register which for > all > >> we know may have been valid for some other display? > > > > In the patch, it will not depend on previous state, I think. We > > read the register value which is based on the state after modeset. > > Okay, let's have the patches cleaned up and see. It'll be easier and > quicker to solicit more review on that than this expanding
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: Hi Mika/Dave/Michel, I saw the patch of using LRI for root pointer update has been merged to drm-intel. When we consider i915 driver to run inside a virtual machine, e.g. with XenGT, we may still need Mika's this patch like below: " if (intel_vgpu_active(ppgtt->base.dev)) gen8_preallocate_top_level_pdps(ppgtt); " Could you share with us your opinion? Thanks in advance! Hi Zhiyuan, The change looks ok to me. If you need to preallocate the PDPs, gen8_ppgtt_init is the right place to do it. Only add a similar vgpu_active check to disable the LRI updates (in gen8_emit_bb_start). The reason behind is that LRI command will make shadow PPGTT implementation hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 driver, and then track every guest page table change in order to update shadow page table accordingly. The problem of page table updates with GPU command is that they cannot be trapped by hypervisor to finish the shadow page table update work. In XenGT, the only change we have is the command scan in context submission. But that is not exactly the right time to do shadow page table update. Mika's patch can address the problem nicely. With the preallocation, the root pointers in EXECLIST context will always keep the same. Then we can treat any attempt to change guest PPGTT with GPU commands as malicious behavior. Thanks! Regards, -Zhiyuan On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: Dave Gordon writes: On 10/06/15 12:42, Michel Thierry wrote: On 5/29/2015 1:53 PM, Michel Thierry wrote: On 5/29/2015 12:05 PM, Michel Thierry wrote: On 5/22/2015 6:04 PM, Mika Kuoppala wrote: With BDW/SKL and 32bit addressing mode only, the hardware preloads pdps. However the TLB invalidation only has effect on levels below the pdps. This means that if pdps change, hw might access with stale pdp entry. To combat this problem, preallocate the top pdps so that hw sees them as immutable for each context. Cc: Ville Syrjälä Cc: Rafael Barbalho Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50 + drivers/gpu/drm/i915/i915_reg.h | 17 + drivers/gpu/drm/i915/intel_lrc.c| 15 +-- 3 files changed, 68 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0ffd459..1a5ad4c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -941,6 +941,48 @@ err_out: return ret; } +/* With some architectures and 32bit legacy mode, hardware pre-loads the + * top level pdps but the tlb invalidation only invalidates the lower levels. + * This might lead to hw fetching with stale pdp entries if top level + * structure changes, ie va space grows with dynamic page tables. + */ Is this still necessary if we reload PDPs via LRI instructions whenever the address map has changed? That always (AFAICT) causes sufficient invalidation, so then we might not need to preallocate at all :) LRI reload gets my vote. Please ignore this patch. -Mika .Dave. ___ 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
[Intel-gfx] [PATCH] drm/i915: Boost priority for the mmioflip task
We don't want pageflips to be delayed by any arbitrary user process, so move their task to the high priority workqueue. Signed-off-by: Chris Wilson Cc: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 9cca8f76ebcd..bb40f1c163ec 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11214,7 +11214,7 @@ static int intel_queue_mmio_flip(struct drm_device *dev, mmio_flip->crtc = to_intel_crtc(crtc); INIT_WORK(&mmio_flip->work, intel_mmio_flip_work_func); - schedule_work(&mmio_flip->work); + queue_work(system_highpri_wq, &mmio_flip->work); return 0; } -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/8] *** DSC Inital Design RFC ***
From: vkorjani s RFC is for feature Display Stream Compression (DSC) for BXT, It is a VESA defined standard to compress and decompress image in display streams in a link independent manner. Some of the basic requirements of the standard are to support higher resolution on a given display link with fewer lanes or lower rate. DSC is architected to work in current Intel Display Engine design without modification how current display pipeline works. DSC hardware as per HAS is in b/n port and MIPI DSI controller. so most of the changes are at port level. At begining of frame display can start sending valid pixels to DSC at normal rate, DSC start compressing this image according to pps parameters programmed already to 8bpp, 10bpp, 12bpp. /*This bitstream is temprory stored in output buffer and sent as byte stream to DSI controller as soon as it is valid. */ Following are the set of patches as per initial design in HLD, one can refer DSC HLD if more details about the changes is required. Tested these patches on fulsim simulation enviornment. vkorjani (8): drm/915/bxt: Adding DSC VBT parameter and PPS structures drm/i915/bxt: Adding registers to support DSC drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters for DSC drm/i915/bxt: MIPI DSI Register Programming for DSC drm/i915/bxt: Program MIPI_DPI_RESOLUTION for DSC drm/i915/bxt: Enable/Disable DSC and programme PPS. drm: Add support for pps and compression mode command packet drm/i915/bxt: Send PPS packet and compression mode command packet drivers/gpu/drm/drm_mipi_dsi.c | 29 +++ drivers/gpu/drm/i915/i915_drv.h|2 + drivers/gpu/drm/i915/i915_reg.h| 126 + drivers/gpu/drm/i915/intel_bios.h | 74 drivers/gpu/drm/i915/intel_dsi.c | 274 ++-- drivers/gpu/drm/i915/intel_dsi.h |5 + drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 23 +++ drivers/gpu/drm/i915/intel_dsi_pll.c | 24 ++- include/drm/drm_mipi_dsi.h |4 +- include/video/mipi_display.h |3 + 10 files changed, 539 insertions(+), 25 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 4/8] drm/i915/bxt: MIPI DSI Register Programming for DSC
From: vkorjani
For compression enabled, the number of bytes in active
region cannot be calculated just by multiplying number
of pixels and bits per pixel, formula in HLD is
ceil((ceil(pixels/num_slice) * bpp) / 8) * num_slice
hence modifying txbyteclkhs() to accommodate calculation
for DSC Enable/Disable and created a separate
function pixel_to_bytes().
Using modified txbyteclkhs to calculate MIPI_HS_TX_TIMEOUT
As per HLD for computing MIPI_HS_TX_TIMEOUT per line,
1) calculate number of bytes in active region
2) calculate number of bytes in blanking region
Add above two and compute byteclkhs.
similarly for MIPI_HX_TX_TIMEOUT per frame, Add bytes in
active and blanking region should be calculated separately.
Signed-off-by: vkorjani
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/intel_dsi.c | 74 ++
1 file changed, 59 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 36fcb86..e566750 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -760,12 +760,48 @@ static u16 txclkesc(u32 divider, unsigned int us)
}
}
+static int compute_num_slice(struct drm_encoder *encoder)
+{
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+
+ return DIV_ROUND_UP(intel_dsi->pps_data.pic_height*
+ intel_dsi->pps_data.pic_width,
+ intel_dsi->pps_data.slice_height*
+ intel_dsi->pps_data.slice_width);
+}
+
+static u32 pixel_to_bytes(struct drm_encoder *encoder, u16 pixels, int bpp)
+{
+
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+ int num_slice;
+
+ if (intel_dsi->dsc_enable) {
+ num_slice = compute_num_slice(encoder);
+ if (num_slice <= 0)
+ num_slice = 1;
+ bpp = intel_dsi->pps_data.bits_per_pixel / 16;
+ return DIV_ROUND_UP((DIV_ROUND_UP(pixels, num_slice)) * bpp, 8)
+ * num_slice;
+ } else
+ return DIV_ROUND_UP((pixels * bpp), 8);
+}
+
+
/* return pixels in terms of txbyteclkhs */
-static u16 txbyteclkhs(u16 pixels, int bpp, int lane_count,
- u16 burst_mode_ratio)
+static u16 txbyteclkhs(struct drm_encoder *encoder, u16 pixels, int bpp,
+ int lane_count, u16 burst_mode_ratio, bool dsc_calc)
{
- return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp * burst_mode_ratio,
-8 * 100), lane_count);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+ u32 pixel_bytes;
+
+ if (intel_dsi->dsc_enable && dsc_calc) {
+ pixel_bytes = pixel_to_bytes(encoder, pixels, bpp);
+ return DIV_ROUND_UP(DIV_ROUND_UP(pixel_bytes *
+ burst_mode_ratio, 100), lane_count);
+ } else
+ return DIV_ROUND_UP(DIV_ROUND_UP(pixels * bpp *
+ burst_mode_ratio, 8 * 100), lane_count);
}
static void set_dsi_timings(struct drm_encoder *encoder,
@@ -800,12 +836,14 @@ static void set_dsi_timings(struct drm_encoder *encoder,
vbp = mode->vtotal - mode->vsync_end;
/* horizontal values are in terms of high speed byte clock */
- hactive = txbyteclkhs(hactive, bpp, lane_count,
- intel_dsi->burst_mode_ratio);
- hfp = txbyteclkhs(hfp, bpp, lane_count, intel_dsi->burst_mode_ratio);
- hsync = txbyteclkhs(hsync, bpp, lane_count,
- intel_dsi->burst_mode_ratio);
- hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi->burst_mode_ratio);
+ hactive = txbyteclkhs(encoder, hactive, bpp, lane_count,
+ intel_dsi->burst_mode_ratio, true);
+ hfp = txbyteclkhs(encoder, hfp, bpp, lane_count,
+ intel_dsi->burst_mode_ratio, true);
+ hsync = txbyteclkhs(encoder, hsync, bpp, lane_count,
+ intel_dsi->burst_mode_ratio, true);
+ hbp = txbyteclkhs(encoder, hbp, bpp, lane_count,
+ intel_dsi->burst_mode_ratio, true);
for_each_dsi_port(port, intel_dsi->ports) {
if (IS_BROXTON(dev)) {
@@ -851,6 +889,7 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
unsigned int bpp = intel_crtc->config->pipe_bpp;
u32 val, tmp;
u16 mode_hdisplay;
+ u32 hactive, hblank;
DRM_DEBUG_KMS("pipe %c\n", pipe_name(intel_crtc->pipe));
@@ -943,18 +982,23 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
* said value is recommended.
*/
+ hactive = pixel_to_bytes(encoder, adjusted_mode->hdisplay, bpp);
+ hblank = pixel_to_bytes(encoder, (adjusted_mode->htotal -
+ adjusted_mode->hsync_
[Intel-gfx] [RFC 2/8] drm/i915/bxt: Adding registers to support DSC
From: vkorjani
This patch adds register definitions required to support
DSC feature.
Signed-off-by: vkorjani
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/i915_reg.h | 126 +
drivers/gpu/drm/i915/intel_bios.h |1 +
2 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0b1d7ff..b41da94 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7666,12 +7666,15 @@ enum skl_disp_power_wells {
#define CMD_MODE_DATA_WIDTH_8_BIT (3 << 13)
#define CMD_MODE_DATA_WIDTH_OPTION1 (4 << 13)
#define CMD_MODE_DATA_WIDTH_OPTION2 (5 << 13)
+#define CMD_MODE_DATA_WIDTH_OPTION2_SKIP_LAST (6 << 13)
+#define CMD_MODE_DATA_WIDTH_OPTION2_SKIP_LAST2 (7 << 13)
#define VID_MODE_FORMAT_MASK (0xf << 7)
#define VID_MODE_NOT_SUPPORTED(0 << 7)
#define VID_MODE_FORMAT_RGB565(1 << 7)
#define VID_MODE_FORMAT_RGB666(2 << 7)
#define VID_MODE_FORMAT_RGB666_LOOSE (3 << 7)
#define VID_MODE_FORMAT_RGB888(4 << 7)
+#define VID_MODE_FORMAT_COMPRESSED (8 << 7)
#define CMD_MODE_CHANNEL_NUMBER_SHIFT 5
#define CMD_MODE_CHANNEL_NUMBER_MASK (3 << 5)
#define VID_MODE_CHANNEL_NUMBER_SHIFT 3
@@ -7965,6 +7968,7 @@ enum skl_disp_power_wells {
#define BXT_PIPE_SELECT_C (2 << 7)
#define BXT_PIPE_SELECT_B (1 << 7)
#define BXT_PIPE_SELECT_A (0 << 7)
+#define BXT_DSC_ENABLE (1 << 3)
#define _MIPIA_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb108)
#define _MIPIC_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb908)
@@ -8010,6 +8014,128 @@ enum skl_disp_power_wells {
_MIPIA_READ_DATA_VALID, _MIPIC_READ_DATA_VALID)
#define READ_DATA_VALID(n)(1 << (n))
+#define DSC_A_PICTURE_PARAMETER_SET_0(dev_priv->mipi_mmio_base + 0xb200)
+#define DSC_A_PICTURE_PARAMETER_SET_1(dev_priv->mipi_mmio_base + 0xb204)
+#define DSC_A_PICTURE_PARAMETER_SET_2(dev_priv->mipi_mmio_base + 0xb208)
+#define DSC_A_PICTURE_PARAMETER_SET_3(dev_priv->mipi_mmio_base + 0xb20c)
+#define DSC_A_PICTURE_PARAMETER_SET_4(dev_priv->mipi_mmio_base + 0xb210)
+#define DSC_A_PICTURE_PARAMETER_SET_5(dev_priv->mipi_mmio_base + 0xb214)
+#define DSC_A_PICTURE_PARAMETER_SET_6(dev_priv->mipi_mmio_base + 0xb218)
+#define DSC_A_PICTURE_PARAMETER_SET_7(dev_priv->mipi_mmio_base + 0xb21c)
+#define DSC_A_PICTURE_PARAMETER_SET_8(dev_priv->mipi_mmio_base + 0xb220)
+#define DSC_A_PICTURE_PARAMETER_SET_9(dev_priv->mipi_mmio_base + 0xb224)
+#define DSC_A_PICTURE_PARAMETER_SET_10 (dev_priv->mipi_mmio_base + 0xb228)
+#define DSC_A_PICTURE_PARAMETER_SET_11 (dev_priv->mipi_mmio_base + 0xb22c)
+#define DSC_A_PICTURE_PARAMETER_SET_12 (dev_priv->mipi_mmio_base + 0xb260)
+#define DSC_A_PICTURE_PARAMETER_SET_13 (dev_priv->mipi_mmio_base + 0xb264)
+#define DSC_A_PICTURE_PARAMETER_SET_14 (dev_priv->mipi_mmio_base + 0xb268)
+#define DSC_A_PICTURE_PARAMETER_SET_15 (dev_priv->mipi_mmio_base + 0xb26c)
+#define DSC_A_PICTURE_PARAMETER_SET_16 (dev_priv->mipi_mmio_base + 0xb270)
+#define DSC_A_RC_BUF_THRESH_0_3 (dev_priv->mipi_mmio_base + 0xb230)
+#define DSC_A_RC_BUF_THRESH_4_7 (dev_priv->mipi_mmio_base + 0xb234)
+#define DSC_A_RC_BUF_THRESH_8_11(dev_priv->mipi_mmio_base + 0xb238)
+#define DSC_A_RC_BUF_THRESH_12_13 (dev_priv->mipi_mmio_base + 0xb23C)
+#define DSC_A_RC_RANGE_PARAMETERS_0 (dev_priv->mipi_mmio_base + 0xb240)
+#define DSC_A_RC_RANGE_PARAMETERS_1 (dev_priv->mipi_mmio_base + 0xb244)
+#define DSC_A_RC_RANGE_PARAMETERS_2 (dev_priv->mipi_mmio_base + 0xb248)
+#define DSC_A_RC_RANGE_PARAMETERS_3 (dev_priv->mipi_mmio_base + 0xb24C)
+#define DSC_A_RC_RANGE_PARAMETERS_4 (dev_priv->mipi_mmio_base + 0xb250)
+#define DSC_A_RC_RANGE_PARAMETERS_5 (dev_priv->mipi_mmio_base + 0xb254)
+#define DSC_A_RC_RANGE_PARAMETERS_6 (dev_priv->mipi_mmio_base + 0xb258)
+#define DSC_A_RC_RANGE_PARAMETERS_7 (dev_priv->mipi_mmio_base + 0xb25C)
+
+#define DSC_C_PICTURE_PARAMETER_SET_0(dev_priv->mipi_mmio_base + 0xba00)
+#define DSC_C_PICTURE_PARAMETER_SET_1(dev_priv->mipi_mmio_base + 0xba04)
+#define DSC_C_PICTURE_PARAMETER_SET_2(dev_priv->mipi_mmio_base + 0xba08)
+#define DSC_C_PICTURE_PARAMETER_SET_3(dev_priv->mipi_mmio_base + 0xba0c)
+#define DSC_C_PICTURE_PARAMETER_SET_4(dev_priv->mipi_mmio_base + 0xba10)
+#define DSC_C_PICTURE_PARAMETER_SET_5(dev_priv->mipi_mmio_base + 0xba14)
+#define DSC_C_PICTURE_PARAMETER_SET_6(dev_priv->mip
[Intel-gfx] [RFC 1/8] drm/915/bxt: Adding DSC VBT parameter and PPS structures
From: vkorjani
Adding pps structure as per VESA DSC v1.1 spec.
Adding "vbt_dsc_param" vbt structure to store DSC info
vbt_dsc_param and pps structures are made part of intel_vbt_data.
Signed-off-by: vkorjani
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_bios.h | 73 +
2 files changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1a9b0f..78f293f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1492,6 +1492,8 @@ struct intel_vbt_data {
union child_device_config *child_dev;
struct ddi_vbt_port_info ddi_port_info[I915_MAX_PORTS];
+ struct vbt_dsc_param dsc_param;
+ struct vbt_dsc_capablity_param capab_param;
};
enum intel_ddb_partitioning {
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index af0b476..8bc7c87 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -778,6 +778,79 @@ int intel_parse_bios(struct drm_device *dev);
#define MIPI_DSI_UNDEFINED_PANEL_ID0
#define MIPI_DSI_GENERIC_PANEL_ID 1
+struct vesa_dsc_rc_range_param {
+ u8 range_min_qp;
+ u8 range_max_qp;
+ u8 range_bpg_offset;
+};
+
+struct vesa_dsc_rc_param {
+ u16 model_size;
+ u8 rc_edge_factor;
+ u8 rc_quant_incr_limit0;
+ u8 rc_quant_incr_limit1;
+ u8 rc_tgt_offset_hi;
+ u8 rc_tgt_offset_lo;
+ u8 rc_buf_thresh[14];
+ struct vesa_dsc_rc_range_param rc_range[16];
+};
+
+struct vesa_dsc_pps_data {
+ u8 dsc_ver_major;
+ u8 dsc_ver_minor;
+ u8 pps_identifier;
+ u8 bit_per_comp;
+ u8 line_buf_depth;
+ u8 block_pred_enable;
+ u8 convert_rgb;
+ u8 enable_422;
+ u8 enable_vbr;
+ u16 bits_per_pixel;
+ u16 pic_width;
+ u16 pic_height;
+ u16 slice_width;
+ u16 slice_height;
+ u16 chunk_size;
+ u16 initial_xmit_delay;
+ u16 initial_dec_delay;
+ u8 initial_scale_value;
+ u16 scale_increment_interval;
+ u16 scale_decrement_interval;
+ u8 first_line_bpg_offset;
+ u16 nfl_bpg_offset;
+ u16 slice_bpg_offset;
+ u16 initial_offset;
+ u16 final_offset;
+ u8 flatness_min_qp;
+ u8 flatness_max_qp;
+ struct vesa_dsc_rc_param rc_param;
+};
+
+struct vbt_dsc_capablity_param {
+ u8 block_prediction_allowed;
+ u8 disp_bpc;
+ u8 line_buf_bit_depth;
+ u16 picture_height;
+ u16 picture_width;
+ u16 rate_buffer_size;
+ u16 slice_height;
+ u16 slice_width;
+ u8 supported_dsc_version;
+ u8 vbr_allowed;
+};
+struct vbt_dsc_param {
+ u8 dsc_support;
+ u8 valid_pps;
+ u8 block_prediction;
+ u8 panel_bpc;
+ u8 bit_depth;
+ u16 rate_buffer_size;
+ u16 slice_height;
+ u16 slice_width;
+ u8 dsc_version;
+ struct vesa_dsc_pps_data pps_data;
+};
+
struct mipi_config {
u16 panel_id;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/8] drm/i915/bxt: Program MIPI_DPI_RESOLUTION for DSC
From: vkorjani
Program the MIPI_DPI_RESOLUTION register horizontal
resolution using the byte_to_pixels() DSC specific
function in case of compression enabled.
For non-compressed video, the number of pixels
in active region are computed as usual.
Change-Id: Iacea79352fa67a40a1d305494539f7c99f2715d0
Signed-off-by: vkorjani
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/intel_dsi.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index e566750..9963ec2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -901,6 +901,9 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder)
mode_hdisplay += intel_dsi->pixel_overlap;
}
+ if (intel_dsi->dsc_enable)
+ mode_hdisplay = pixel_to_bytes(encoder, mode_hdisplay, bpp);
+
for_each_dsi_port(port, intel_dsi->ports) {
if (IS_VALLEYVIEW(dev)) {
/*
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 8/8] drm/i915/bxt: Send PPS packet and compression mode command packet
From: vkorjani
This patch adds code to send pps long packet and compression mode
command packet.
Signed-off-by: vkorjani
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f893d37..813b126 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -292,6 +292,15 @@ static void generic_exec_sequence(struct intel_dsi
*intel_dsi, const u8 *data)
}
}
+static void send_dsc_pps_block(struct intel_dsi *intel_dsi)
+{
+ u8 *data;
+
+ mipi_dsi_dsc_pps_write_buffer(dsi_device, NULL, 0);
+ data = (u8 *)&intel_dsi->pps_data;
+ mipi_dsi_dsc_pps_write_buffer(dsi_device, data, 128);
+}
+
static int vbt_panel_prepare(struct drm_panel *panel)
{
struct vbt_panel *vbt_panel = to_vbt_panel(panel);
@@ -306,6 +315,9 @@ static int vbt_panel_prepare(struct drm_panel *panel)
sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
generic_exec_sequence(intel_dsi, sequence);
+ if (intel_dsi->dsc_enable)
+ send_dsc_pps_block(intel_dsi);
+
return 0;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 6/8] drm/i915/bxt: Enable/Disable DSC and programme PPS.
From: vkorjani
Program the PPS data from intel_dsc->vesa_dsc_pps_data
into display controller register DSCx_PICTURE_PARAMETER_SET_x.
DSC should be enabled in MIPI Port control register, after
programming PPS register
Disable DSC in disable sequence after disabling port.
Signed-off-by: vkorjani
---
drivers/gpu/drm/i915/intel_dsi.c | 197 +-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 9963ec2..c011966 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -411,7 +411,12 @@ static void intel_dsi_port_disable(struct intel_encoder
*encoder)
/* de-assert ip_tg_enable signal */
port_ctrl = GET_DSI_PORT_CTRL(dev);
temp = I915_READ(port_ctrl);
- I915_WRITE(port_ctrl, temp & ~DPI_ENABLE);
+ temp &= ~DPI_ENABLE;
+ if (intel_dsi->dsc_enable) {
+ temp &= ~BXT_DSC_ENABLE;
+ temp &= ~RGB_FLIP_TO_BGR;
+ }
+ I915_WRITE(port_ctrl, temp);
POSTING_READ(port_ctrl);
}
}
@@ -876,6 +881,188 @@ static void set_dsi_timings(struct drm_encoder *encoder,
}
}
+static void intel_dsi_program_pps(struct drm_encoder *encoder, int port)
+{
+ struct drm_device *dev = encoder->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
+ u32 tmp = 0;
+
+ tmp |= intel_dsi->pps_data.dsc_ver_major << 0;
+ tmp |= intel_dsi->pps_data.dsc_ver_minor << 4;
+ tmp |= intel_dsi->pps_data.bit_per_comp << 8;
+ tmp |= intel_dsi->pps_data.line_buf_depth << 12;
+ tmp |= intel_dsi->pps_data.block_pred_enable << 16;
+ tmp |= intel_dsi->pps_data.convert_rgb << 17;
+ tmp |= intel_dsi->pps_data.enable_422 << 18;
+ tmp |= intel_dsi->pps_data.enable_vbr << 19;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_0(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.bits_per_pixel << 0;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_1(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.pic_height << 0;
+ tmp |= intel_dsi->pps_data.pic_width << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_2(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.slice_height << 0;
+ tmp |= intel_dsi->pps_data.slice_width << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_3(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.initial_xmit_delay << 0;
+ tmp |= intel_dsi->pps_data.initial_dec_delay << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_4(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.scale_increment_interval << 0;
+ tmp |= intel_dsi->pps_data.scale_decrement_interval << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_5(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.initial_scale_value << 0;
+ tmp |= intel_dsi->pps_data.first_line_bpg_offset << 8;
+ tmp |= intel_dsi->pps_data.flatness_min_qp << 16;
+ tmp |= intel_dsi->pps_data.flatness_max_qp << 24;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_6(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.slice_bpg_offset << 0;
+ tmp |= intel_dsi->pps_data.nfl_bpg_offset << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_7(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.final_offset << 0;
+ tmp |= intel_dsi->pps_data.initial_offset << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_8(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.rc_param.model_size << 0;
+ tmp |= intel_dsi->pps_data.rc_param.rc_edge_factor << 16;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_9(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.rc_param.rc_quant_incr_limit0 << 0;
+ tmp |= intel_dsi->pps_data.rc_param.rc_quant_incr_limit1 << 8;
+ tmp |= intel_dsi->pps_data.rc_param.rc_tgt_offset_hi << 16;
+ tmp |= intel_dsi->pps_data.rc_param.rc_tgt_offset_lo << 20;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_10(port), tmp);
+
+ tmp = 0;
+ tmp |= intel_dsi->pps_data.chunk_size << 0;
+ tmp |= 0x04 << 16;
+ tmp |= 0x78 << 20;
+ I915_WRITE(DSC_PICTURE_PARAMETER_SET_16(port), tmp);
+
+ tmp = 0;
+ tmp = intel_dsi->pps_data.rc_param.rc_buf_thresh[0] << 0 |
+ intel_dsi->pps_data.rc_param.rc_buf_thresh[1] << 8 |
+ intel_dsi->pps_data.rc_param.rc_buf_thresh[2] << 16|
+ intel_dsi->pps_data.rc_param.rc_buf_thresh[3] << 24;
+ I915_WRITE(DSC_RC_BUF_THRESH_0_3(port), tmp);
+
+ tmp = 0;
+ tmp = intel_dsi->pps_data.rc_param.rc_buf_thresh[4] << 0 |
+ intel_dsi->pps_data.rc_param.rc_buf_thresh[5] << 8 |
+ intel_dsi->pps_data.rc_par
[Intel-gfx] [RFC 7/8] drm: Add support for pps and compression mode command packet
From: vkorjani
After enabling DSC we need to send compression mode command packet
and pps data packet, for which 2 new data types are added
07h Compression Mode Data Type Write , short write, 2 parameters
0Ah PPS Long Write (word count determines number of bytes)
This patch adds support to send these packets.
Cc: David Airlie
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: vkorjani
---
drivers/gpu/drm/drm_mipi_dsi.c | 29 +
include/drm/drm_mipi_dsi.h |4 +++-
include/video/mipi_display.h |3 +++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2d5ca8ee..cd536d1 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -521,6 +521,35 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device
*dsi,
EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer);
/**
+ * mipi_dsi_dsc_pps_write_buffer() - transmit a DSC command with payload
+ * @dsi: DSI peripheral device
+ * @data: buffer containing data to be transmitted
+ * @len: size of transmission buffer
+ *
+ * function will automatically choose the right data type depending on
+ * the command payload length.
+ *
+ * Return: The number of bytes successfully transmitted or a negative error
+ * code on failure.*/
+ssize_t mipi_dsi_dsc_pps_write_buffer(struct mipi_dsi_device *dsi,
+ const void *data, size_t len)
+{
+struct mipi_dsi_msg msg = {
+ .channel = dsi->channel,
+ .tx_buf = data,
+ .tx_len = len
+};
+
+ if (len == 0)
+ msg.type = MIPI_DSI_DCS_COMPRESSION_MODE;
+ else
+ msg.type = MIPI_DSI_PPS_LONG_WRITE;
+
+ return mipi_dsi_device_transfer(dsi, &msg);
+}
+EXPORT_SYMBOL(mipi_dsi_dsc_pps_write_buffer);
+
+/**
* mipi_dsi_dcs_write() - send DCS write command
* @dsi: DSI peripheral device
* @cmd: DCS command
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..2aa5120 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -197,7 +197,9 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device
*dsi,
ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
const void *data, size_t len);
ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
- size_t len);
+ size_t len);
+ssize_t mipi_dsi_dsc_pps_write_buffer(struct mipi_dsi_device *dsi,
+ const void *data, size_t len);
int mipi_dsi_dcs_nop(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_soft_reset(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_get_power_mode(struct mipi_dsi_device *dsi, u8 *mode);
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index ddcc8ca..880e6e6 100644
--- a/include/video/mipi_display.h
+++ b/include/video/mipi_display.h
@@ -38,6 +38,9 @@ enum {
MIPI_DSI_DCS_READ = 0x06,
+ MIPI_DSI_DCS_COMPRESSION_MODE = 0x07,
+ MIPI_DSI_PPS_LONG_WRITE = 0x0A,
+
MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
MIPI_DSI_END_OF_TRANSMISSION= 0x08,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/8] drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters for DSC
From: vkorjani
This patch adds code to initialize Picture Parameter set (PPS)
data structure for DSC.
DSC is enabled than the bitrate should be calculated using the
formula pixel_clock * bits_per_pixel / lane_count, where
bits_per_pixel can be 8bpp, 10bpp, 12bpp.
value of bits_per_pixel is available in step of 1/16 in
pps date structure.
DPHY parameters are computed based on data rate calculated
as per bits_per_pixel provided in pps data structure.
Signed-off-by: vkorjani
Signed-off-by: Yogesh Mohan Marimuthu
---
drivers/gpu/drm/i915/intel_dsi.h |5 +
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 11 +++
drivers/gpu/drm/i915/intel_dsi_pll.c | 24
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 24fc550..699f995 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -96,6 +96,11 @@ struct intel_dsi {
u16 panel_on_delay;
u16 panel_off_delay;
u16 panel_pwr_cycle_delay;
+
+ /*DSC Support */
+ u8 dsc_enable;
+ struct vesa_dsc_pps_data pps_data;
+ u8 dsc_bpp;
};
struct intel_dsi_host {
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..f893d37 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -413,6 +413,17 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
*intel_dsi, u16 panel_id)
bits_per_pixel = 18;
else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
bits_per_pixel = 16;
+ else if (intel_dsi->pixel_format == VID_MODE_FORMAT_COMPRESSED &&
+ dev_priv->vbt.dsc_param.dsc_support) {
+ intel_dsi->dsc_enable = true;
+ intel_dsi->dsc_bpp =
+ (intel_dsi->pps_data.bits_per_pixel / 16);
+ bits_per_pixel = intel_dsi->dsc_bpp;
+ intel_dsi->pps_data =
+ dev_priv->vbt.dsc_param.pps_data;
+ /*TODO If PPS not available in VBT compute PPS
+* from capablity parameter set in vbt */
+ }
intel_dsi->operation_mode = mipi_config->is_cmd_mode;
intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index b647f13..38c9433 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -143,10 +143,17 @@ static u32 dsi_rr_formula(const struct drm_display_mode
*mode,
#else
/* Get DSI clock from pixel clock */
-static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
+static u32 dsi_clk_from_pclk(struct intel_encoder *encoder,
+ u32 pclk, int pixel_format, int lane_count)
{
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
u32 dsi_clk_khz;
- u32 bpp = dsi_pixel_format_bpp(pixel_format);
+ u32 bpp;
+
+ if (intel_dsi->dsc_enable)
+ bpp = intel_dsi->dsc_bpp;
+ else
+ bpp = dsi_pixel_format_bpp(pixel_format);
/* DSI data rate = pixel clock * bits per pixel / lane count
pixel clock is converted from KHz to Hz */
@@ -223,8 +230,8 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
struct dsi_mnp dsi_mnp;
u32 dsi_clk;
- dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
- intel_dsi->lane_count);
+ dsi_clk = dsi_clk_from_pclk(encoder, intel_dsi->pclk,
+ intel_dsi->pixel_format, intel_dsi->lane_count);
ret = dsi_calc_mnp(dev_priv, &dsi_mnp, dsi_clk);
if (ret) {
@@ -410,8 +417,9 @@ u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int
pipe_bpp)
dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
- /* pixel_format and pipe_bpp should agree */
- assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
+ /* pixel_format and pipe_bpp should agree if DSC is not enabled */
+ if (!intel_dsi->dsc_enable)
+ assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
pclk = DIV_ROUND_CLOSEST(dsi_clk * intel_dsi->lane_count, pipe_bpp);
@@ -475,8 +483,8 @@ static bool bxt_configure_dsi_pll(struct intel_encoder
*encoder)
u32 dsi_clk;
u32 val;
- dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
- intel_dsi->lane_count);
+ dsi_clk = dsi_clk_from_pclk(encoder, intel_dsi->pclk,
+ intel_dsi->pixel_format, intel_dsi->lane_count);
/*
* From clock diagram, to get PLL ratio divider, divide double of DSI
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.fre
[Intel-gfx] [PATCH] drm/i915: Only dither on 6bpc panels
In
commit d328c9d78d64ca11e744fe227096990430a88477
Author: Daniel Vetter
Date: Fri Apr 10 16:22:37 2015 +0200
drm/i915: Select starting pipe bpp irrespective or the primary plane
we started to select the pipe bpp from sink capabilities and not from
the primary framebuffer - that one might change (and we don't want to
incur a modeset) and sprites might contain higher bpp content too.
Problem is that now if you have a 10bpc screen and display 24bpp rgb
primary then we select dithering, and apparently that mangles the high
8 bits even (even thought you'd expect dithering only to affect how
12bpc gets mapped into 10bpc). And that mangling upsets certain users.
Hence only enable dithering on 6bpc screens where we difinitely and
always want it.
Cc: Mario Kleiner
Reported-by: Mario Kleiner
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a2f229a1c3a..128462e0a0b5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12186,7 +12186,9 @@ encoder_retry:
goto encoder_retry;
}
- pipe_config->dither = pipe_config->pipe_bpp != base_bpp;
+ /* Dithering seems to not pass-through bits correctly when it should, so
+* only enable it on 6bpc panels. */
+ pipe_config->dither = pipe_config->pipe_bpp == 6*3;
DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: WaBindlessSurfaceStateModifyEnable
On 11/08/2015 13:25, Mika Kuoppala wrote:
Don't set the size of bindless surface state on rendercopy.
And as of doing so, take into account the workaround for setting
the command size.
This was tried during hunting for
https://bugs.freedesktop.org/show_bug.cgi?id=89959. But no
impact was found.
Cc: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
lib/rendercopy_gen9.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
index 0766192..4a4a604 100644
--- a/lib/rendercopy_gen9.c
+++ b/lib/rendercopy_gen9.c
@@ -511,7 +511,11 @@ gen7_emit_push_constants(struct intel_batchbuffer *batch) {
static void
gen9_emit_state_base_address(struct intel_batchbuffer *batch) {
- OUT_BATCH(GEN6_STATE_BASE_ADDRESS | (19 - 2));
+
+ /* WaBindlessSurfaceStateModifyEnable:skl,bxt */
+ /* The length has to be one less if we dont modify
+ bindless state */
+ OUT_BATCH(GEN6_STATE_BASE_ADDRESS | (19 - 1 - 2));
/* general */
OUT_BATCH(0 | BASE_ADDRESS_MODIFY);
@@ -544,9 +548,9 @@ gen9_emit_state_base_address(struct intel_batchbuffer
*batch) {
OUT_BATCH(1 << 12 | 1);
/* Bindless surface state base address */
- OUT_BATCH(0 | BASE_ADDRESS_MODIFY);
OUT_BATCH(0);
- OUT_BATCH(0xf000);
+ OUT_BATCH(0);
+ OUT_BATCH(0);
}
static void
Agrees with spec and looks good to me. No impact observed with
gem_concurrent_blit subtests.
Reviewed-by: Arun Siluvery
regards
Arun
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
Some more fixup is needed; the bits from Antti's patch
that actually expanded the struct to fully fit the newer
versions of the child_device_config was part of the second
patch; since that patch hasn't been merged yet we need this bit:
This applies on top of the patch you already merged
(the Iboost patch will need corresponding adjustment to
remove the changes I split out):
Expand common_child_dev_config to be able to fit all information
defined by the latest VBT specification.
Signed-off-by: David Weinehall
CC: Antti Koskipaa
---
intel_bios.c |7 ++-
intel_bios.h |4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 990acc20771a..40e2cc4e7419 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
DRM_DEBUG_KMS("No general definition block is found, no devices
defined.\n");
return;
}
+ /* Remember to keep this in sync with child_device_config;
+* whenever a new feature is added to BDB that causes that
+* struct to grow this needs to be updated too
+*/
if (bdb->version < 195) {
expected_size = 33;
} else if (bdb->version == 195) {
@@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
}
if (expected_size > sizeof(*p_child)) {
- DRM_ERROR("child_device_config cannot fit in p_child\n");
+ DRM_ERROR("child_device_config (size %u) cannot fit in p_child
(size %u); bdb->version: %u\n",
+ expected_size, sizeof(*p_child), bdb->version);
return;
}
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index f7ad6a585129..71cb96f77870 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -239,6 +239,10 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
+ u8 obsolete;
+ u8 flags_1;
+ u8 not_common3[13];
+ u8 iboost_level;
} __packed;
/* This field changes depending on the BDB version, so the most reliable way to
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E
> On Tue, 2015-08-11 at 11:47 +0200, Daniel Vetter wrote:
> > On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
> > > From: Rodrigo Vivi
> > >
> > > On Skylake we have eDP-to-VGA using DDI-E and another aux.
> > > So let's identify it properly.
> >
> > eDP means panel (the only difference in the code we have between eDP
> > and DP is the power panel sequncing). VGA very much means no panel.
> >
> > Is this some impressive hack (dp->vga dongle using panel power as it's
> > power source) or what's going on here? Or just confused commit
> > message?
>
> That's a good question. I've heard from customer the embedded converter is
> eDP-to-VGA, not DP-to-VGA so I'm not sure what is behind and I have no
> machine here with me.
[Xiong, Zhang]: From vbt, it is a DP-to-VGA, not eDP-to-VGA
[ 103.407648] [drm:parse_ddi_port] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0
CRT:0
>
> Xiong, could you please check with customer if everything works without this
> patch?
[Xiong, Zhang]: Everything works well without this patch on customer's machine.
But if a eDP indeed connect to DDI-E without this patch,
intel_dp_is_edp(PORT_E) will return false, then eDP on DDI-E couldn't work.
>
> Thanks,
> Rodrigo.
>
> > I'll punt on this for now.
> > -Daniel
> >
> > >
> > > Also let's remove duplicated definitions to avoid later confusion.
> > >
> > > Signed-off-by: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/intel_bios.h | 5 -
> > > drivers/gpu/drm/i915/intel_dp.c | 9 +
> > > 2 files changed, 5 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > > b/drivers/gpu/drm/i915/intel_bios.h
> > > index 02255d8..a2ef0df 100644
> > > --- a/drivers/gpu/drm/i915/intel_bios.h
> > > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > > @@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device *dev);
> > > #define DVO_C 2
> > > #define DVO_D 3
> > >
> > > -/* define the PORT for DP output type */
> > > -#define PORT_IDPB 7
> > > -#define PORT_IDPC 8
> > > -#define PORT_IDPD 9
> > > -
> > > /* Possible values for the "DVO Port" field for versions >= 155:
> > > */
> > > #define DVO_PORT_HDMIA 0
> > > #define DVO_PORT_HDMIB 1
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c index 7cd47bc..0643a91 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct drm_crtc
> > > *crtc)
> > > return -1;
> > > }
> > >
> > > -/* check the VBT to see whether the eDP is on DP-D port */
> > > +/* check the VBT to see whether the eDP is on another port */
> > > bool intel_dp_is_edp(struct drm_device *dev, enum port port) {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > union child_device_config *p_child;
> > > int i;
> > > static const short port_mapping[] = {
> > > - [PORT_B] = PORT_IDPB,
> > > - [PORT_C] = PORT_IDPC,
> > > - [PORT_D] = PORT_IDPD,
> > > + [PORT_B] = DVO_PORT_DPB,
> > > + [PORT_C] = DVO_PORT_DPC,
> > > + [PORT_D] = DVO_PORT_DPD,
> > > + [PORT_E] = DVO_PORT_DPE,
> > > };
> > >
> > > if (port == PORT_A)
> > > --
> > > 2.1.4
> > >
> > > ___
> > > 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
[Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
v3: WARN() take place of BUG()
Signed-off-by: Xiong Zhang
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/intel_bios.c | 25 +
drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
3 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6d93334..5d8e7fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1414,6 +1414,10 @@ enum modeset_restore {
#define DP_AUX_C 0x20
#define DP_AUX_D 0x30
+#define DDC_PIN_B 0x05
+#define DDC_PIN_C 0x04
+#define DDC_PIN_D 0x06
+
struct ddi_vbt_port_info {
/*
* This is an index in the HDMI/DVI DDI buffer translation table.
@@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
uint8_t supports_dp:1;
uint8_t alternate_aux_channel;
+ uint8_t alternate_ddc_pin;
};
enum psr_lines_to_wait {
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 16cdf17..8140531 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
uint8_t hdmi_level_shift;
int i, j;
bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
- uint8_t aux_channel;
+ uint8_t aux_channel, ddc_pin;
/* Each DDI port can have more than one value on the "DVO Port" field,
* so look for all the possible values for each port and abort if more
* than one is found. */
@@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
return;
aux_channel = child->raw[25];
+ ddc_pin = child->common.ddc_pin;
is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
is_dp = child->common.device_type & DEVICE_TYPE_DISPLAYPORT_OUTPUT;
@@ -959,11 +960,27 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
if (is_dvi) {
- if (child->common.ddc_pin == 0x05 && port != PORT_B)
+ if (port == PORT_E) {
+ info->alternate_ddc_pin = ddc_pin;
+ /* if DDIE share ddc pin with other port, then
+* dvi/hdmi couldn't exist on the shared port.
+* Otherwise they share the same ddc bin and system
+* couldn't communicate with them seperately. */
+ if (ddc_pin == DDC_PIN_B) {
+
dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
+ } else if (ddc_pin == DDC_PIN_C) {
+
dev_priv->vbt.ddi_port_info[PORT_C].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
+ } else if (ddc_pin == DDC_PIN_D) {
+
dev_priv->vbt.ddi_port_info[PORT_D].supports_dvi = 0;
+
dev_priv->vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
+ }
+ } else if (ddc_pin == DDC_PIN_B && port != PORT_B)
DRM_DEBUG_KMS("Unexpected DDC pin for port B\n");
- if (child->common.ddc_pin == 0x04 && port != PORT_C)
+ else if (ddc_pin == DDC_PIN_C && port != PORT_C)
DRM_DEBUG_KMS("Unexpected DDC pin for port C\n");
- if (child->common.ddc_pin == 0x06 && port != PORT_D)
+ else if (ddc_pin == DDC_PIN_D && port != PORT_D)
DRM_DEBUG_KMS("Unexpected DDC pin for port D\n");
}
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..a4129f2 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1991,6 +1991,24 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_hdmi->ddc_bus = GMBUS_PIN_DPD;
intel_encoder->hpd_pin = HPD_PORT_D;
break;
+ case PORT_E:
+ /* On SKL PORT E doesn't have seperate GMBUS pin
+* We rely on VBT to set a proper alternate GMBUS pin. */
+ switch (dev_priv->vbt.ddi_port_info[PORT_E].alternate_ddc_pin) {
+ case DDC_PIN_B:
+ intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
+ break;
+ case
[Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
From Gen9, by default push constant command is not committed to the shader unit
untill the corresponding shader's BTP_* command is parsed. This is the
behaviour when set shader is enabled. This patch updates the batch to follow
this requirement otherwise it results in gpu hang.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
Set shader need to be disabled if legacy behaviour is required.
Cc: Ben Widawsky
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
---
If this patch is applied then we don't need to disable set shader bit
in kernel and the following can be discarded.
http://lists.freedesktop.org/archives/intel-gfx/2015-August/073425.html
lib/rendercopy_gen9.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
index 4a4a604..9537480 100644
--- a/lib/rendercopy_gen9.c
+++ b/lib/rendercopy_gen9.c
@@ -590,13 +590,9 @@ gen8_emit_multisample(struct intel_batchbuffer *batch) {
static void
gen8_emit_vs(struct intel_batchbuffer *batch) {
- OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
+ OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
OUT_BATCH(0);
-
- OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
OUT_BATCH(0);
-
- OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
@@ -605,7 +601,11 @@ gen8_emit_vs(struct intel_batchbuffer *batch) {
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
+
+ OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
OUT_BATCH(0);
+
+ OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
OUT_BATCH(0);
OUT_BATCH(GEN6_3DSTATE_VS | (9-2));
@@ -998,14 +998,14 @@ void gen9_render_copyfunc(struct intel_batchbuffer *batch,
gen8_emit_sf(batch);
+ gen8_emit_ps(batch, ps_kernel_off);
+
OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_PS);
OUT_BATCH(ps_binding_table);
OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_PS);
OUT_BATCH(ps_sampler_state);
- gen8_emit_ps(batch, ps_kernel_off);
-
OUT_BATCH(GEN6_3DSTATE_SCISSOR_STATE_POINTERS);
OUT_BATCH(scissor_state);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation programming.
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7079 -Summary- Platform Delta drm-intel-nightly Series Applied ILK -1 302/302 301/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT 283/283 283/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@kms_flip@rcs-wf_vblank-vs-dpms-interruptible PASS(1) DMESG_WARN(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/22 RESEND] drm/i915: On fb alloc failure, unref gem object where it gets refed
Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call chain in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_lookup).
This invites mistakes: As discovered by Tvrtko Ursulin, a double unref
has sneaked into intelfb_alloc (which calls __intel_framebuffer_create).
As suggested by Ville Syrjälä, improve code clarity by moving the unref
away from __intel_framebuffer_create to where the gem object gets refed.
[Changelog is in preceding patch by Tvrtko Ursulin.]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Signed-off-by: Lukas Wunner
Fixes: a8bb6818270c ("drm/i915: Fix error path leak in fbdev fb
allocation")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 907b73e..5984d5f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10145,20 +10145,17 @@ __intel_framebuffer_create(struct drm_device *dev,
int ret;
intel_fb = kzalloc(sizeof(*intel_fb), GFP_KERNEL);
- if (!intel_fb) {
- drm_gem_object_unreference(&obj->base);
+ if (!intel_fb)
return ERR_PTR(-ENOMEM);
- }
ret = intel_framebuffer_init(dev, intel_fb, mode_cmd, obj);
if (ret)
goto err;
return &intel_fb->base;
+
err:
- drm_gem_object_unreference(&obj->base);
kfree(intel_fb);
-
return ERR_PTR(ret);
}
@@ -10198,6 +10195,7 @@ intel_framebuffer_create_for_mode(struct drm_device
*dev,
struct drm_display_mode *mode,
int depth, int bpp)
{
+ struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
@@ -10212,7 +10210,11 @@ intel_framebuffer_create_for_mode(struct drm_device
*dev,
bpp);
mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
- return intel_framebuffer_create(dev, &mode_cmd, obj);
+ fb = intel_framebuffer_create(dev, &mode_cmd, obj);
+ if (IS_ERR(fb))
+ drm_gem_object_unreference_unlocked(&obj->base);
+
+ return fb;
}
static struct drm_framebuffer *
@@ -14468,6 +14470,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
struct drm_file *filp,
struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
obj = to_intel_bo(drm_gem_object_lookup(dev, filp,
@@ -14475,7 +14478,11 @@ intel_user_framebuffer_create(struct drm_device *dev,
if (&obj->base == NULL)
return ERR_PTR(-ENOENT);
- return intel_framebuffer_create(dev, mode_cmd, obj);
+ fb = intel_framebuffer_create(dev, mode_cmd, obj);
+ if (IS_ERR(fb))
+ drm_gem_object_unreference_unlocked(&obj->base);
+
+ return fb;
}
static void intel_output_poll_changed(struct drm_device *dev)
--
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:
> From: "Thulasimani,Sivakumar"
>
> This reverts
> commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
> Author: Ville Syrjälä
> Date: Thu Mar 12 17:10:38 2015 +0200
>
> CHV does not support intermediate frequencies so reverting the
> patch that added it in the first place
My docs still say it does. Is there some undocumented problem with the
PLL or is this just a marketing decision?
>
> Signed-off-by: Sivakumar Thulasimani
> ---
> drivers/gpu/drm/i915/intel_dp.c |6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..d9fb7a8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
> 27,
> 324000, 432000, 54 };
> static const int skl_rates[] = { 162000, 216000, 27,
> 324000, 432000, 54 };
> -static const int chv_rates[] = { 162000, 202500, 21, 216000,
> - 243000, 27, 324000, 405000,
> - 42, 432000, 54 };
> static const int default_rates[] = { 162000, 27, 54 };
>
> /**
> @@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int
> **source_rates)
> } else if (IS_SKYLAKE(dev)) {
> *source_rates = skl_rates;
> return ARRAY_SIZE(skl_rates);
> - } else if (IS_CHERRYVIEW(dev)) {
> - *source_rates = chv_rates;
> - return ARRAY_SIZE(chv_rates);
> }
>
> *source_rates = default_rates;
> --
> 1.7.9.5
--
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 v2 00/22] Enable gpu switching on the MacBook Pro
This is a follow-up to the v1 posted in April: http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro. These were tested successfully by multiple people and solve two tickets in Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 https://bugs.freedesktop.org/show_bug.cgi?id=61115 Patches 18 - 22 are a preview of how we're tackling retina support. Those are marked experimental and are NOT ready to be merged yet. Feedback on them is welcome. The patches are based on drm-next. They were tested on the following hardware (thanks a lot everyone!): Tested-by: Paul Hordiienko [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] What's new: * By default the MBP boots with the display switched to the discrete GPU but it can be forced to the integrated GPU with an EFI boot variable. Here's a handy tool for that: https://github.com/0xbb/gpu-switch v1 didn't work in this configuration, v2 does. * Reprobing if the inactive GPU initializes before the apple-gmux module: v1 used Matthew Garrett's approach of adding a driver callback. v2 simply generates a hotplug event instead. nouveau polls its outputs every 10 seconds so we want it to poll immediately once apple-gmux registers. That is achieved by the hotplug event. The i915 driver is changed to behave identically to nouveau. (Right now it deletes LVDS and eDP connectors from the mode configuration if they can't be probed, deeming them to be ghosts.) * Framebuffer recreation if the inactive GPU initializes before the apple-gmux module (i.e. discarding the default 1024x768 fb and replacing with a new one with the actual panel resolution): v1 only supported this for i915, v2 has a generic solution which works with nouveau and radeon as well. (Necessary if the discrete GPU is forced to be the inactive one on boot via the EFI variable.) * Generally lots of rough edges were smoothed to hopefully make the patches more suitable for merging. E.g. there's a bug in i915 where the SSC status set by BIOS is preserved too late and v1 only contained a workaround, whereas v2 contains a proper fix in a separate commit. The long journey towards retina support: The pixel clock required for retina resolution is not supported by LVDS (which was used on pre-retinas), necessitating eDP instead. Problem is, the gmux register which switches the DDC lines on pre-retinas doesn't switch the AUX channel on retinas. Disassembling the OS X driver revealed that the gmux in retina MBPs gained an additional register 0x7f which gets written to when setting up the eDP configuration. There was some hope that this might switch the AUX channel. Alas, we tried writing various values to that register but were unable to get the inactive GPU to talk to the panel. The purpose of register 0x7f remains a mystery. Teardowns of the first generation retina MBP name the NXP CBTL06142 and TI HD3SS212 as multiplexers and according to the data sheets I've found, neither supports switching the AUX channel separately from the main link. Matthew Garrett had the idea of having the active GPU stash the EDID and the first 8 bytes of the DPCD (receiver capabilities) and letting the inactive GPU retrieve that data. I rebased and rewrote his patches and got everything working, only to discover that the drivers are unhappy with just 8 bytes of DPCD. They need full access to the DPCD to set up their outputs. We could stash the entire DPCD but some parts of it are mutable so the stashed data may become stale when the active GPU performs writes to the DPCD. So I had the idea of using the active GPU as a proxy to talk to the panel, thus emulating switching of the AUX channel in software. We can leverage the struct drm_dp_aux and i2c_adapter (for DDC) to achieve this, swapping the inactive GPU's structs with those of the active GPU on the fly. That approach is implemented in patches 18 - 22 but there are still some driver issues that I'm debugging. The current status as per the latest logs Bruno sent me is that i915 rejects the mode retrieved via proxying with CLOCK_HIGH and nouveau aborts link training halfway through. Bottom line is that it's not yet working but we're getting closer. As a side effect, the pre-retinas gain a second way to initialize their outputs: They can either use gmux to switch the DDC lines, or use the active GPU as a proxy for the DDC communication. Which method gets used depends on the order in which the drivers initialize, the inactive GPU will happily use whatever is available and it automatically receives a hotplug event once either method becomes ready for use. But, once again, the patches imple
[Intel-gfx] [PATCH v2 14/22 RESEND] drm/i915: Fix failure paths around initial fbdev allocation
From: Tvrtko Ursulin
We had two failure modes here:
1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.
2.
Deadlock in intelfb_create failure path where it calls
drm_framebuffer_unreference, which grabs the struct mutex and
intelfb_create was already holding it.
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v3:
* On fb alloc failure, unref gem object where it gets refed,
fix double unref in separate commit. (Ville Syrjälä)
v4:
* Lock struct mutex on unref. (Chris Wilson)
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Signed-off-by: Tvrtko Ursulin
Fixes: 60a5ca015ffd ("drm/i915: Add locking around
framebuffer_references--")
Reported-by: Lukas Wunner
[Lukas: Create v3 + v4 based on Tvrtko's v2]
Signed-off-by: Lukas Wunner
Cc: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fbdev.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 7eff33f..dd138aa 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -140,7 +140,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
{
struct intel_fbdev *ifbdev =
container_of(helper, struct intel_fbdev, helper);
- struct drm_framebuffer *fb;
+ struct drm_framebuffer *fb = NULL;
struct drm_device *dev = helper->dev;
struct drm_mode_fb_cmd2 mode_cmd = {};
struct drm_i915_gem_object *obj;
@@ -158,6 +158,8 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
+ mutex_lock(&dev->struct_mutex);
+
size = mode_cmd.pitches[0] * mode_cmd.height;
size = PAGE_ALIGN(size);
obj = i915_gem_object_create_stolen(dev, size);
@@ -179,18 +181,21 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
ret = intel_pin_and_fence_fb_obj(NULL, fb, NULL, NULL, NULL);
if (ret) {
DRM_ERROR("failed to pin obj: %d\n", ret);
- goto out_fb;
+ goto out_unref;
}
+ mutex_unlock(&dev->struct_mutex);
+
ifbdev->fb = to_intel_framebuffer(fb);
return 0;
-out_fb:
- drm_framebuffer_remove(fb);
out_unref:
drm_gem_object_unreference(&obj->base);
out:
+ mutex_unlock(&dev->struct_mutex);
+ if (fb)
+ drm_framebuffer_remove(fb);
return ret;
}
@@ -208,8 +213,6 @@ static int intelfb_create(struct drm_fb_helper *helper,
int size, ret;
bool prealloc = false;
- mutex_lock(&dev->struct_mutex);
-
if (intel_fb &&
(sizes->fb_width > intel_fb->base.width ||
sizes->fb_height > intel_fb->base.height)) {
@@ -224,7 +227,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
DRM_DEBUG_KMS("no BIOS fb, allocating a new one\n");
ret = intelfb_alloc(helper, sizes);
if (ret)
- goto out_unlock;
+ return ret;
intel_fb = ifbdev->fb;
} else {
DRM_DEBUG_KMS("re-using BIOS fb\n");
@@ -236,6 +239,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
obj = intel_fb->obj;
size = obj->base.size;
+ mutex_lock(&dev->struct_mutex);
+
info = framebuffer_alloc(0, &dev->pdev->dev);
if (!info) {
ret = -ENOMEM;
@@ -306,7 +311,6 @@ static int intelfb_create(struct drm_fb_helper *helper,
out_unpin:
i915_gem_object_ggtt_unpin(obj);
drm_gem_object_unreference(&obj->base);
-out_unlock:
mutex_unlock(&dev->struct_mutex);
return ret;
}
--
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/22] drm/i915: Reprobe eDP and LVDS connectors on hotplug event
The i915 driver probes eDP and LVDS connectors once on startup by
invoking intel_setup_outputs(). If no DPCD or EDID can be obtained,
it will remove the connectors from the device's mode configuration,
presuming they're ghost connectors. As a result, subsequent calls to
drm_fb_helper_hotplug_event() won't be able to pick up changes on
these connectors.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy the DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, eDP and
LVDS connectors which may seem disconnected at startup may later turn
out to be connected.
By contrast, nouveau will keep eDP and LVDS connectors for which no
modes were found in the device's mode configuration and thus is able
to reprobe these connectors in drm_fb_helper_hotplug_event().
Assimilate to nouveau's behaviour: Keep modeless eDP and LVDS connectors
in the mode configuration and change the ->output_poll_changed callback
to reprobe them on hotplug events.
In the case of LVDS, split intel_lvds_init() in half: The first portion
is executed once on startup. This consists of detecting, setting up and
registering the connector. The second portion is executed both on
startup and on every reprobe. This consists of reading the panel's EDID,
determining if dual channel LVDS is used, and initializing the reference
clock.
In the case of eDP, reprobe involves calling intel_edp_init_connector()
and initializing the reference clock.
Based (loosely) on a patch by Matthew Garrett who
duplicated intel_setup_outputs() and reduced it to just the eDP probing
portion (which is not sufficient since pre-retina MBPs used LVDS):
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0024-i915-Add-support-for-reprobing-for-a-panel.patch
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_display.c | 41 ++
drivers/gpu/drm/i915/intel_dp.c | 38
drivers/gpu/drm/i915/intel_drv.h | 6
drivers/gpu/drm/i915/intel_lvds.c| 67 +---
drivers/gpu/drm/i915/intel_panel.c | 4 +--
5 files changed, 112 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6335883..907b73e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8223,11 +8223,11 @@ static void ironlake_init_pch_refclk(struct drm_device
*dev)
for_each_intel_encoder(dev, encoder) {
switch (encoder->type) {
case INTEL_OUTPUT_LVDS:
- has_panel = true;
+ has_panel = intel_lvds_has_panel(encoder);
has_lvds = true;
break;
case INTEL_OUTPUT_EDP:
- has_panel = true;
+ has_panel = intel_edp_has_panel(encoder);
if (enc_to_dig_port(&encoder->base)->port == PORT_A)
has_cpu_edp = true;
break;
@@ -14478,15 +14478,44 @@ intel_user_framebuffer_create(struct drm_device *dev,
return intel_framebuffer_create(dev, mode_cmd, obj);
}
-#ifndef CONFIG_DRM_I915_FBDEV
-static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
+static void intel_output_poll_changed(struct drm_device *dev)
{
-}
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_connector *intel_connector;
+
+ /* Reprobe LVDS and eDP as long as no EDID was retrieved from panel */
+ for_each_intel_connector(dev, intel_connector) {
+ struct drm_connector *connector = &intel_connector->base;
+
+ if ((connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
+connector->connector_type != DRM_MODE_CONNECTOR_eDP) ||
+ !IS_ERR_OR_NULL(intel_connector->edid))
+ continue;
+
+ if ((connector->connector_type == DRM_MODE_CONNECTOR_LVDS &&
+!intel_lvds_probe_modes(connector)) ||
+ (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
+!intel_edp_init_connector(
+ enc_to_intel_dp(&intel_connector->encoder->base),
+ intel_connector)))
+ continue;
+
+ intel_init_
[Intel-gfx] [PATCH v2 12/22] drm/i915: Preserve SSC earlier
Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.
However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.
Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.
Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).
Fix this by moving the code introduced by 92122789b2d6 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.
Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/04.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_display.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af0bcfe..6335883 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14893,6 +14893,24 @@ void intel_modeset_init(struct drm_device *dev)
if (INTEL_INFO(dev)->num_pipes == 0)
return;
+ /*
+* There may be no VBT; and if the BIOS enabled SSC we can
+* just keep using it to avoid unnecessary flicker. Whereas if the
+* BIOS isn't using it, don't assume it will work even if the VBT
+* indicates as much.
+*/
+ if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
+ bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
+ DREF_SSC1_ENABLE);
+
+ if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
+ DRM_DEBUG_KMS("SSC %sabled by BIOS, overriding VBT
which says %sabled\n",
+bios_lvds_use_ssc ? "en" : "dis",
+dev_priv->vbt.lvds_use_ssc ? "en" : "dis");
+ dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
+ }
+ }
+
intel_init_display(dev);
intel_init_audio(dev);
@@ -15446,7 +15464,6 @@ err:
void intel_modeset_gem_init(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc *c;
struct drm_i915_gem_object *obj;
int ret;
@@ -15455,16 +15472,6 @@ void intel_modeset_gem_init(struct drm_device *dev)
intel_init_gt_powersave(dev);
mutex_unlock(&dev->struct_mutex);
- /*
-* There may be no VBT; and if the BIOS enabled SSC we can
-* just keep using it to avoid unnecessary flicker. Whereas if the
-* BIOS isn't using it, don't assume it will work even if the VBT
-* indicates as much.
-*/
- if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
- dev_priv->vbt.lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
- DREF_SSC1_ENABLE);
-
intel_modeset_init_hw(dev);
intel_setup_overlay(dev);
--
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series
On Tue, Aug 11, 2015 at 11:41:42AM +0200, Daniel Vetter wrote: > On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote: > > > > > > On 8/10/2015 1:38 PM, Daniel Vetter wrote: > > >On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote: > > >>Hi Daniel, > > >> > > >>That patch was already merged: > > >>http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html > > >> > > >>For SKL, the above patch helped in getting the correct ISR bits set. > > >>One option is to enable the HDMI optimization from VLV onwards. > > >>I don't have an ivb machine to try out the issue. > > > > > >ivb is simple the machine I have here, but when we tried this the last > > >time around we had reports for all platforms (your patch still doesn't > > >cite the relevant sha1 btw). I think there are 3 possible explanations: > > > > > Yes, I don't know which were those patches and how to find them.. > > git blame (recursively) and git log on intel_hdmi.c will tell you the > story. I require all these extensive git commit messages because I dig > them out daily. Also git log --pickaxe (well I use the equivalent in the > gitk gui). If these tools are generally unknown in the vpg display team > then we absolutely need to do a training session about them, they're > extremely powerful and useful to dig out the history of the i915 code. git blame I use a lot to find whom to ask for clarification. pickaxe, however, was new to me. Thanks for the tip, will look into it. As far as training sessions about git goes, I think a lot of people could benefit from it; git has a LOT of hidden gems, and it seems almost everyone has different workflows. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On 8/12/2015 5:02 PM, Ville Syrjälä wrote:
On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:
From: "Thulasimani,Sivakumar"
This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä
Date: Thu Mar 12 17:10:38 2015 +0200
CHV does not support intermediate frequencies so reverting the
patch that added it in the first place
My docs still say it does. Is there some undocumented problem with the
PLL or is this just a marketing decision?
I don't think so, i too have just one document that shows the phy values
for each of
the link rates but have not found any where else to say it is supported .
Also this is not tested by anyone including us from product team so i
highly doubt
it will even work.
regarding HBR2, it was supposed to land on a future stepping that never
happened
so it is not supported at all.
Signed-off-by: Sivakumar Thulasimani
---
drivers/gpu/drm/i915/intel_dp.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..d9fb7a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
27,
324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
static const int default_rates[] = { 162000, 27, 54 };
/**
@@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
- } else if (IS_CHERRYVIEW(dev)) {
- *source_rates = chv_rates;
- return ARRAY_SIZE(chv_rates);
}
*source_rates = default_rates;
--
1.7.9.5
--
regards,
Sivakumar
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands
On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote:
> From Gen9, by default push constant command is not committed to the
> shader unit
> untill the corresponding shader's BTP_* command is parsed. This is
> the
> behaviour when set shader is enabled. This patch updates the batch to
> follow
> this requirement otherwise it results in gpu hang.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
>
> Set shader need to be disabled if legacy behaviour is required.
>
> Cc: Ben Widawsky
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Signed-off-by: Arun Siluvery
Reviewed-by: Joonas Lahtinen
> ---
>
> If this patch is applied then we don't need to disable set shader bit
> in kernel and the following can be discarded.
>
> http://lists.freedesktop.org/archives/intel-gfx/2015-August/073425.ht
> ml
>
> lib/rendercopy_gen9.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
> index 4a4a604..9537480 100644
> --- a/lib/rendercopy_gen9.c
> +++ b/lib/rendercopy_gen9.c
> @@ -590,13 +590,9 @@ gen8_emit_multisample(struct intel_batchbuffer
> *batch) {
>
> static void
> gen8_emit_vs(struct intel_batchbuffer *batch) {
> - OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
> + OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
> OUT_BATCH(0);
> -
> - OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
> OUT_BATCH(0);
> -
> - OUT_BATCH(GEN6_3DSTATE_CONSTANT_VS | (11-2));
> OUT_BATCH(0);
> OUT_BATCH(0);
> OUT_BATCH(0);
> @@ -605,7 +601,11 @@ gen8_emit_vs(struct intel_batchbuffer *batch) {
> OUT_BATCH(0);
> OUT_BATCH(0);
> OUT_BATCH(0);
> +
> + OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_VS);
> OUT_BATCH(0);
> +
> + OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_VS);
> OUT_BATCH(0);
>
> OUT_BATCH(GEN6_3DSTATE_VS | (9-2));
> @@ -998,14 +998,14 @@ void gen9_render_copyfunc(struct
> intel_batchbuffer *batch,
>
> gen8_emit_sf(batch);
>
> + gen8_emit_ps(batch, ps_kernel_off);
> +
> OUT_BATCH(GEN7_3DSTATE_BINDING_TABLE_POINTERS_PS);
> OUT_BATCH(ps_binding_table);
>
> OUT_BATCH(GEN7_3DSTATE_SAMPLER_STATE_POINTERS_PS);
> OUT_BATCH(ps_sampler_state);
>
> - gen8_emit_ps(batch, ps_kernel_off);
> -
> OUT_BATCH(GEN6_3DSTATE_SCISSOR_STATE_POINTERS);
> OUT_BATCH(scissor_state);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, 12 Aug 2015, David Weinehall wrote:
> Some more fixup is needed; the bits from Antti's patch
> that actually expanded the struct to fully fit the newer
> versions of the child_device_config was part of the second
> patch; since that patch hasn't been merged yet we need this bit:
>
> This applies on top of the patch you already merged
> (the Iboost patch will need corresponding adjustment to
> remove the changes I split out):
>
> Expand common_child_dev_config to be able to fit all information
> defined by the latest VBT specification.
>
> Signed-off-by: David Weinehall
> CC: Antti Koskipaa
> ---
> intel_bios.c |7 ++-
> intel_bios.h |4
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 990acc20771a..40e2cc4e7419 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> DRM_DEBUG_KMS("No general definition block is found, no devices
> defined.\n");
> return;
> }
> + /* Remember to keep this in sync with child_device_config;
> + * whenever a new feature is added to BDB that causes that
> + * struct to grow this needs to be updated too
> + */
BUILD_BUG_ON(something about sizeof child device config) ?
> if (bdb->version < 195) {
> expected_size = 33;
> } else if (bdb->version == 195) {
> @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> }
>
> if (expected_size > sizeof(*p_child)) {
> - DRM_ERROR("child_device_config cannot fit in p_child\n");
> + DRM_ERROR("child_device_config (size %u) cannot fit in p_child
> (size %u); bdb->version: %u\n",
> + expected_size, sizeof(*p_child), bdb->version);
> return;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a585129..71cb96f77870 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -239,6 +239,10 @@ struct common_child_dev_config {
> u8 not_common2[2];
> u8 ddc_pin;
> u16 edid_ptr;
> + u8 obsolete;
> + u8 flags_1;
> + u8 not_common3[13];
> + u8 iboost_level;
> } __packed;
>
> /* This field changes depending on the BDB version, so the most reliable way
> to
> ___
> 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
[Intel-gfx] [PATCH] drm/i915: Do not check or a stalled pageflip prior to it being queued
When we queue the command or operation to change the scanout address, we mark the flip as in progress. We can use this flag to prevent us from checking for a stalled flip prior to its existence! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index aab8dfd1f8a5..edc7d4a7c9de 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11248,6 +11248,9 @@ static bool __intel_pageflip_stall_check(struct drm_device *dev, if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) return true; + if (atomic_read(&work->pending) < INTEL_FLIP_PENDING) + return false; + if (!work->enable_stall_check) return false; -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 0/2] Enable legacy behaviour for Push constants
On 11/08/2015 21:58, Timo Aaltonen wrote: On 11.08.2015 17:44, Arun Siluvery wrote: Patch1 fixes a simple compile error in Patch2 Patch2 fixes gpu hang observed with a subtest of gem_concurrent_blit. Arun Siluvery (1): drm/i915/gen9: Disable gather at set shader bit Mika Kuoppala (1): drm/i915: Contain the WA_REG macro drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_ringbuffer.c | 14 -- 2 files changed, 17 insertions(+), 2 deletions(-) prw-blt-overwrite-source-read-rcs-forked runs fine with these, tested on SKL-Y & -H Tested-by: Timo Aaltonen This patch can be ignored if the following patch is applied, [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands http://lists.freedesktop.org/archives/intel-gfx/2015-August/073483.html regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series
On Tue, Aug 11, 2015 at 11:03:54AM +, Sharma, Shashank wrote: > HI Daniel, > > Looks like we are not getting an IVB machine here. I think instead of > blocking the patch set for the whole series, we can just block it for the > platforms we don’t get success for. > We are shipping many VLV/CHV systems with these patches applied, and they are > passing all Android test suits and test benches, so we don’t doubt the > solution as such. > > We have done testing for following platforms (gen 9 is tested by Imre also): > 1. CHV / BSW > 2. SKL > 3. BXT > 4. BDW I know that it works on piles of other platforms too. The problem is figuring out why it doesn't work on some and what we're doing wrong. > Why don’t we go ahead with this solution for gen 8 onwards, and keep the > rest of the code un touched, this will serve both the purpose. I guess we can, but if we get a regression report on bdw because of this I'll be furious. -Daniel > > Regards > Shashank > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Daniel Vetter > Sent: Tuesday, August 11, 2015 3:12 PM > To: Jindal, Sonika > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series > > On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote: > > > > > > On 8/10/2015 1:38 PM, Daniel Vetter wrote: > > >On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote: > > >>Hi Daniel, > > >> > > >>That patch was already merged: > > >>http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.htm > > >>l > > >> > > >>For SKL, the above patch helped in getting the correct ISR bits set. > > >>One option is to enable the HDMI optimization from VLV onwards. > > >>I don't have an ivb machine to try out the issue. > > > > > >ivb is simple the machine I have here, but when we tried this the > > >last time around we had reports for all platforms (your patch still > > >doesn't cite the relevant sha1 btw). I think there are 3 possible > > >explanations: > > > > > Yes, I don't know which were those patches and how to find them.. > > git blame (recursively) and git log on intel_hdmi.c will tell you the story. > I require all these extensive git commit messages because I dig them out > daily. Also git log --pickaxe (well I use the equivalent in the gitk gui). If > these tools are generally unknown in the vpg display team then we absolutely > need to do a training session about them, they're extremely powerful and > useful to dig out the history of the i915 code. > > > >a) we do something wrong with hpd handling on these platforms. That > > >seems to be the explanation you favour (with the gen >= 7 checks and > > >all that), but I think it's very unlikely: On each platform where we > > >had reports of hpd being broken there was also machines where hpd works > > >perfectly fine. > > > > > Not sure, I will find one ivb system and try on that. > > > > >b) There's broken HDMI (or DVI) sinks out there. If that's the case > > >we can never merge your patch. > > I doubt this because we have tested these patches with many sinks in > > the past with VLV/CHV. > > > > > >c) There's something in vbt or somewhere else that tells the windows > > >driver whether using hpd or not is ok (and the hpd problem is > > >actually an issue with certain OEM machines ...). > > > > > No, nothing like that. > > > > >I hoped that with your hpd handling fix we'd have some indication > > >that our hpd troubles are of type a). But since I tested with your > > >patch that didn't work out. > > > > > >And until we have some evidence that our hpd troubles aren't type b) > > >I really don't want to merge any patch which relies upon hpd bits for hdmi. > > >-Daniel > > > > > I will try on ivb. > > I don't think it's ivb specific, since we do have ivb machines where hpd > works perfectly fine. Same for every other platform. The only thing which > seems common is that DP+ connectors work, but some of the hdmi-only > connectors fail. That's why I wondered whether there's something i915 does > different than the windows driver. In case you can get hold of one, the > broken laptop I have here is an Asus UX31A with ivb. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: eDP can be present on DDI-E
On Wed, Aug 12, 2015 at 10:27:08AM +, Zhang, Xiong Y wrote:
> > On Tue, 2015-08-11 at 11:47 +0200, Daniel Vetter wrote:
> > > On Thu, Aug 06, 2015 at 03:51:39PM +0800, Xiong Zhang wrote:
> > > > From: Rodrigo Vivi
> > > >
> > > > On Skylake we have eDP-to-VGA using DDI-E and another aux.
> > > > So let's identify it properly.
> > >
> > > eDP means panel (the only difference in the code we have between eDP
> > > and DP is the power panel sequncing). VGA very much means no panel.
> > >
> > > Is this some impressive hack (dp->vga dongle using panel power as it's
> > > power source) or what's going on here? Or just confused commit
> > > message?
> >
> > That's a good question. I've heard from customer the embedded converter is
> > eDP-to-VGA, not DP-to-VGA so I'm not sure what is behind and I have no
> > machine here with me.
> [Xiong, Zhang]: From vbt, it is a DP-to-VGA, not eDP-to-VGA
> [ 103.407648] [drm:parse_ddi_port] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0
> CRT:0
> >
> > Xiong, could you please check with customer if everything works without this
> > patch?
> [Xiong, Zhang]: Everything works well without this patch on customer's
> machine. But if a eDP indeed connect to DDI-E without this patch,
> intel_dp_is_edp(PORT_E) will return false, then eDP on DDI-E couldn't
> work.
So if I understand it correctly this isn't about a dp2vga dongle but
simply about edp on ddi-E? And it's also not tested with a panel connected
to ddi-E?
If that's correct I'll update the commit message to reflect this
accurately and merge the patch.
-Daniel
> >
> > Thanks,
> > Rodrigo.
> >
> > > I'll punt on this for now.
> > > -Daniel
> > >
> > > >
> > > > Also let's remove duplicated definitions to avoid later confusion.
> > > >
> > > > Signed-off-by: Rodrigo Vivi
> > > > ---
> > > > drivers/gpu/drm/i915/intel_bios.h | 5 -
> > > > drivers/gpu/drm/i915/intel_dp.c | 9 +
> > > > 2 files changed, 5 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_bios.h
> > > > b/drivers/gpu/drm/i915/intel_bios.h
> > > > index 02255d8..a2ef0df 100644
> > > > --- a/drivers/gpu/drm/i915/intel_bios.h
> > > > +++ b/drivers/gpu/drm/i915/intel_bios.h
> > > > @@ -747,11 +747,6 @@ int intel_parse_bios(struct drm_device *dev);
> > > > #defineDVO_C 2
> > > > #defineDVO_D 3
> > > >
> > > > -/* define the PORT for DP output type */
> > > > -#definePORT_IDPB 7
> > > > -#definePORT_IDPC 8
> > > > -#definePORT_IDPD 9
> > > > -
> > > > /* Possible values for the "DVO Port" field for versions >= 155:
> > > > */
> > > > #define DVO_PORT_HDMIA 0
> > > > #define DVO_PORT_HDMIB 1
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c index 7cd47bc..0643a91 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -4978,16 +4978,17 @@ intel_trans_dp_port_sel(struct drm_crtc
> > > > *crtc)
> > > > return -1;
> > > > }
> > > >
> > > > -/* check the VBT to see whether the eDP is on DP-D port */
> > > > +/* check the VBT to see whether the eDP is on another port */
> > > > bool intel_dp_is_edp(struct drm_device *dev, enum port port) {
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > union child_device_config *p_child;
> > > > int i;
> > > > static const short port_mapping[] = {
> > > > - [PORT_B] = PORT_IDPB,
> > > > - [PORT_C] = PORT_IDPC,
> > > > - [PORT_D] = PORT_IDPD,
> > > > + [PORT_B] = DVO_PORT_DPB,
> > > > + [PORT_C] = DVO_PORT_DPC,
> > > > + [PORT_D] = DVO_PORT_DPD,
> > > > + [PORT_E] = DVO_PORT_DPE,
> > > > };
> > > >
> > > > if (port == PORT_A)
> > > > --
> > > > 2.1.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E
On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
> DDI-E doesn't have the correspondent GMBUS pin.
>
> We rely on VBT to tell us which one it being used instead.
>
> The DVI/HDMI on shared port couldn't exist.
>
> This patch isn't tested without hardware wchich has HDMI
> on DDI-E.
>
> v2: fix trailing whitespace
> v3: WARN() take place of BUG()
I asked for MISSING_CASE, not WARN.
-Daniel
>
> Signed-off-by: Xiong Zhang
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_bios.c | 25 +
> drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
> 3 files changed, 44 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6d93334..5d8e7fe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1414,6 +1414,10 @@ enum modeset_restore {
> #define DP_AUX_C 0x20
> #define DP_AUX_D 0x30
>
> +#define DDC_PIN_B 0x05
> +#define DDC_PIN_C 0x04
> +#define DDC_PIN_D 0x06
> +
> struct ddi_vbt_port_info {
> /*
>* This is an index in the HDMI/DVI DDI buffer translation table.
> @@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
> uint8_t supports_dp:1;
>
> uint8_t alternate_aux_channel;
> + uint8_t alternate_ddc_pin;
> };
>
> enum psr_lines_to_wait {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 16cdf17..8140531 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> uint8_t hdmi_level_shift;
> int i, j;
> bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
> - uint8_t aux_channel;
> + uint8_t aux_channel, ddc_pin;
> /* Each DDI port can have more than one value on the "DVO Port" field,
>* so look for all the possible values for each port and abort if more
>* than one is found. */
> @@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> return;
>
> aux_channel = child->raw[25];
> + ddc_pin = child->common.ddc_pin;
>
> is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
> is_dp = child->common.device_type & DEVICE_TYPE_DISPLAYPORT_OUTPUT;
> @@ -959,11 +960,27 @@ static void parse_ddi_port(struct drm_i915_private
> *dev_priv, enum port port,
> DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
>
> if (is_dvi) {
> - if (child->common.ddc_pin == 0x05 && port != PORT_B)
> + if (port == PORT_E) {
> + info->alternate_ddc_pin = ddc_pin;
> + /* if DDIE share ddc pin with other port, then
> + * dvi/hdmi couldn't exist on the shared port.
> + * Otherwise they share the same ddc bin and system
> + * couldn't communicate with them seperately. */
> + if (ddc_pin == DDC_PIN_B) {
> +
> dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
> +
> dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
> + } else if (ddc_pin == DDC_PIN_C) {
> +
> dev_priv->vbt.ddi_port_info[PORT_C].supports_dvi = 0;
> +
> dev_priv->vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
> + } else if (ddc_pin == DDC_PIN_D) {
> +
> dev_priv->vbt.ddi_port_info[PORT_D].supports_dvi = 0;
> +
> dev_priv->vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
> + }
> + } else if (ddc_pin == DDC_PIN_B && port != PORT_B)
> DRM_DEBUG_KMS("Unexpected DDC pin for port B\n");
> - if (child->common.ddc_pin == 0x04 && port != PORT_C)
> + else if (ddc_pin == DDC_PIN_C && port != PORT_C)
> DRM_DEBUG_KMS("Unexpected DDC pin for port C\n");
> - if (child->common.ddc_pin == 0x06 && port != PORT_D)
> + else if (ddc_pin == DDC_PIN_D && port != PORT_D)
> DRM_DEBUG_KMS("Unexpected DDC pin for port D\n");
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 70bad5b..a4129f2 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1991,6 +1991,24 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> intel_hdmi->ddc_bus = GMBUS_PIN_DPD;
> intel_encoder->hpd_pin = HPD_PORT_D;
> break;
> + case PORT_E:
> + /* On SKL PORT E doesn't have seperate GMBUS pin
> + * We rely on VBT to set a proper alternate
Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series
Regards Shashank On 8/12/2015 5:55 PM, Daniel Vetter wrote: On Tue, Aug 11, 2015 at 11:03:54AM +, Sharma, Shashank wrote: HI Daniel, Looks like we are not getting an IVB machine here. I think instead of blocking the patch set for the whole series, we can just block it for the platforms we don’t get success for. We are shipping many VLV/CHV systems with these patches applied, and they are passing all Android test suits and test benches, so we don’t doubt the solution as such. We have done testing for following platforms (gen 9 is tested by Imre also): 1. CHV / BSW 2. SKL 3. BXT 4. BDW I know that it works on piles of other platforms too. The problem is figuring out why it doesn't work on some and what we're doing wrong. Why don’t we go ahead with this solution for gen 8 onwards, and keep the rest of the code un touched, this will serve both the purpose. I guess we can, but if we get a regression report on bdw because of this I'll be furious. -Daniel I completely agree, and understand your concern about adding regression. How about this, we perform an extended set of testing on BDW also, and only after seeing the test reports, we can take a call on merging these patches. Regards Shashank -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Daniel Vetter Sent: Tuesday, August 11, 2015 3:12 PM To: Jindal, Sonika Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote: On 8/10/2015 1:38 PM, Daniel Vetter wrote: On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote: Hi Daniel, That patch was already merged: http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.htm l For SKL, the above patch helped in getting the correct ISR bits set. One option is to enable the HDMI optimization from VLV onwards. I don't have an ivb machine to try out the issue. ivb is simple the machine I have here, but when we tried this the last time around we had reports for all platforms (your patch still doesn't cite the relevant sha1 btw). I think there are 3 possible explanations: Yes, I don't know which were those patches and how to find them.. git blame (recursively) and git log on intel_hdmi.c will tell you the story. I require all these extensive git commit messages because I dig them out daily. Also git log --pickaxe (well I use the equivalent in the gitk gui). If these tools are generally unknown in the vpg display team then we absolutely need to do a training session about them, they're extremely powerful and useful to dig out the history of the i915 code. a) we do something wrong with hpd handling on these platforms. That seems to be the explanation you favour (with the gen >= 7 checks and all that), but I think it's very unlikely: On each platform where we had reports of hpd being broken there was also machines where hpd works perfectly fine. Not sure, I will find one ivb system and try on that. b) There's broken HDMI (or DVI) sinks out there. If that's the case we can never merge your patch. I doubt this because we have tested these patches with many sinks in the past with VLV/CHV. c) There's something in vbt or somewhere else that tells the windows driver whether using hpd or not is ok (and the hpd problem is actually an issue with certain OEM machines ...). No, nothing like that. I hoped that with your hpd handling fix we'd have some indication that our hpd troubles are of type a). But since I tested with your patch that didn't work out. And until we have some evidence that our hpd troubles aren't type b) I really don't want to merge any patch which relies upon hpd bits for hdmi. -Daniel I will try on ivb. I don't think it's ivb specific, since we do have ivb machines where hpd works perfectly fine. Same for every other platform. The only thing which seems common is that DP+ connectors work, but some of the hdmi-only connectors fail. That's why I wondered whether there's something i915 does different than the windows driver. In case you can get hold of one, the broken laptop I have here is an Asus UX31A with ivb. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ 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] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On Fri, Aug 07, 2015 at 02:07:39PM +0100, Chris Wilson wrote: > On Fri, Aug 07, 2015 at 01:55:01PM +0200, Daniel Vetter wrote: > > On Fri, Aug 07, 2015 at 11:10:58AM +0100, Chris Wilson wrote: > > > On Fri, Aug 07, 2015 at 10:07:28AM +0200, Daniel Vetter wrote: > > > > On Thu, Aug 06, 2015 at 05:43:39PM +0100, Chris Wilson wrote: > > > > But it's still salvageable I think since we only care about coherency > > > > for > > > > the gpu (where data might be stuck in cpu caches). From the cpu's pov > > > > (and > > > > hence the entire system except the gpu) we should never see > > > > inconsistency > > > > really - as soon as the gpu does a write to a cacheline it'll win, and > > > > before that nothing in the system can assume anything about the contents > > > > of these pages. > > > > > > But the GPU doesn't write to cachelines (except in LLC/snooped+flush). > > > The issue is what happens when the user lies about writing to the object > > > through a WB cpu mapping (dirtying a cacheline) and the GPU also does. > > > Who wins then? > > > > > > We have postulated that it could be entirely possible for the CPU to > > > trust it cache and return local contents and for those to be also > > > considered not dirty and so not flushed to memory. Later, we then read > > > what the gpu wrote and choas ensues. > > > > This was just with an eye towards purged memory where we don't care about > > correct data anyway. The only thing we care about is that when it's all > > overwritten again by someone, that someone should win. And since GEM > > assumes new pages are in the cpu domain and clflushes them first that > > should hold even for GEM. But the tricky part is that I think we can pull > > this off only if the backing storage is purged already. > > But what's the difference between: > > lock > put_pages > purge > > and > > lock > purge > put_pages > > if you are dismissing the user dirtying CPU cachelines vs already dirty > GPU data as being a source of worry? Just worrying that eventually we'll change something and end up without the purge after put_pages. If we reorder we can't get it wrong. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 0/3] HDMI optimization series
On Wed, Aug 12, 2015 at 06:04:50PM +0530, Sharma, Shashank wrote: > Regards > Shashank > > On 8/12/2015 5:55 PM, Daniel Vetter wrote: > >On Tue, Aug 11, 2015 at 11:03:54AM +, Sharma, Shashank wrote: > >>HI Daniel, > >> > >>Looks like we are not getting an IVB machine here. I think instead of > >>blocking the patch set for the whole series, we can just block it for the > >>platforms we don’t get success for. > >>We are shipping many VLV/CHV systems with these patches applied, and they > >>are passing all Android test suits and test benches, so we don’t doubt the > >>solution as such. > >> > >>We have done testing for following platforms (gen 9 is tested by Imre also): > >>1. CHV / BSW > >>2. SKL > >>3. BXT > >>4. BDW > > > >I know that it works on piles of other platforms too. The problem is > >figuring out why it doesn't work on some and what we're doing wrong. > > > >>Why don’t we go ahead with this solution for gen 8 onwards, and keep the > >>rest of the code un touched, this will serve both the purpose. > > > >I guess we can, but if we get a regression report on bdw because of this > >I'll be furious. > >-Daniel > > > I completely agree, and understand your concern about adding regression. How > about this, we perform an extended set of testing on BDW also, and only > after seeing the test reports, we can take a call on merging these patches. The problem is that no one seems to have machines with broken hpd, I stumbled over the broken ivb here purely by accident. The only way to get testing is to merge the patches and then wait for someone to complain. Trying to do exhaustive testing beforehand is imo impossible. The only thing which would alleviate my concerns is fixing the hpd handling bugs we know about already, since in the past we've just done "oh doesn't work on genX, try on genX+1 only then" and that never worked out. And we've tried this for _every_ _single_ platform since gen4. But we can try once more, simply be aware that if it breaks again I will not accept a patch to restrict to gen9 but instead will rip it out again. -Daniel > >> > >>Regards > >>Shashank > >>-Original Message- > >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > >>Of Daniel Vetter > >>Sent: Tuesday, August 11, 2015 3:12 PM > >>To: Jindal, Sonika > >>Cc: intel-gfx@lists.freedesktop.org > >>Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series > >> > >>On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote: > >>> > >>> > >>>On 8/10/2015 1:38 PM, Daniel Vetter wrote: > On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote: > >Hi Daniel, > > > >That patch was already merged: > >http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.htm > >l > > > >For SKL, the above patch helped in getting the correct ISR bits set. > >One option is to enable the HDMI optimization from VLV onwards. > >I don't have an ivb machine to try out the issue. > > ivb is simple the machine I have here, but when we tried this the > last time around we had reports for all platforms (your patch still > doesn't cite the relevant sha1 btw). I think there are 3 possible > explanations: > > >>>Yes, I don't know which were those patches and how to find them.. > >> > >>git blame (recursively) and git log on intel_hdmi.c will tell you the > >>story. I require all these extensive git commit messages because I dig them > >>out daily. Also git log --pickaxe (well I use the equivalent in the gitk > >>gui). If these tools are generally unknown in the vpg display team then we > >>absolutely need to do a training session about them, they're extremely > >>powerful and useful to dig out the history of the i915 code. > >> > a) we do something wrong with hpd handling on these platforms. That > seems to be the explanation you favour (with the gen >= 7 checks and > all that), but I think it's very unlikely: On each platform where we > had reports of hpd being broken there was also machines where hpd works > perfectly fine. > > >>>Not sure, I will find one ivb system and try on that. > >>> > b) There's broken HDMI (or DVI) sinks out there. If that's the case > we can never merge your patch. > >>>I doubt this because we have tested these patches with many sinks in > >>>the past with VLV/CHV. > > c) There's something in vbt or somewhere else that tells the windows > driver whether using hpd or not is ok (and the hpd problem is > actually an issue with certain OEM machines ...). > > >>>No, nothing like that. > >>> > I hoped that with your hpd handling fix we'd have some indication > that our hpd troubles are of type a). But since I tested with your > patch that didn't work out. > > And until we have some evidence that our hpd troubles aren't type b) > I really don't want to merge any patch which relies upon hpd bits for > hdmi. > -Daniel >
Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply
On Wed, Aug 12, 2015 at 11:36:07AM +0530, Sivakumar Thulasimani wrote:
> Hi Daniel,
> any comments for the patch below ?
Find me a reviewer to r-b stamp this patch and I'll merge.
-Daniel
>
> regards,
> Sivakumar
>
> On Friday 07 August 2015 03:14 PM, Sivakumar Thulasimani wrote:
> >From: "Thulasimani,Sivakumar"
> >
> >DP spec requires the checksum of the last block read to be written
> >when replying to TEST_EDID_READ. This patch fixes the current code
> >to do the same.
> >
> >v2: removed loop for jumping blocks and performed direct addition
> >as recommended by Daniel
> >
> >Signed-off-by: Sivakumar Thulasimani
> >---
> > drivers/gpu/drm/i915/intel_dp.c |9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >b/drivers/gpu/drm/i915/intel_dp.c
> >index f1b9f93..fa6e202 100644
> >--- a/drivers/gpu/drm/i915/intel_dp.c
> >+++ b/drivers/gpu/drm/i915/intel_dp.c
> >@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp
> >*intel_dp)
> > intel_dp->aux.i2c_defer_count);
> > intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
> > } else {
> >+struct edid *block = intel_connector->detect_edid;
> >+
> >+/* We have to write the checksum
> >+ * of the last block read
> >+ */
> >+block += intel_connector->detect_edid->extensions;
> >+
> > if (!drm_dp_dpcd_write(&intel_dp->aux,
> > DP_TEST_EDID_CHECKSUM,
> >-&intel_connector->detect_edid->checksum,
> >+&block->checksum,
> > 1))
> > DRM_DEBUG_KMS("Failed to write EDID checksum\n");
>
--
Daniel Vetter
Software Engineer, Intel Corporation
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 0/3] HDMI optimization series
Sure, I understood the point. We will do another round of testing with gen8, and when we are good with that, will submit the patches again. Regards Shashank -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Wednesday, August 12, 2015 6:11 PM To: Sharma, Shashank Cc: Daniel Vetter; Jindal, Sonika; intel-gfx@lists.freedesktop.org; Mukherjee, Indranil Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series On Wed, Aug 12, 2015 at 06:04:50PM +0530, Sharma, Shashank wrote: > Regards > Shashank > > On 8/12/2015 5:55 PM, Daniel Vetter wrote: > >On Tue, Aug 11, 2015 at 11:03:54AM +, Sharma, Shashank wrote: > >>HI Daniel, > >> > >>Looks like we are not getting an IVB machine here. I think instead of > >>blocking the patch set for the whole series, we can just block it for the > >>platforms we don’t get success for. > >>We are shipping many VLV/CHV systems with these patches applied, and they > >>are passing all Android test suits and test benches, so we don’t doubt the > >>solution as such. > >> > >>We have done testing for following platforms (gen 9 is tested by Imre also): > >>1. CHV / BSW > >>2. SKL > >>3. BXT > >>4. BDW > > > >I know that it works on piles of other platforms too. The problem is > >figuring out why it doesn't work on some and what we're doing wrong. > > > >>Why don’t we go ahead with this solution for gen 8 onwards, and keep > >>the rest of the code un touched, this will serve both the purpose. > > > >I guess we can, but if we get a regression report on bdw because of > >this I'll be furious. > >-Daniel > > > I completely agree, and understand your concern about adding > regression. How about this, we perform an extended set of testing on > BDW also, and only after seeing the test reports, we can take a call on > merging these patches. The problem is that no one seems to have machines with broken hpd, I stumbled over the broken ivb here purely by accident. The only way to get testing is to merge the patches and then wait for someone to complain. Trying to do exhaustive testing beforehand is imo impossible. The only thing which would alleviate my concerns is fixing the hpd handling bugs we know about already, since in the past we've just done "oh doesn't work on genX, try on genX+1 only then" and that never worked out. And we've tried this for _every_ _single_ platform since gen4. But we can try once more, simply be aware that if it breaks again I will not accept a patch to restrict to gen9 but instead will rip it out again. -Daniel > >> > >>Regards > >>Shashank > >>-Original Message- > >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > >>Behalf Of Daniel Vetter > >>Sent: Tuesday, August 11, 2015 3:12 PM > >>To: Jindal, Sonika > >>Cc: intel-gfx@lists.freedesktop.org > >>Subject: Re: [Intel-gfx] [PATCH 0/3] HDMI optimization series > >> > >>On Mon, Aug 10, 2015 at 02:05:47PM +0530, Jindal, Sonika wrote: > >>> > >>> > >>>On 8/10/2015 1:38 PM, Daniel Vetter wrote: > On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote: > >Hi Daniel, > > > >That patch was already merged: > >http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142. > >htm > >l > > > >For SKL, the above patch helped in getting the correct ISR bits set. > >One option is to enable the HDMI optimization from VLV onwards. > >I don't have an ivb machine to try out the issue. > > ivb is simple the machine I have here, but when we tried this the > last time around we had reports for all platforms (your patch > still doesn't cite the relevant sha1 btw). I think there are 3 possible > explanations: > > >>>Yes, I don't know which were those patches and how to find them.. > >> > >>git blame (recursively) and git log on intel_hdmi.c will tell you the > >>story. I require all these extensive git commit messages because I dig them > >>out daily. Also git log --pickaxe (well I use the equivalent in the gitk > >>gui). If these tools are generally unknown in the vpg display team then we > >>absolutely need to do a training session about them, they're extremely > >>powerful and useful to dig out the history of the i915 code. > >> > a) we do something wrong with hpd handling on these platforms. > That seems to be the explanation you favour (with the gen >= 7 > checks and all that), but I think it's very unlikely: On each > platform where we had reports of hpd being broken there was also machines > where hpd works perfectly fine. > > >>>Not sure, I will find one ivb system and try on that. > >>> > b) There's broken HDMI (or DVI) sinks out there. If that's the > case we can never merge your patch. > >>>I doubt this because we have tested these patches with many sinks > >>>in the past with VLV/CHV. > > c) There's something in vbt or somewhere else that tells the > windows driver whethe
Re: [Intel-gfx] [PATCH] drm/i915: Only move to the CPU write domain if keeping the GTT pages
On Wed, Aug 12, 2015 at 02:35:59PM +0200, Daniel Vetter wrote: > On Fri, Aug 07, 2015 at 02:07:39PM +0100, Chris Wilson wrote: > > On Fri, Aug 07, 2015 at 01:55:01PM +0200, Daniel Vetter wrote: > > > On Fri, Aug 07, 2015 at 11:10:58AM +0100, Chris Wilson wrote: > > > > On Fri, Aug 07, 2015 at 10:07:28AM +0200, Daniel Vetter wrote: > > > > > On Thu, Aug 06, 2015 at 05:43:39PM +0100, Chris Wilson wrote: > > > > > But it's still salvageable I think since we only care about coherency > > > > > for > > > > > the gpu (where data might be stuck in cpu caches). From the cpu's pov > > > > > (and > > > > > hence the entire system except the gpu) we should never see > > > > > inconsistency > > > > > really - as soon as the gpu does a write to a cacheline it'll win, and > > > > > before that nothing in the system can assume anything about the > > > > > contents > > > > > of these pages. > > > > > > > > But the GPU doesn't write to cachelines (except in LLC/snooped+flush). > > > > The issue is what happens when the user lies about writing to the object > > > > through a WB cpu mapping (dirtying a cacheline) and the GPU also does. > > > > Who wins then? > > > > > > > > We have postulated that it could be entirely possible for the CPU to > > > > trust it cache and return local contents and for those to be also > > > > considered not dirty and so not flushed to memory. Later, we then read > > > > what the gpu wrote and choas ensues. > > > > > > This was just with an eye towards purged memory where we don't care about > > > correct data anyway. The only thing we care about is that when it's all > > > overwritten again by someone, that someone should win. And since GEM > > > assumes new pages are in the cpu domain and clflushes them first that > > > should hold even for GEM. But the tricky part is that I think we can pull > > > this off only if the backing storage is purged already. > > > > But what's the difference between: > > > > lock > > put_pages > > purge > > > > and > > > > lock > > purge > > put_pages > > > > if you are dismissing the user dirtying CPU cachelines vs already dirty > > GPU data as being a source of worry? > > Just worrying that eventually we'll change something and end up without > the purge after put_pages. If we reorder we can't get it wrong. I'd rather keep my sanity checks (that say we are not allowed to touch the backing storage whilst we are still using it). So how about a comment in put_pages() detailing the issue? -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 i-g-t 1/3] lib/core: Add optional reason for timeout failure
On Fri, Aug 07, 2015 at 11:10:22AM -0700, Jesse Barnes wrote:
> On 08/07/2015 10:29 AM, Daniel Vetter wrote:
> > "Timed out" isn't a terribly informative message, allow users to set
> > something more informative. Inspired by a request from Jesse.
> >
> > Cc: Jesse Barnes
> > Signed-off-by: Daniel Vetter
> > ---
> > lib/igt_core.c | 12 ++--
> > lib/igt_core.h | 3 ++-
> > lib/igt_debugfs.c | 4 ++--
> > lib/tests/igt_timeout.c | 2 +-
> > tests/kms_flip.c| 4 ++--
> > 5 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index af3d87316857..e2c2502bd147 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -1748,9 +1748,13 @@ out:
> > free(line);
> > }
> >
> > +static const char *timeout_op;
> > static void igt_alarm_handler(int signal)
> > {
> > - igt_info("Timed out\n");
> > + if (timeout_op)
> > + igt_info("Timed out: %s\n", timeout_op);
> > + else
> > + igt_info("Timed out\n");
> >
> > /* exit with failure status */
> > igt_fail(IGT_EXIT_FAILURE);
> > @@ -1759,6 +1763,7 @@ static void igt_alarm_handler(int signal)
> > /**
> > * igt_set_timeout:
> > * @seconds: number of seconds before timeout
> > + * @op: Optional string to explain what operation has timed out in the
> > debug log
> > *
> > * Fail a test and exit with #IGT_EXIT_FAILURE status after the specified
> > * number of seconds have elapsed. If the current test has subtests and the
> > @@ -1768,7 +1773,8 @@ static void igt_alarm_handler(int signal)
> > * Any previous timer is cancelled and no timeout is scheduled if @seconds
> > is
> > * zero.
> > */
> > -void igt_set_timeout(unsigned int seconds)
> > +void igt_set_timeout(unsigned int seconds,
> > +const char *op)
> > {
> > struct sigaction sa;
> >
> > @@ -1776,6 +1782,8 @@ void igt_set_timeout(unsigned int seconds)
> > sigemptyset(&sa.sa_mask);
> > sa.sa_flags = 0;
> >
> > + timeout_op = op;
> > +
> > if (seconds == 0)
> > sigaction(SIGALRM, NULL, NULL);
> > else
> > diff --git a/lib/igt_core.h b/lib/igt_core.h
> > index 83eac02b28bf..1a324ee85514 100644
> > --- a/lib/igt_core.h
> > +++ b/lib/igt_core.h
> > @@ -732,7 +732,8 @@ extern enum igt_log_level igt_log_level;
> > } while (0)
> >
> >
> > -void igt_set_timeout(unsigned int seconds);
> > +void igt_set_timeout(unsigned int seconds,
> > +const char *op);
> >
> > FILE *__igt_fopen_data(const char* igt_srcdir, const char* igt_datadir,
> >const char* filename);
> > diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> > index 568154ac0e80..6180a2aa56db 100644
> > --- a/lib/igt_debugfs.c
> > +++ b/lib/igt_debugfs.c
> > @@ -463,9 +463,9 @@ static bool read_one_crc(igt_pipe_crc_t *pipe_crc,
> > igt_crc_t *out)
> > ssize_t bytes_read;
> > char buf[pipe_crc->buffer_len];
> >
> > - igt_set_timeout(5);
> > + igt_set_timeout(5, "CRC reading");
> > bytes_read = read(pipe_crc->crc_fd, &buf, pipe_crc->line_len);
> > - igt_set_timeout(0);
> > + igt_set_timeout(0, NULL);
> >
> > igt_assert_eq(bytes_read, pipe_crc->line_len);
> > buf[bytes_read] = '\0';
> > diff --git a/lib/tests/igt_timeout.c b/lib/tests/igt_timeout.c
> > index 8affa61f3d79..d228041d493b 100644
> > --- a/lib/tests/igt_timeout.c
> > +++ b/lib/tests/igt_timeout.c
> > @@ -3,6 +3,6 @@
> >
> > igt_simple_main
> > {
> > - igt_set_timeout(1);
> > + igt_set_timeout(1, "Testcase");
> > sleep(5);
> > }
> > diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> > index 25c924305c32..214cd696fd2f 100644
> > --- a/tests/kms_flip.c
> > +++ b/tests/kms_flip.c
> > @@ -1614,9 +1614,9 @@ static void test_nonblocking_read(int in)
> > }
> > igt_require(ret != -1);
> >
> > - igt_set_timeout(5);
> > + igt_set_timeout(5, "Nonblocking DRM fd reading");
> > ret = read(fd, buffer, sizeof(buffer));
> > - igt_set_timeout(0);
> > + igt_set_timeout(0, NULL);
> > igt_assert_eq(ret, -1);
> > igt_assert_eq(errno, EAGAIN);
> >
> >
>
> Reviewed-by: Jesse Barnes
Thanks for the review, pushed this patch + the other two + David's patch
to test NO_ZEROMAP to fix the gem_ctx_param_basic regression.
-Daniel
>
> The earlier version worked like a charm.
>
> Thanks,
> Jesse
--
Daniel Vetter
Software Engineer, Intel Corporation
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: Report IOMMU enabled status for GPU hangs
On Fri, Aug 07, 2015 at 08:24:15PM +0100, Chris Wilson wrote:
> The IOMMU for Intel graphics has historically had many issues resulting
> in random GPU hangs. Lets include its status when capturing the GPU hang
> error state for post-mortem analysis.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu_error.c | 5 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 786ddd8b4e97..82d225786db2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -488,6 +488,7 @@ struct drm_i915_error_state {
> struct timeval time;
>
> char error_msg[128];
> + int iommu;
> u32 reset_count;
> u32 suspend_count;
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 0110c2626859..21ae99e5b1ed 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -399,6 +399,7 @@ int i915_error_state_to_str(struct
> drm_i915_error_state_buf *m,
> err_printf(m, "Reset count: %u\n", error->reset_count);
> err_printf(m, "Suspend count: %u\n", error->suspend_count);
> err_printf(m, "PCI ID: 0x%04x\n", dev->pdev->device);
> + err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
> err_printf(m, "EIR: 0x%08x\n", error->eir);
> err_printf(m, "IER: 0x%08x\n", error->ier);
> if (INTEL_INFO(dev)->gen >= 8) {
> @@ -1341,6 +1342,10 @@ static void i915_error_capture_msg(struct drm_device
> *dev,
> static void i915_capture_gen_state(struct drm_i915_private *dev_priv,
> struct drm_i915_error_state *error)
> {
> + error->iommu = -1;
> +#ifdef CONFIG_INTEL_IOMMU
> + error->iommu = intel_iommu_gfx_mapped;
> +#endif
> error->reset_count = i915_reset_count(&dev_priv->gpu_error);
> error->suspend_count = dev_priv->suspend_count;
> }
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP
On Mon, Aug 10, 2015 at 05:51:48PM +0530, Sivakumar Thulasimani wrote: > > > On 8/10/2015 5:44 PM, Jani Nikula wrote: > >On Mon, 10 Aug 2015, Sivakumar Thulasimani > >wrote: > >>On 8/10/2015 5:07 PM, Jani Nikula wrote: > >>>On Mon, 10 Aug 2015, Sivakumar Thulasimani > >>> wrote: > Reviewed-by: Sivakumar Thulasimani > > On 8/10/2015 10:35 AM, Sonika Jindal wrote: > >With HPD support added for all ports including PORT_A, setting hpd_pin > >will > >result in enabling of hpd to edp as well. There is no need to enable HPD > >on > >PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will > >be connected. it can be added back when required > >>>What? You can't just go ahead and remove HPD from eDP sinks. > >>> > >>>BR, > >>>Jani. > >>Nope, we are not removing HPD for edp sinks, it was never there in the > >>first place. It was > >>enabled for CHV (even there by mistake since PORT B/C was both DP and > >>eDP) but it was > >>never there for any other plaforms nor is it used for any purpose (PSR > >>must use it, but i > >>dont see code for it as well). > >Are you saying there's no HPD enabled in our *hardware* for eDP? Or > >driver? > > > >My point is, is this patch making it harder to enable eDP hpd handling > >(e.g. for PSR or DP link re-training) in the future? We currently take > >it into account in a few places, and if we start removing that, it will > >be a loss of effort to first remove and then add it back. > > > >BR, > >Jani. > i was referring to our driver only. > > Our VLV/CHV code already receives hpd for every pps on and off which is > later ignored. if we dont disable HPD on eDPs this behavior will be extended > for all platforms which i feel is too costly to keep enabled when there is > no > purpose for it right now. don't optimize code because you "feel it's costly", only do it when you have hard numbers. One interrupt per pps on or off transition won't be measurable at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 3/3] drm/i915/bxt: WA for swapped HPD pins in A stepping
On Mon, Aug 10, 2015 at 10:58:55AM +0530, Sivakumar Thulasimani wrote: > Reviewed-by: Sivakumar Thulasimani > > On 8/10/2015 10:35 AM, Sonika Jindal wrote: > >WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling > >DDIA HPD pin in place of DDIB. > > > >v2: For DP, irq_port is used to determine the encoder instead of > >hpd_pin and removing the edp HPD logic because port A HPD is not > >present(Imre) > >v3: Rebased on top of Imre's patchset for enabling HPD on PORT A. > >Added hpd_pin swapping for intel_dp_init_connector, setting encoder > >for PORT_A as per the WA in irq_port (Imre) > >v4: Dont enable interrupt for edp, also reframe the description (Siva) > >v5: Don’t check for PORT_A in intel_ddi_init to update dig_port, > >instead avoid setting hpd_pin itself (Imre) > > > >Signed-off-by: Sonika Jindal Merged patches 2&3 from this series, thanks. -Daniel > >--- > > drivers/gpu/drm/i915/intel_ddi.c | 10 +- > > drivers/gpu/drm/i915/intel_dp.c |2 ++ > > drivers/gpu/drm/i915/intel_hdmi.c |9 - > > 3 files changed, 19 insertions(+), 2 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_ddi.c > >b/drivers/gpu/drm/i915/intel_ddi.c > >index e2c6f73..777e3a3 100644 > >--- a/drivers/gpu/drm/i915/intel_ddi.c > >+++ b/drivers/gpu/drm/i915/intel_ddi.c > >@@ -3225,7 +3225,15 @@ void intel_ddi_init(struct drm_device *dev, enum port > >port) > > goto err; > > intel_dig_port->hpd_pulse = intel_dp_hpd_pulse; > >-dev_priv->hotplug.irq_port[port] = intel_dig_port; > >+/* > >+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and > >+ * interrupts to check the external panel connection. > >+ */ > >+if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0) > >+ && port == PORT_B) > >+dev_priv->hotplug.irq_port[PORT_A] = intel_dig_port; > >+else > >+dev_priv->hotplug.irq_port[port] = intel_dig_port; > > } > > /* In theory we don't need the encoder->type check, but leave it just in > >diff --git a/drivers/gpu/drm/i915/intel_dp.c > >b/drivers/gpu/drm/i915/intel_dp.c > >index 5a614c9..7fab3e5 100644 > >--- a/drivers/gpu/drm/i915/intel_dp.c > >+++ b/drivers/gpu/drm/i915/intel_dp.c > >@@ -5788,6 +5788,8 @@ intel_dp_init_connector(struct intel_digital_port > >*intel_dig_port, > > break; > > case PORT_B: > > intel_encoder->hpd_pin = HPD_PORT_B; > >+if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) > >+intel_encoder->hpd_pin = HPD_PORT_A; > > break; > > case PORT_C: > > intel_encoder->hpd_pin = HPD_PORT_C; > >diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > >b/drivers/gpu/drm/i915/intel_hdmi.c > >index 70bad5b..94fa716 100644 > >--- a/drivers/gpu/drm/i915/intel_hdmi.c > >+++ b/drivers/gpu/drm/i915/intel_hdmi.c > >@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct > >intel_digital_port *intel_dig_port, > > intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT; > > else > > intel_hdmi->ddc_bus = GMBUS_PIN_DPB; > >-intel_encoder->hpd_pin = HPD_PORT_B; > >+/* > >+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and > >+ * interrupts to check the external panel connection. > >+ */ > >+if (IS_BROXTON(dev_priv) && (INTEL_REVID(dev) < BXT_REVID_B0)) > >+intel_encoder->hpd_pin = HPD_PORT_A; > >+else > >+intel_encoder->hpd_pin = HPD_PORT_B; > > break; > > case PORT_C: > > if (IS_BROXTON(dev_priv)) > > -- > regards, > Sivakumar > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Adding intel_panel_scale_none() helper function
On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote:
> I believe this function could be added along with the next patch that is
> the first to use it...
> Or it would be good to have a good commit message explaining why this
> function is needed and what is be used for...
Yes, please don't split up patches so much that you end up adding dead
code or dead structures - always try to have at least a minimal user for
something.
If you want to split things up really tiny then go the other way round:
First add the callers, then add the implementation. That way reviewers can
understand the big scope first and then dig into details. But this one
here really is small enough to just be squashed in.
-Daniel
>
> more bikeshedings inline:
>
> On Mon, Aug 10, 2015 at 12:39 AM Xiong Zhang
> wrote:
>
> > Signed-off-by: Xiong Zhang
> > ---
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_panel.c | 10 ++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 47cef0e..f57a0b4 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1287,6 +1287,7 @@ int intel_panel_init(struct intel_panel *panel,
> > void intel_panel_fini(struct intel_panel *panel);
> > void intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
> > struct drm_display_mode *adjusted_mode);
> > +bool intel_panel_scale_none(struct intel_panel *panel);
> > void intel_pch_panel_fitting(struct intel_crtc *crtc,
> > struct intel_crtc_state *pipe_config,
> > int fitting_mode);
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index e2ab3f6..4a573ac 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -46,6 +46,16 @@ intel_fixed_panel_mode(const struct drm_display_mode
> > *fixed_mode,
> > drm_mode_set_crtcinfo(adjusted_mode, 0);
> > }
> >
> > +bool
> > +intel_panel_scale_none(struct intel_panel *panel)
> >
>
> double negations always confuses me, when reading next patches it took few
> seconds to realize on next patch that !scale_none was == fixed_mode...
> but meh, I never have good suggestions to avoid double negations... so up
> to you...
>
>
> > +{
> > + if (panel->fitting_mode == DRM_MODE_SCALE_NONE ||
> > + panel->fixed_mode == NULL)
> > + return true;
> > + else
> > + return false;
> >
>
> this could be just return (panel->fitting_mode == DRM_MODE_SCALE_NONE ||
> panel->fixed_mode == NULL)
> or ! if you remove the double negation...
>
>
> > +}
> > +
> > /**
> > * intel_find_panel_downclock - find the reduced downclock for LVDS in
> > EDID
> > * @dev: drm device
> > --
> > 1.8.2.1
> >
> > ___
> > 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
--
Daniel Vetter
Software Engineer, Intel Corporation
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 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:
>
>
> On 8/12/2015 5:02 PM, Ville Syrjälä wrote:
> > On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:
> >> From: "Thulasimani,Sivakumar"
> >>
> >> This reverts
> >> commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
> >> Author: Ville Syrjälä
> >> Date: Thu Mar 12 17:10:38 2015 +0200
> >>
> >> CHV does not support intermediate frequencies so reverting the
> >> patch that added it in the first place
> > My docs still say it does. Is there some undocumented problem with the
> > PLL or is this just a marketing decision?
> I don't think so, i too have just one document that shows the phy values
> for each of
> the link rates but have not found any where else to say it is supported .
Display cluster HAS says they're supported. And since the spreadsheet
has them all in green I assume someone actually figured that they ought
to work.
> Also this is not tested by anyone including us from product team so i
> highly doubt
> it will even work.
Well if no one has tested them I guess we shouldn't try to use them. Not
a big loss in any case I suppose.
So based on that reasoning I can give an ack for this patch:
Acked-by: Ville Syrjälä
>
> regarding HBR2, it was supposed to land on a future stepping that never
> happened
> so it is not supported at all.
Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. Apart
from that there isn't much else to go by. Excepth the training pattern 3
support, but now that I look again the new bit for that has disappeared
from the DP register in the spec. Or maybe I was looking at the k0 spec
when I added it. It's still in the k0 spec but as you say that's been
nuked.
In light of this, I think dropping HBR2 is reasonable. HBR is anyway
enough for 4k@30 with 4 lanes, so it's not like we really need HBR2.
And could you also cook up a patch to kill the training pattern 3
support for CHV? Should be mostly a revert of my original patch that
added it, but you probably need to adjust the use_tps3 condition a bit
too.
> >> Signed-off-by: Sivakumar Thulasimani
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c |6 --
> >> 1 file changed, 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index 44f8a32..d9fb7a8 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000,
> >> 27,
> >> 324000, 432000, 54 };
> >> static const int skl_rates[] = { 162000, 216000, 27,
> >> 324000, 432000, 54 };
> >> -static const int chv_rates[] = { 162000, 202500, 21, 216000,
> >> - 243000, 27, 324000, 405000,
> >> - 42, 432000, 54 };
> >> static const int default_rates[] = { 162000, 27, 54 };
> >>
> >> /**
> >> @@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const
> >> int **source_rates)
> >>} else if (IS_SKYLAKE(dev)) {
> >>*source_rates = skl_rates;
> >>return ARRAY_SIZE(skl_rates);
> >> - } else if (IS_CHERRYVIEW(dev)) {
> >> - *source_rates = chv_rates;
> >> - return ARRAY_SIZE(chv_rates);
> >>}
> >>
> >>*source_rates = default_rates;
> >> --
> >> 1.7.9.5
>
> --
> regards,
> Sivakumar
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
On Mon, Aug 10, 2015 at 03:00:13PM +0300, Jani Nikula wrote:
> On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > + n_low = n & 0xfff;
> > + n_up = (n >> 12) & 0xff;
> > +
> > + /* 4. set the N/CTS */
> > + tmp = I915_READ(HSW_AUD_CFG(pipe));
> > + tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > + tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > + tmp |= (n_up << AUD_CONFIG_UPPER_N_SHIFT);
> > + tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > + tmp |= (n_low << AUD_CONFIG_LOWER_N_SHIFT);
>
> You could squash the ors and ands together.
Also read-modify-write considered evil. If you need to save a few bits
please be explicit about it like
tmp &= BITS_WE_WANT_TO_KEEP;
if there's no bits to keep just start out with 0. If we have too much rwm
to hw registers then probably something with the overall design is
botched, e.g. with the pipe config precomputation we managed to remove
almost all the rwm code for modesets.
-Daniel
>
> > + I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> > +
> > + return 0;
> > +}
> > +
> > static const struct i915_audio_component_ops i915_audio_component_ops = {
> > .owner = THIS_MODULE,
> > .get_power = i915_audio_component_get_power,
> > .put_power = i915_audio_component_put_power,
> > .codec_wake_override = i915_audio_component_codec_wake_override,
> > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > + .set_ncts = i915_audio_component_set_ncts,
> > };
> >
> > static int i915_audio_component_bind(struct device *i915_dev,
> > --
> > 1.9.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
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v2 2/4] drm/i915: implement set_ncts callback
On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
> On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > From: Libin Yang
> >
> > Display audio may not work at some frequencies
> > with the HW provided N/CTS.
> >
> > This patch sets the proper N value for the
> > given audio sample rate at the impacted frequencies.
> > At other frequencies, it will use the N/CTS value
> > which HW provides.
> >
> > Signed-off-by: Libin Yang
> > ---
> > drivers/gpu/drm/i915/i915_reg.h| 2 +
> > drivers/gpu/drm/i915/intel_audio.c | 95
> > ++
> > 2 files changed, 97 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index ea46d68..da2d128 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
> > _HSW_AUD_MISC_CTRL_A, \
> > _HSW_AUD_MISC_CTRL_B)
> >
> > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> > +
> > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index dc32cf4..eddf37f 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -68,6 +68,30 @@ static const struct {
> > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> > };
> >
> > +#define TMDS_297M 297000
> > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > +static const struct {
> > + int sample_rate;
> > + int clock;
> > + int n;
> > + int cts;
> > +} aud_ncts[] = {
> > + { 44100, TMDS_296M, 4459, 234375 },
> > + { 44100, TMDS_297M, 4704, 247500 },
> > + { 48000, TMDS_296M, 5824, 281250 },
> > + { 48000, TMDS_297M, 5120, 247500 },
> > + { 32000, TMDS_296M, 5824, 421875 },
> > + { 32000, TMDS_297M, 3072, 222750 },
> > + { 88200, TMDS_296M, 8918, 234375 },
> > + { 88200, TMDS_297M, 9408, 247500 },
> > + { 96000, TMDS_296M, 11648, 281250 },
> > + { 96000, TMDS_297M, 10240, 247500 },
> > + { 176400, TMDS_296M, 17836, 234375 },
> > + { 176400, TMDS_297M, 18816, 247500 },
> > + { 44100, TMDS_296M, 23296, 281250 },
> > + { 44100, TMDS_297M, 20480, 247500 },
> > +};
> > +
> > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> > static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
> > {
> > @@ -514,12 +538,83 @@ static int i915_audio_component_get_cdclk_freq(struct
> > device *dev)
> > return ret;
> > }
> >
> > +static int i915_audio_component_set_ncts(struct device *dev, int port,
> > + int dev_entry, int rate)
> > +{
> > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > + struct drm_device *drm_dev = dev_priv->dev;
> > + struct intel_encoder *intel_encoder;
> > + struct intel_digital_port *intel_dig_port;
> > + struct intel_crtc *crtc;
> > + struct drm_display_mode *mode;
> > + enum pipe pipe = -1;
> > + u32 tmp;
> > + int i;
> > + int n_low, n_up, n = 0;
>
> I think you'll need the power well get here, and put at the end. Or
> check that we it.
If we call this and end up actually dropping the power well then the
register writes will go exactly nowhere at all. Which indicates a bug in
how this is orchestrated. There is probably one ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: > On Wed, 12 Aug 2015, "Yang, Libin" wrote: > > Hi Jani, > > > >> -Original Message- > >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> Sent: Tuesday, August 11, 2015 4:14 PM > >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> modeset > >> > >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> > Hi Jani, > >> > > >> >> -Original Message- > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> Sent: Tuesday, August 11, 2015 3:14 PM > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> >> modeset > >> >> > >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> > Hi Jani, > >> >> > > >> >> > Thanks for careful reviewing for all the patches, please > >> >> > see my comments. > >> >> > > >> >> >> -Original Message- > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> Sent: Monday, August 10, 2015 8:10 PM > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS > >> in > >> >> >> modeset > >> >> >> > >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > >> >> >> > From: Libin Yang > >> >> >> > > >> >> >> > When modeset occurs and the TMDS frequency is set to some > >> >> >> > speical value, the N/CTS need to be set manually if audio > >> >> >> > is playing. > >> >> >> > >> >> >> When modeset occurs, we disable everything, and then re-enable > >> >> >> everything, and notify the audio driver every step of the way. IIUC > >> >> >> there should be no audio playing across the modeset, and when > >> the > >> >> >> modeset is complete and we've set the valid ELD, the audio driver > >> >> >> should > >> >> >> call the callback from the earlier patches to set the correct audio > >> >> >> rate. > >> >> >> > >> >> >> Why is this patch needed? Please enlighten me. > >> >> > > >> >> > Please image this scenario: when audio is playing, the gfx driver > >> >> > does the modeset. In this situation, after modeset, audio driver > >> >> > will do nothing and continue playing. And audio driver will not call > >> >> > set_ncts. > >> >> > >> >> Why does the audio driver not do anything here? Whenever there's > >> a > >> >> modeset, the graphics driver will disable audio and invalidate the > >> ELD, > >> >> which should cause an interrupt to notify the audio driver about > >> >> this. This is no different from a hot-unplug, in fact I can't see how > >> >> the audio driver could even detect whether there's been a hotplug > >> or > >> >> not > >> >> when there's a codec disable/enable. > >> > > >> > Yes, it will trigger an interrupt to audio driver when unplug > >> > and another interrupt for hotplug. But from audio driver, > >> > we will not stop the playing and resume the playing based > >> > on the hotplug or modeset. The audio is always playing during > >> > the hotplug/modeset. > >> > >> But the whole display, and consequently ELD, might have changed > >> during > >> the hotplug, why do you assume you can just keep playing?! The > >> display > >> might even have changed from HDMI to DP or vice versa. > > > > The eld info changing will not impact the audio playing. > > Actually, you can image the monitor as a digital speaker, just > > like the headphone to the analog audio. Unplug the speaker > > will not impact on the audio playing. Of course , there is a > > little difference, when monitor hotplug, in the interrupt, > > we may change the codec configuration dynamically. > > > > And audio driver supply the mechanism to stop the > > audio playing when hotplug if the HW requires. > > > >> > >> We've also been putting a lot of effort into not depending on previous > >> state when enabling the outputs, for more reliability. We generally > >> don't do partial changes, we disable everything and then enable > >> again. And now you're suggesting we look at some register which for all > >> we know may have been valid for some other display? > > > > In the patch, it will not depend on previous state, I think. We > > read the register value which is based on the state after modeset. > > Okay, let's have the patches cleaned up and see. It'll be easier and > quicker to solicit more review on that than this expanding thread. It sounds like we actually need to ping the audio side _before_ we do the hw modeset while computing the pipe_config. That would probably take care of my rwm concerns, give this thing proper structure and also make sure N/CTS never get out of sync. Also then we can track this stuff in the pipe_config
Re: [Intel-gfx] [PATCH 2/2] drm/i915: remove HBR2 from chv supported list
On Fri, Jul 31, 2015 at 11:32:53AM +0530, Sivakumar Thulasimani wrote: > From: "Thulasimani,Sivakumar" > > This patch removes 5.4Gbps from supported link rate for CHV since > it is not supported in it. > > Signed-off-by: Sivakumar Thulasimani > --- > drivers/gpu/drm/i915/intel_dp.c |5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index d9fb7a8..4e53433 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1186,8 +1186,9 @@ intel_dp_source_rates(struct drm_device *dev, const int > **source_rates) > > *source_rates = default_rates; > > - if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) > - /* WaDisableHBR2:skl */ > + /* WaDisableHBR2:skl */ > + if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) || > + IS_CHERRYVIEW(dev)) > return (DP_LINK_BW_2_7 >> 3) + 1; > else if (INTEL_INFO(dev)->gen >= 8 || > (IS_HASWELL(dev) && !IS_HSW_ULX(dev))) I would suggest reordering this a bit. Something likle this perhaps: /* WaDisableHBR2:skl */ if (IS_SKYLAKE && ...) return (DP_LINK_BW_2_7 >> 3) + 1; if ((IS_HASWELL && !IS_HSW_ULX) || IS_BROADWELL || gen >= 9) return (DP_LINK_BW_5_4 >> 3) + 1; else return (DP_LINK_BW_2_7 >> 3) + 1; IMO that makes it easier to see exactly which platforms support HBR2, and it keeps the SKL w/a separated neatly for easy removal in the near future (I'm assuming we want to kill the w/a based on the fact that it's for an early stepping). -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
> Depending on the VBT BDB version the maximum size
> can be up to 38 bytes.
>
> This fix increases the maximum of the VBT expected size
> from 33 bytes to 38 bytes and by doing so cures the kernel
> hang on BSW box.
>
> Signed-off-by: Mika Kahola
We already have David's patch in -fixes, how does this relate? How does it
blow up? Is this a regression? If so which commit created it? Where's the
bugzilla link from QA?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_bios.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a5..788463d 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -246,7 +246,7 @@ struct common_child_dev_config {
> union child_device_config {
> /* This one is safe to be used anywhere, but the code should still check
>* the BDB version. */
> - u8 raw[33];
> + u8 raw[38];
> /* This one should only be kept for legacy code. */
> struct old_child_dev_config old;
> /* This one should also be safe to use anywhere, even without version
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, 12 Aug 2015, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: >> On Wed, 12 Aug 2015, "Yang, Libin" wrote: >> > Hi Jani, >> > >> >> -Original Message- >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >> Sent: Tuesday, August 11, 2015 4:14 PM >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in >> >> modeset >> >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: >> >> > Hi Jani, >> >> > >> >> >> -Original Message- >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >> >> Sent: Tuesday, August 11, 2015 3:14 PM >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch >> >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in >> >> >> modeset >> >> >> >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: >> >> >> > Hi Jani, >> >> >> > >> >> >> > Thanks for careful reviewing for all the patches, please >> >> >> > see my comments. >> >> >> > >> >> >> >> -Original Message- >> >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >> >> >> Sent: Monday, August 10, 2015 8:10 PM >> >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- >> >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch >> >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS >> >> in >> >> >> >> modeset >> >> >> >> >> >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: >> >> >> >> > From: Libin Yang >> >> >> >> > >> >> >> >> > When modeset occurs and the TMDS frequency is set to some >> >> >> >> > speical value, the N/CTS need to be set manually if audio >> >> >> >> > is playing. >> >> >> >> >> >> >> >> When modeset occurs, we disable everything, and then re-enable >> >> >> >> everything, and notify the audio driver every step of the way. IIUC >> >> >> >> there should be no audio playing across the modeset, and when >> >> the >> >> >> >> modeset is complete and we've set the valid ELD, the audio driver >> >> >> >> should >> >> >> >> call the callback from the earlier patches to set the correct audio >> >> >> >> rate. >> >> >> >> >> >> >> >> Why is this patch needed? Please enlighten me. >> >> >> > >> >> >> > Please image this scenario: when audio is playing, the gfx driver >> >> >> > does the modeset. In this situation, after modeset, audio driver >> >> >> > will do nothing and continue playing. And audio driver will not call >> >> >> > set_ncts. >> >> >> >> >> >> Why does the audio driver not do anything here? Whenever there's >> >> a >> >> >> modeset, the graphics driver will disable audio and invalidate the >> >> ELD, >> >> >> which should cause an interrupt to notify the audio driver about >> >> >> this. This is no different from a hot-unplug, in fact I can't see how >> >> >> the audio driver could even detect whether there's been a hotplug >> >> or >> >> >> not >> >> >> when there's a codec disable/enable. >> >> > >> >> > Yes, it will trigger an interrupt to audio driver when unplug >> >> > and another interrupt for hotplug. But from audio driver, >> >> > we will not stop the playing and resume the playing based >> >> > on the hotplug or modeset. The audio is always playing during >> >> > the hotplug/modeset. >> >> >> >> But the whole display, and consequently ELD, might have changed >> >> during >> >> the hotplug, why do you assume you can just keep playing?! The >> >> display >> >> might even have changed from HDMI to DP or vice versa. >> > >> > The eld info changing will not impact the audio playing. >> > Actually, you can image the monitor as a digital speaker, just >> > like the headphone to the analog audio. Unplug the speaker >> > will not impact on the audio playing. Of course , there is a >> > little difference, when monitor hotplug, in the interrupt, >> > we may change the codec configuration dynamically. >> > >> > And audio driver supply the mechanism to stop the >> > audio playing when hotplug if the HW requires. >> > >> >> >> >> We've also been putting a lot of effort into not depending on previous >> >> state when enabling the outputs, for more reliability. We generally >> >> don't do partial changes, we disable everything and then enable >> >> again. And now you're suggesting we look at some register which for all >> >> we know may have been valid for some other display? >> > >> > In the patch, it will not depend on previous state, I think. We >> > read the register value which is based on the state after modeset. >> >> Okay, let's have the patches cleaned up and see. It'll be easier and >> quicker to solicit more review on that than this expanding thread. > > It sounds like we actually need to ping the audio side _before_ we do the Do you mean "read _HSW_AUD_STR_DESC_*" by "ping the audio side" above? Ja
Re: [Intel-gfx] [PATCH v2] drm/i915: clflush on pin_to_display after pwrite to UC bo in LLC
On Tue, Aug 11, 2015 at 06:12:04PM +0100, Chris Wilson wrote: > On Tue, Aug 11, 2015 at 07:47:10PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently we don't clflush on pin_to_display if the bo is already > > UC/WT and is not in the CPU write domain. This causes problems with > > pwrite since pwrite doesn't change the write domain, and it avoids > > clflushing on UC/WT buffers on LLC platforms unless the buffer is > > currently being scanned out. > > > > Fix the problem by marking the cache dirty and adjusting > > i915_gem_object_set_cache_level() to clflush when the cache is dirty > > even if the cache_level doesn't change. > > > > My last attempt [1] at fixing this via write domain frobbing was shot > > down, but now with the cache_dirty flag we can do things in a nicer way. > > > > [1] > > http://lists.freedesktop.org/archives/intel-gfx/2014-November/055390.html > > > > v2: Drop the I915_CACHE_NONE/WT checks from pwrite > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86422 > > Testcase: igt/kms_pwrite_crc > > Testcase: igt/gem_pwrite_snooped > > Signed-off-by: Ville Syrjälä > Reviewed-by: Chris Wilson Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 v2 5/5] tests: make drm_read platform agnostic
On Tue, Aug 11, 2015 at 11:59:16AM -0400, Micah Fedke wrote:
>
> Update the drm_read test to operate on any platform to demonstrate the use of
> drm_open_driver(OPEN_ANY_GPU).
>
> To work on exynos, the event generation code is converted to use the new CRTC
> selection API for vblank. The first valid crtc is selected at fixture-time.
>
> pipe0_enabled() is updated to use the drmMode* wrapper functions instead of
> direct ioctls, and the unnecessary, intel-specific pipe<->crtc mapping ioctl
> is
> dropped.
>
> With these updates in place, drm_read can run successfully on intel and
> exynos.
> Tested on ivb and peach-pi, respectively.
>
> Signed-off-by: Micah Fedke
drm_read isn't the greatest test since it implicitly relies upon fbcon
enabling the screens for us. I think that should be fixed first.
> ---
> tests/drm_read.c | 87
>
> 1 file changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/tests/drm_read.c b/tests/drm_read.c
> index fdaf126..38fde26 100644
> --- a/tests/drm_read.c
> +++ b/tests/drm_read.c
> @@ -45,10 +45,15 @@
> #include "drm.h"
> #include "ioctl_wrappers.h"
> #include "drmtest.h"
> +#include "igt_core.h"
> #include "igt_aux.h"
> +#include "igt_kms.h"
>
> IGT_TEST_DESCRIPTION("Call read(drm) and see if it behaves.");
>
> +static drmModeRes *resources;
> +static int crtc_idx;
> +
> static void sighandler(int sig)
> {
> }
> @@ -61,16 +66,19 @@ static void assert_empty(int fd)
>
> static void generate_event(int fd)
> {
> - union drm_wait_vblank vbl;
> + drmVBlank wait_vbl;
> + unsigned crtc_idx_mask;
> + memset(&wait_vbl, 0, sizeof(wait_vbl));
>
> - /* We require that pipe 0 is running */
> + crtc_idx_mask = crtc_idx << DRM_VBLANK_HIGH_CRTC_SHIFT;
> + igt_assert(!(crtc_idx_mask & ~DRM_VBLANK_HIGH_CRTC_MASK));
>
> - vbl.request.type =
> - DRM_VBLANK_RELATIVE |
> - DRM_VBLANK_EVENT;
> - vbl.request.sequence = 0;
> + wait_vbl.request.type = crtc_idx_mask;
> + wait_vbl.request.type |= DRM_VBLANK_RELATIVE;
> + wait_vbl.request.type |= DRM_VBLANK_EVENT;
> + wait_vbl.request.sequence = 1;
>
> - do_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, &vbl);
> + igt_assert(!drmWaitVBlank(fd, &wait_vbl));
> }
>
> static void wait_for_event(int fd)
> @@ -154,44 +162,27 @@ static void test_short_buffer(int in, int nonblock)
>
> static int pipe0_enabled(int fd)
> {
> - struct drm_mode_card_res res;
> - uint32_t crtcs[32];
> - int i;
> + drmModeRes *res;
> + drmModeCrtc *crtc;
> + int ret;
>
> /* We assume we can generate events on pipe 0. So we have better
>* make sure that is running!
>*/
>
> - memset(&res, 0, sizeof(res));
> - res.count_crtcs = 32;
> - res.crtc_id_ptr = (uintptr_t)crtcs;
> -
> - if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res))
> - return 0;
> -
> - if (res.count_crtcs > 32)
> + res = drmModeGetResources(fd);
> + igt_assert(res);
> + crtc = drmModeGetCrtc(fd, res->crtcs[crtc_idx]);
> + if (!crtc){
> return 0;
> + }
>
> - for (i = 0; i < res.count_crtcs; i++) {
> - struct drm_i915_get_pipe_from_crtc_id get_pipe;
> - struct drm_mode_crtc mode;
> -
> - memset(&get_pipe, 0, sizeof(get_pipe));
> - memset(&mode, 0, sizeof(mode));
> -
> - mode.crtc_id = crtcs[i];
> -
> - get_pipe.pipe = -1;
> - get_pipe.crtc_id = mode.crtc_id;
> - drmIoctl(fd, DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID, &get_pipe);
> - if (get_pipe.pipe)
> - continue;
> + ret = crtc->mode_valid && crtc->mode.clock;
>
> - drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, &mode);
> - return mode.mode_valid && mode.mode.clock;
> - }
> + drmModeFreeCrtc(crtc);
> + drmModeFreeResources(res);
>
> - return 0;
> + return ret;
> }
>
> igt_main
> @@ -202,8 +193,30 @@ igt_main
> siginterrupt(SIGALRM, 1);
>
> igt_fixture {
> - fd = drm_open_driver_master(DRIVER_INTEL);
> + struct kmstest_connector_config config;
> + int i, n;
> +
> + fd = drm_open_driver_master(OPEN_ANY_GPU);
> + igt_enable_connectors(fd);
> + kmstest_set_vt_graphics_mode();
Because in general we don't want fbcon to do things behind our back, like
suspending the display.
-Daniel
> +
> igt_require(pipe0_enabled(fd));
> +
> + resources = drmModeGetResources(fd);
> + igt_assert(resources);
> +
> + for (i = 0; i < resources->count_connectors; i++) {
> + for (n = 0; n < resources->count_crtcs; n++) {
> + //use the first connector config we find
> + if(kmstest_get_connector_config(fd,
> resources->connectors[i],
>
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Use CPU mapping for userspace dma-buf mmap()
On Tue, Aug 11, 2015 at 11:20:46PM +0100, Chris Wilson wrote:
> On Tue, Aug 11, 2015 at 05:59:23PM -0300, Tiago Vignatti wrote:
> > Userspace is the one in charge of flush CPU by wrapping mmap with
> > begin{,end}_cpu_access.
> >
> > v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix
> > return
> > before transferring ownership when mmap fails.
> > v3: Fix return values.
> >
> > Signed-off-by: Tiago Vignatti
> > ---
> > drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18 +-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > index 8447ba4..8b87c86 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > @@ -193,7 +193,23 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf
> > *dma_buf, unsigned long page_n
> >
> > static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
> > vm_area_struct *vma)
> > {
> > - return -EINVAL;
> > + struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> > + int ret;
> > +
> > + if (obj->base.size < vma->vm_end - vma->vm_start)
> > + return -EINVAL;
> > +
> > + if (WARN_ON(!obj->base.filp))
> > + return -ENODEV;
>
> That's user triggerable, mmap(dma_buf_export(userptr)), so remove the
Sounds like we need another testcase here ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915:gen9: Add WA for disable gather at set shader bit
This WA doesn't have a name. According to WA ID 0555 in spec, driver need to
reset disable gather at set shader bit in per ctx WA batch. It is to be noted
that the default value is already '0' for this bit but we still need to apply
this WA because userspace may set it. If userspace really need it to be set
then they need to do in every batch.
Cc: Ben Widawsky
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7456bd2..d60a510 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5834,6 +5834,7 @@ enum skl_disp_power_wells {
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1<<10) | (1<<26))
# define GEN9_RHWO_OPTIMIZATION_DISABLE(1<<14)
#define COMMON_SLICE_CHICKEN2 0x7014
+#define GEN9_DISABLE_GATHER_SET_SHADER_SLICE (1<<12)
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1<<0)
#define HIZ_CHICKEN0x7018
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 5559ed9..e79be4c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1305,6 +1305,15 @@ static int gen9_init_perctx_bb(struct intel_engine_cs
*ring,
struct drm_device *dev = ring->dev;
uint32_t index = wa_ctx_start(wa_ctx, *offset, CACHELINE_DWORDS);
+ /* WaNoName:skl,bxt
+* This WA has no name, WA ID 0555 in spec says, driver needs to reset
+* "disable gather at set shader slice" bit in per ctx batch
+*/
+ wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(1));
+ wa_ctx_emit(batch, index, COMMON_SLICE_CHICKEN2);
+ wa_ctx_emit(batch, index,
+ _MASKED_BIT_DISABLE(GEN9_DISABLE_GATHER_SET_SHADER_SLICE));
+
/* WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken:skl,bxt */
if ((IS_SKYLAKE(dev) && (INTEL_REVID(dev) <= SKL_REVID_B0)) ||
(IS_BROXTON(dev) && (INTEL_REVID(dev) == BXT_REVID_A0))) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/8] drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters for DSC
On Wed, Aug 12, 2015 at 03:23:48PM +0530, vikas.korj...@intel.com wrote:
> From: vkorjani
>
> This patch adds code to initialize Picture Parameter set (PPS)
> data structure for DSC.
> DSC is enabled than the bitrate should be calculated using the
> formula pixel_clock * bits_per_pixel / lane_count, where
> bits_per_pixel can be 8bpp, 10bpp, 12bpp.
> value of bits_per_pixel is available in step of 1/16 in
> pps date structure.
> DPHY parameters are computed based on data rate calculated
> as per bits_per_pixel provided in pps data structure.
>
> Signed-off-by: vkorjani
> Signed-off-by: Yogesh Mohan Marimuthu
> ---
> drivers/gpu/drm/i915/intel_dsi.h |5 +
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 11 +++
> drivers/gpu/drm/i915/intel_dsi_pll.c | 24
> 3 files changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 24fc550..699f995 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -96,6 +96,11 @@ struct intel_dsi {
> u16 panel_on_delay;
> u16 panel_off_delay;
> u16 panel_pwr_cycle_delay;
> +
> + /*DSC Support */
> + u8 dsc_enable;
> + struct vesa_dsc_pps_data pps_data;
> + u8 dsc_bpp;
> };
>
> struct intel_dsi_host {
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index a5e99ac..f893d37 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -413,6 +413,17 @@ struct drm_panel *vbt_panel_init(struct intel_dsi
> *intel_dsi, u16 panel_id)
> bits_per_pixel = 18;
> else if (intel_dsi->pixel_format == VID_MODE_FORMAT_RGB565)
> bits_per_pixel = 16;
> + else if (intel_dsi->pixel_format == VID_MODE_FORMAT_COMPRESSED &&
> + dev_priv->vbt.dsc_param.dsc_support) {
> + intel_dsi->dsc_enable = true;
> + intel_dsi->dsc_bpp =
> + (intel_dsi->pps_data.bits_per_pixel / 16);
> + bits_per_pixel = intel_dsi->dsc_bpp;
> + intel_dsi->pps_data =
> + dev_priv->vbt.dsc_param.pps_data;
> + /*TODO If PPS not available in VBT compute PPS
> + * from capablity parameter set in vbt */
We don't seem to feed back the dsi bits_per_pixel information into our
computation of pipe_config->pipe_bpp. We probably need to fix that to
actually be able to drive the higher bpc modes ...
Wiring this up correctly should probably be a prep patch.
Also do we have to compute bpp differently for dsc? Can't we just store
bits_per_pixel somewhere?
-Daniel
> + }
>
> intel_dsi->operation_mode = mipi_config->is_cmd_mode;
> intel_dsi->video_mode_format = mipi_config->video_transfer_mode;
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index b647f13..38c9433 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -143,10 +143,17 @@ static u32 dsi_rr_formula(const struct drm_display_mode
> *mode,
> #else
>
> /* Get DSI clock from pixel clock */
> -static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
> +static u32 dsi_clk_from_pclk(struct intel_encoder *encoder,
> + u32 pclk, int pixel_format, int lane_count)
> {
> + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> u32 dsi_clk_khz;
> - u32 bpp = dsi_pixel_format_bpp(pixel_format);
> + u32 bpp;
> +
> + if (intel_dsi->dsc_enable)
> + bpp = intel_dsi->dsc_bpp;
> + else
> + bpp = dsi_pixel_format_bpp(pixel_format);
>
> /* DSI data rate = pixel clock * bits per pixel / lane count
> pixel clock is converted from KHz to Hz */
> @@ -223,8 +230,8 @@ static void vlv_configure_dsi_pll(struct intel_encoder
> *encoder)
> struct dsi_mnp dsi_mnp;
> u32 dsi_clk;
>
> - dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
> - intel_dsi->lane_count);
> + dsi_clk = dsi_clk_from_pclk(encoder, intel_dsi->pclk,
> + intel_dsi->pixel_format, intel_dsi->lane_count);
>
> ret = dsi_calc_mnp(dev_priv, &dsi_mnp, dsi_clk);
> if (ret) {
> @@ -410,8 +417,9 @@ u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int
> pipe_bpp)
>
> dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
>
> - /* pixel_format and pipe_bpp should agree */
> - assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
> + /* pixel_format and pipe_bpp should agree if DSC is not enabled */
> + if (!intel_dsi->dsc_enable)
> + assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
>
> pclk = DIV_ROUND_CLOSEST(dsi_clk * intel_dsi->lane_count, pipe_bpp);
>
> @@ -475,8 +483,8 @@
Re: [Intel-gfx] [RFC 0/8] *** DSC Inital Design RFC ***
jn Wed, Aug 12, 2015 at 03:23:45PM +0530, vikas.korj...@intel.com wrote: > From: vkorjani > > s RFC is for feature Display Stream Compression (DSC) for BXT, > It is a VESA defined standard to compress and decompress image in display > streams in a link independent manner. Some of the basic requirements of > the standard are to support higher resolution on a given display link > with fewer lanes or lower rate. > > DSC is architected to work in current Intel Display Engine design > without modification how current display pipeline works. DSC hardware > as per HAS is in b/n port and MIPI DSI controller. so most of the > changes are at port level. > > At begining of frame display can start sending valid pixels to DSC > at normal rate, DSC start compressing this image according to > pps parameters programmed already to 8bpp, 10bpp, 12bpp. > > /*This bitstream is temprory stored in output buffer and sent as byte > stream to DSI controller as soon as it is valid. > */ Where exactly is that bistream stored? In some on-chip buffer which is hidden from us, or do we need to allocate some memory for this? I din't spot anything of the latter form ... -Daniel > Following are the set of patches as per initial design in HLD, one > can refer DSC HLD if more details about the changes is required. > > Tested these patches on fulsim simulation enviornment. > > > vkorjani (8): > drm/915/bxt: Adding DSC VBT parameter and PPS structures > drm/i915/bxt: Adding registers to support DSC > drm/i915/bxt: Init PPS, Calculate DSI frequency and DPHY parameters > for DSC > drm/i915/bxt: MIPI DSI Register Programming for DSC > drm/i915/bxt: Program MIPI_DPI_RESOLUTION for DSC > drm/i915/bxt: Enable/Disable DSC and programme PPS. > drm: Add support for pps and compression mode command packet > drm/i915/bxt: Send PPS packet and compression mode command packet > > drivers/gpu/drm/drm_mipi_dsi.c | 29 +++ > drivers/gpu/drm/i915/i915_drv.h|2 + > drivers/gpu/drm/i915/i915_reg.h| 126 + > drivers/gpu/drm/i915/intel_bios.h | 74 > drivers/gpu/drm/i915/intel_dsi.c | 274 > ++-- > drivers/gpu/drm/i915/intel_dsi.h |5 + > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 23 +++ > drivers/gpu/drm/i915/intel_dsi_pll.c | 24 ++- > include/drm/drm_mipi_dsi.h |4 +- > include/video/mipi_display.h |3 + > 10 files changed, 539 insertions(+), 25 deletions(-) > > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Wed, 12 Aug 2015, Daniel Vetter wrote:
> On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote:
>> Depending on the VBT BDB version the maximum size
>> can be up to 38 bytes.
>>
>> This fix increases the maximum of the VBT expected size
>> from 33 bytes to 38 bytes and by doing so cures the kernel
>> hang on BSW box.
>>
>> Signed-off-by: Mika Kahola
>
> We already have David's patch in -fixes, how does this relate? How does it
> blow up? Is this a regression? If so which commit created it? Where's the
> bugzilla link from QA?
There's no bugzilla link from QA because Mika found the bug and I told
him to just send the patch.
BR,
Jani.
> -Daniel
>
>> ---
>> drivers/gpu/drm/i915/intel_bios.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index f7ad6a5..788463d 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -246,7 +246,7 @@ struct common_child_dev_config {
>> union child_device_config {
>> /* This one is safe to be used anywhere, but the code should still check
>> * the BDB version. */
>> -u8 raw[33];
>> +u8 raw[38];
>> /* This one should only be kept for legacy code. */
>> struct old_child_dev_config old;
>> /* This one should also be safe to use anywhere, even without version
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> 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 v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: > >> On Wed, 12 Aug 2015, "Yang, Libin" wrote: > >> > Hi Jani, > >> > > >> >> -Original Message- > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> Sent: Tuesday, August 11, 2015 4:14 PM > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> >> modeset > >> >> > >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> > Hi Jani, > >> >> > > >> >> >> -Original Message- > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> Sent: Tuesday, August 11, 2015 3:14 PM > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel- > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > >> >> >> modeset > >> >> >> > >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" wrote: > >> >> >> > Hi Jani, > >> >> >> > > >> >> >> > Thanks for careful reviewing for all the patches, please > >> >> >> > see my comments. > >> >> >> > > >> >> >> >> -Original Message- > >> >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >> >> >> >> Sent: Monday, August 10, 2015 8:10 PM > >> >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > >> >> >> >> intel- > >> >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > >> >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS > >> >> in > >> >> >> >> modeset > >> >> >> >> > >> >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > >> >> >> >> > From: Libin Yang > >> >> >> >> > > >> >> >> >> > When modeset occurs and the TMDS frequency is set to some > >> >> >> >> > speical value, the N/CTS need to be set manually if audio > >> >> >> >> > is playing. > >> >> >> >> > >> >> >> >> When modeset occurs, we disable everything, and then re-enable > >> >> >> >> everything, and notify the audio driver every step of the way. > >> >> >> >> IIUC > >> >> >> >> there should be no audio playing across the modeset, and when > >> >> the > >> >> >> >> modeset is complete and we've set the valid ELD, the audio driver > >> >> >> >> should > >> >> >> >> call the callback from the earlier patches to set the correct > >> >> >> >> audio > >> >> >> >> rate. > >> >> >> >> > >> >> >> >> Why is this patch needed? Please enlighten me. > >> >> >> > > >> >> >> > Please image this scenario: when audio is playing, the gfx driver > >> >> >> > does the modeset. In this situation, after modeset, audio driver > >> >> >> > will do nothing and continue playing. And audio driver will not > >> >> >> > call > >> >> >> > set_ncts. > >> >> >> > >> >> >> Why does the audio driver not do anything here? Whenever there's > >> >> a > >> >> >> modeset, the graphics driver will disable audio and invalidate the > >> >> ELD, > >> >> >> which should cause an interrupt to notify the audio driver about > >> >> >> this. This is no different from a hot-unplug, in fact I can't see how > >> >> >> the audio driver could even detect whether there's been a hotplug > >> >> or > >> >> >> not > >> >> >> when there's a codec disable/enable. > >> >> > > >> >> > Yes, it will trigger an interrupt to audio driver when unplug > >> >> > and another interrupt for hotplug. But from audio driver, > >> >> > we will not stop the playing and resume the playing based > >> >> > on the hotplug or modeset. The audio is always playing during > >> >> > the hotplug/modeset. > >> >> > >> >> But the whole display, and consequently ELD, might have changed > >> >> during > >> >> the hotplug, why do you assume you can just keep playing?! The > >> >> display > >> >> might even have changed from HDMI to DP or vice versa. > >> > > >> > The eld info changing will not impact the audio playing. > >> > Actually, you can image the monitor as a digital speaker, just > >> > like the headphone to the analog audio. Unplug the speaker > >> > will not impact on the audio playing. Of course , there is a > >> > little difference, when monitor hotplug, in the interrupt, > >> > we may change the codec configuration dynamically. > >> > > >> > And audio driver supply the mechanism to stop the > >> > audio playing when hotplug if the HW requires. > >> > > >> >> > >> >> We've also been putting a lot of effort into not depending on previous > >> >> state when enabling the outputs, for more reliability. We generally > >> >> don't do partial changes, we disable everything and then enable > >> >> again. And now you're suggesting we look at some register which for all > >> >> we know may have been valid for some other display? > >> > > >> > In the patch, it will not depend on previous state, I think. We > >> > read the register value which is based
Re: [Intel-gfx] [BUGFIX] drm/i915: Fix for VBT expected size
On Wed, Aug 12, 2015 at 04:42:53PM +0300, Jani Nikula wrote: > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > On Tue, Aug 11, 2015 at 04:49:33PM +0300, Mika Kahola wrote: > >> Depending on the VBT BDB version the maximum size > >> can be up to 38 bytes. > >> > >> This fix increases the maximum of the VBT expected size > >> from 33 bytes to 38 bytes and by doing so cures the kernel > >> hang on BSW box. > >> > >> Signed-off-by: Mika Kahola > > > > We already have David's patch in -fixes, how does this relate? How does it > > blow up? Is this a regression? If so which commit created it? Where's the > > bugzilla link from QA? > > There's no bugzilla link from QA because Mika found the bug and I told > him to just send the patch. so bsw doesn't boot and QA didn't notice? That's fail too, just different kind of fail ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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: Retry port as HDMI if dp_is_edp turns out to be false
On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:
> We follow the VBT as to whether a DDI port is used for eDP and if so, do
> not attach a HDMI encoder to it. However there are machines for which
> the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
> Furthermore, on those machines the HDMI is connected to that DDI port
> but we ignore it.
>
> If we reorder our port initialisation to try the eDP setup first and
> if that fails we can treat it as a normal DP port along with a HDMI
> output. To accomplish this, we have to delay registering the DP
> connector/encoder until after we establish its final type.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88331
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c | 27
> drivers/gpu/drm/i915/intel_dp.c | 127
> +--
> drivers/gpu/drm/i915/intel_drv.h | 6 +-
> 3 files changed, 79 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0bcd1b1aba4f..aab8dfd1f8a5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_encoder *encoder;
> - bool dpd_is_edp = false;
>
> intel_lvds_init(dev);
>
> @@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct drm_device
> *dev)
> intel_ddi_init(dev, PORT_D);
> } else if (HAS_PCH_SPLIT(dev)) {
> int found;
> - dpd_is_edp = intel_dp_is_edp(dev, PORT_D);
>
> if (has_edp_a(dev))
> intel_dp_init(dev, DP_A, PORT_A);
>
> + found = 0;
> + /* PCH SDVOB multiplex with HDMIB */
> if (I915_READ(PCH_HDMIB) & SDVO_DETECTED) {
> - /* PCH SDVOB multiplex with HDMIB */
> found = intel_sdvo_init(dev, PCH_SDVOB, true);
> if (!found)
> intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
> - if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
> - intel_dp_init(dev, PCH_DP_B, PORT_B);
> }
> + if (!found && I915_READ(PCH_DP_B) & DP_DETECTED)
> + intel_dp_init(dev, PCH_DP_B, PORT_B);
>
> - if (I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
> -
> - if (!dpd_is_edp && I915_READ(PCH_HDMID) & SDVO_DETECTED)
> - intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> -
> + found = 0;
> if (I915_READ(PCH_DP_C) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_C, PORT_C);
> + found = intel_dp_init(dev, PCH_DP_C, PORT_C);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMIC) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
>
> + found = 0;
> if (I915_READ(PCH_DP_D) & DP_DETECTED)
> - intel_dp_init(dev, PCH_DP_D, PORT_D);
> + found = intel_dp_init(dev, PCH_DP_D, PORT_D);
> + if (found != DRM_MODE_CONNECTOR_eDP &&
> + I915_READ(PCH_HDMID) & SDVO_DETECTED)
> + intel_hdmi_init(dev, PCH_HDMID, PORT_D);
> } else if (IS_VALLEYVIEW(dev)) {
> /*
>* The DP_DETECTED bit is the latched state of the DDC
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1e64a8c1e7cb..8adf500f3989 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1031,14 +1031,13 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> return ret;
> }
>
> -static void
> +static int
> intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector
> *connector)
> {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> enum port port = intel_dig_port->port;
> const char *name = NULL;
> - int ret;
>
> switch (port) {
> case PORT_A:
> @@ -1080,20 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct
> intel_connector *connector)
> DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> connector->base.kdev->kobj.name);
>
> - ret = drm_dp_aux_register(&intel_dp->aux);
> - if (ret < 0) {
> - DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
> - name, ret);
> - return;
> - }
> -
> - ret = sysfs_create_link(&connector->base.kdev->kobj,
> -
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add eDP intermediate frequencies for CHV"
On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote: > On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote: > > > > > > On 8/12/2015 5:02 PM, Ville Syrjälä wrote: > > > On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote: > > >> From: "Thulasimani,Sivakumar" > > >> > > >> This reverts > > >> commit fe51bfb95c996733150c44d21e1c9f4b6322a326. > > >> Author: Ville Syrjälä > > >> Date: Thu Mar 12 17:10:38 2015 +0200 > > >> > > >> CHV does not support intermediate frequencies so reverting the > > >> patch that added it in the first place > > > My docs still say it does. Is there some undocumented problem with the > > > PLL or is this just a marketing decision? > > I don't think so, i too have just one document that shows the phy values > > for each of > > the link rates but have not found any where else to say it is supported . > > Display cluster HAS says they're supported. And since the spreadsheet > has them all in green I assume someone actually figured that they ought > to work. > > > Also this is not tested by anyone including us from product team so i > > highly doubt > > it will even work. > > Well if no one has tested them I guess we shouldn't try to use them. Not > a big loss in any case I suppose. > > So based on that reasoning I can give an ack for this patch: > Acked-by: Ville Syrjälä > > > > > regarding HBR2, it was supposed to land on a future stepping that never > > happened > > so it is not supported at all. > > Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. > Apart > from that there isn't much else to go by. Excepth the training pattern 3 > support, but now that I look again the new bit for that has disappeared > from the DP register in the spec. Or maybe I was looking at the k0 spec > when I added it. It's still in the k0 spec but as you say that's been > nuked. > > In light of this, I think dropping HBR2 is reasonable. HBR is anyway > enough for 4k@30 with 4 lanes, so it's not like we really need HBR2. > > And could you also cook up a patch to kill the training pattern 3 > support for CHV? Should be mostly a revert of my original patch that > added it, but you probably need to adjust the use_tps3 condition a bit > too. Can we please grill the people responsible for this docs mess some more? Patch itself is for Jani. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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: Do not check or a stalled pageflip prior to it being queued
On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote: > When we queue the command or operation to change the scanout address, we > mark the flip as in progress. We can use this flag to prevent us from > checking for a stalled flip prior to its existence! > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/intel_display.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index aab8dfd1f8a5..edc7d4a7c9de 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11248,6 +11248,9 @@ static bool __intel_pageflip_stall_check(struct > drm_device *dev, > if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) > return true; > > + if (atomic_read(&work->pending) < INTEL_FLIP_PENDING) > + return false; > + unpin_work is assigned and the lock dropped before the flip is marked as INTEL_FLIP_PENDING. Makes sense. Reviewed-by: Ville Syrjälä > if (!work->enable_stall_check) > return false; > > -- > 2.5.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false
On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote: > > - /* > > -* For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but > > -* for DP the encoder type can be set by the caller to > > -* INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it. > > -*/ > > - if (type == DRM_MODE_CONNECTOR_eDP) > > - intel_encoder->type = INTEL_OUTPUT_EDP; > > aux (and IIRC pps setup on vlv/chv) needs is_edp() to work. So I think > this would break stuff. Hmm, I was hoping that all the additional setup we do in init for edp would be enough for it to use any and all sidebands as necessary. The fallout will be that we simply cannot reuse the false eDP link as a plain DP and just establish one HDMI connector for the port. Or maybe it is still recoverable? -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 v4 4/4] drm/i915: set proper N/CTS in modeset
On Wed, 12 Aug 2015, Daniel Vetter wrote: > On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: >> On Wed, 12 Aug 2015, Daniel Vetter wrote: >> > It sounds like we actually need to ping the audio side _before_ we do the >> >> Do you mean "read _HSW_AUD_STR_DESC_*" by "ping the audio side" above? > > No, I mean call into snd-hda-intel before we do the modeset to ask it for > what it actually wants to have set up. At least it feels a bit like only > reacting to a modeset after it's done leads to confusion. Or maybe we just > need to update the register values we want at compute_time instead of > doing rwm fun ... > > Pure gut feeling comment, I didn't look into details ;-) The audio driver calls us, not vice versa... Jani. -- 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 00/22] Enable gpu switching on the MacBook Pro
On Tue, Aug 11, 2015 at 12:29:17PM +0200, Lukas Wunner wrote: > This is a follow-up to the v1 posted in April: > http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html > > > Patches 1 - 17 enable GPU switching on the pre-retina MacBook Pro. > These were tested successfully by multiple people and solve two > tickets in Bugzilla: > https://bugzilla.kernel.org/show_bug.cgi?id=88861 > https://bugs.freedesktop.org/show_bug.cgi?id=61115 > > Patches 18 - 22 are a preview of how we're tackling retina support. > Those are marked experimental and are NOT ready to be merged yet. > Feedback on them is welcome. > > The patches are based on drm-next. > > They were tested on the following hardware (thanks a lot everyone!): > Tested-by: Paul Hordiienko > [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] > Tested-by: William Brown > [MBP 8,2 2011 intel SNB + amd turks pre-retina] > Tested-by: Lukas Wunner > [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] > Tested-by: Bruno Bierbaumer > [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] > > > What's new: > > * By default the MBP boots with the display switched to the discrete GPU > but it can be forced to the integrated GPU with an EFI boot variable. > Here's a handy tool for that: https://github.com/0xbb/gpu-switch > v1 didn't work in this configuration, v2 does. > > * Reprobing if the inactive GPU initializes before the apple-gmux module: > v1 used Matthew Garrett's approach of adding a driver callback. > v2 simply generates a hotplug event instead. nouveau polls its outputs > every 10 seconds so we want it to poll immediately once apple-gmux > registers. That is achieved by the hotplug event. The i915 driver is > changed to behave identically to nouveau. (Right now it deletes LVDS > and eDP connectors from the mode configuration if they can't be probed, > deeming them to be ghosts.) I thought -EDEFERREDPROBE is what we should be using if drivers don't get loaded in the right order? Hand-rolling depency avoidance stuff is imo a horrible idea. > * Framebuffer recreation if the inactive GPU initializes before the > apple-gmux module (i.e. discarding the default 1024x768 fb and replacing > with a new one with the actual panel resolution): v1 only supported this > for i915, v2 has a generic solution which works with nouveau and radeon > as well. (Necessary if the discrete GPU is forced to be the inactive one > on boot via the EFI variable.) Would completely remove the need for this ;-) > * Generally lots of rough edges were smoothed to hopefully make the > patches more suitable for merging. E.g. there's a bug in i915 where > the SSC status set by BIOS is preserved too late and v1 only contained > a workaround, whereas v2 contains a proper fix in a separate commit. > > > The long journey towards retina support: > > The pixel clock required for retina resolution is not supported by LVDS > (which was used on pre-retinas), necessitating eDP instead. Problem is, > the gmux register which switches the DDC lines on pre-retinas doesn't > switch the AUX channel on retinas. Disassembling the OS X driver revealed > that the gmux in retina MBPs gained an additional register 0x7f which gets > written to when setting up the eDP configuration. There was some hope that > this might switch the AUX channel. Alas, we tried writing various values > to that register but were unable to get the inactive GPU to talk to the > panel. The purpose of register 0x7f remains a mystery. > > Teardowns of the first generation retina MBP name the NXP CBTL06142 and > TI HD3SS212 as multiplexers and according to the data sheets I've found, > neither supports switching the AUX channel separately from the main link. > > Matthew Garrett had the idea of having the active GPU stash the EDID and > the first 8 bytes of the DPCD (receiver capabilities) and letting the > inactive GPU retrieve that data. I rebased and rewrote his patches and > got everything working, only to discover that the drivers are unhappy > with just 8 bytes of DPCD. They need full access to the DPCD to set up > their outputs. We could stash the entire DPCD but some parts of it are > mutable so the stashed data may become stale when the active GPU performs > writes to the DPCD. > > So I had the idea of using the active GPU as a proxy to talk to the panel, > thus emulating switching of the AUX channel in software. We can leverage > the struct drm_dp_aux and i2c_adapter (for DDC) to achieve this, swapping > the inactive GPU's structs with those of the active GPU on the fly. > That approach is implemented in patches 18 - 22 but there are still some > driver issues that I'm debugging. The current status as per the latest > logs Bruno sent me is that i915 rejects the mode retrieved via proxying > with CLOCK_HIGH and nouveau aborts link training halfway through. > Bottom line is that it's not yet working but we're getting closer.
Re: [Intel-gfx] [PATCH 1/2 v2 addendum] drm/i915: Allow parsing of variable size child device entries from VBT
On Wed, 12 Aug 2015, David Weinehall wrote:
> Some more fixup is needed; the bits from Antti's patch
> that actually expanded the struct to fully fit the newer
> versions of the child_device_config was part of the second
> patch; since that patch hasn't been merged yet we need this bit:
>
> This applies on top of the patch you already merged
> (the Iboost patch will need corresponding adjustment to
> remove the changes I split out):
>
> Expand common_child_dev_config to be able to fit all information
> defined by the latest VBT specification.
>
> Signed-off-by: David Weinehall
> CC: Antti Koskipaa
> ---
> intel_bios.c |7 ++-
> intel_bios.h |4
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 990acc20771a..40e2cc4e7419 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> DRM_DEBUG_KMS("No general definition block is found, no devices
> defined.\n");
> return;
> }
> + /* Remember to keep this in sync with child_device_config;
> + * whenever a new feature is added to BDB that causes that
> + * struct to grow this needs to be updated too
> + */
> if (bdb->version < 195) {
> expected_size = 33;
> } else if (bdb->version == 195) {
> @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> }
>
> if (expected_size > sizeof(*p_child)) {
> - DRM_ERROR("child_device_config cannot fit in p_child\n");
> + DRM_ERROR("child_device_config (size %u) cannot fit in p_child
> (size %u); bdb->version: %u\n",
> + expected_size, sizeof(*p_child), bdb->version);
drivers/gpu/drm/i915/intel_bios.c: In function ‘parse_device_mapping’:
drivers/gpu/drm/i915/intel_bios.c:1058:3: warning: format ‘%u’ expects argument
of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
DRM_ERROR("child_device_config (size %u) cannot fit in p_child (size %u);
bdb->version: %u\n",
^
CC [M] drivers/gpu/drm/i915/intel_fifo_underrun.o
> return;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index f7ad6a585129..71cb96f77870 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -239,6 +239,10 @@ struct common_child_dev_config {
> u8 not_common2[2];
> u8 ddc_pin;
> u16 edid_ptr;
> + u8 obsolete;
> + u8 flags_1;
> + u8 not_common3[13];
> + u8 iboost_level;
> } __packed;
>
> /* This field changes depending on the BDB version, so the most reliable way
> to
> ___
> 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 6/6] drm/i915: Enable HDMI on DDI-E
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 7093 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 315/315 315/315 IVB 336/336 336/336 BYT -2 283/283 281/283 HSW 378/378 378/378 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_persistent_relocs@interruptible PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: Add ioctls to allow userspace to flush
Hi Tiago,
Thanks for the patch!
On 12 August 2015 at 02:29, Tiago Vignatti wrote:
> From: Daniel Vetter
>
> FIXME: Update kerneldoc for begin/end to make it clear that those are
> for mmap too.
I think if we're going to add this patch upstream, atleast the FIXMEs
should be fixed.
>
> Open: Do we need a special indication that the begin/end is from
> userspace mmap and not from kernel mmap?
>
> There's also the question already about kernel internal users - vmap
> and kmap interfaces are much different ... We might need to add a
> mapping enum to the begin/end dma-buf functions.
Also, this looks like another thing that could be added right now
while we're adding this change.
>
> v2 (Tiago): Fix header file type names (u64 -> __u64)
>
> Signed-off-by: Daniel Vetter
> Signed-off-by: Tiago Vignatti
> ---
> drivers/dma-buf/dma-buf.c| 47
>
> include/uapi/linux/dma-buf.h | 39
> 2 files changed, 86 insertions(+)
> create mode 100644 include/uapi/linux/dma-buf.h
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 155c146..4820d61 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -34,6 +34,8 @@
> #include
> #include
>
> +#include
> +
> static inline int is_dma_buf_file(struct file *);
>
> struct dma_buf_list {
> @@ -251,11 +253,56 @@ out:
> return events;
> }
>
> +static long dma_buf_ioctl(struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct dma_buf *dmabuf;
> + struct dma_buf_sync sync;
> + enum dma_data_direction direction;
> +
> + dmabuf = file->private_data;
> +
> + if (!is_dma_buf_file(file))
> + return -EINVAL;
> +
> + switch (cmd) {
> + case DMA_BUF_IOCTL_SYNC:
> + if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
> + return -EFAULT;
> +
> + if (sync.flags & DMA_BUF_SYNC_RW)
> + direction = DMA_BIDIRECTIONAL;
> + else if (sync.flags & DMA_BUF_SYNC_READ)
> + direction = DMA_FROM_DEVICE;
> + else if (sync.flags & DMA_BUF_SYNC_WRITE)
> + direction = DMA_TO_DEVICE;
> + else
> + return -EINVAL;
> +
> + if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> + return -EINVAL;
> +
> + /* FIXME: Check for overflows in start/length. */
> +
Even this for fixing in this patch itself.
> + if (sync.flags & DMA_BUF_SYNC_END)
> + dma_buf_end_cpu_access(dmabuf, sync.start,
> + sync.length, direction);
> + else
> + dma_buf_begin_cpu_access(dmabuf, sync.start,
> +sync.length, direction);
> +
> + return 0;
> + default:
> + return -ENOTTY;
> + }
> +}
> +
> static const struct file_operations dma_buf_fops = {
> .release= dma_buf_release,
> .mmap = dma_buf_mmap_internal,
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> + .unlocked_ioctl = dma_buf_ioctl,
> };
>
> /*
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> new file mode 100644
> index 000..e5327df
> --- /dev/null
> +++ b/include/uapi/linux/dma-buf.h
> @@ -0,0 +1,39 @@
> +/*
> + * Framework for buffer objects that can be shared across devices/subsystems.
> + *
> + * Copyright(C) 2015 Intel Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program. If not, see
Re: [Intel-gfx] [PATCH] drm/i915: Fix divide by zero on watermark update
On Thu, 16 Jul 2015, Damien Lespiau wrote: > On Thu, Jul 16, 2015 at 07:36:51PM +0300, Mika Kuoppala wrote: >> Fix divide by zero if we end up updating the watermarks >> with zero dotclock. >> >> This is a stop gap measure to allow module load in cases >> where our state keeping fails. >> >> v2: WARN_ON added (Paulo) >> >> Cc: Paulo Zanoni >> Cc: Damien Lespiau >> Signed-off-by: Mika Kuoppala > > I want to say a loading module is more important than a proper fix, so: Any ideas on the proper fix? Patches on the list, sketches on a post-it, anything? I've got a machine here hitting this. BR, Jani. > > Reviewed-by: Damien Lespiau > > -- > Damien > >> --- >> drivers/gpu/drm/i915/intel_pm.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 5eeddc9..0d3e014 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3316,8 +3316,10 @@ skl_compute_linetime_wm(struct drm_crtc *crtc, struct >> skl_pipe_wm_parameters *p) >> if (!to_intel_crtc(crtc)->active) >> return 0; >> >> -return DIV_ROUND_UP(8 * p->pipe_htotal * 1000, p->pixel_rate); >> +if (WARN_ON(p->pixel_rate == 0)) >> +return 0; >> >> +return DIV_ROUND_UP(8 * p->pipe_htotal * 1000, p->pixel_rate); >> } >> >> static void skl_compute_transition_wm(struct drm_crtc *crtc, >> -- >> 2.1.4 >> > ___ > 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: Retry port as HDMI if dp_is_edp turns out to be false
On Wed, Aug 12, 2015 at 03:14:53PM +0100, Chris Wilson wrote: > On Wed, Aug 12, 2015 at 04:45:39PM +0300, Ville Syrjälä wrote: > > > - /* > > > - * For eDP we always set the encoder type to INTEL_OUTPUT_EDP, but > > > - * for DP the encoder type can be set by the caller to > > > - * INTEL_OUTPUT_UNKNOWN for DDI, so don't rewrite it. > > > - */ > > > - if (type == DRM_MODE_CONNECTOR_eDP) > > > - intel_encoder->type = INTEL_OUTPUT_EDP; > > > > aux (and IIRC pps setup on vlv/chv) needs is_edp() to work. So I think > > this would break stuff. > > Hmm, I was hoping that all the additional setup we do in init for edp > would be enough for it to use any and all sidebands as necessary. It might work by accident at least on some machines since BIOSen seem to leave the vdd force enabled for eDP panels even if the port isn't active. But if that's not the case, then we'd fail to power up the panel before attempting the initial aux communication, and the eDP probe would fail. > > The fallout will be that we simply cannot reuse the false eDP link as a > plain DP and just establish one HDMI connector for the port. Or maybe it > is still recoverable? If we can keep is_edp() returning true during the edp init, things should work OK. For vlv/chv we might need to poke at the pps (maybe just vlv_detach_power_sequencer() would be enough) to make normal DP work without the pps preventing the port from powering up. That should be testable by pretending the VBT is lying about a DP port being an eDP port. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:05 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Mon, Aug 10, 2015 at 03:00:13PM +0300, Jani Nikula wrote:
> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > > + n_low = n & 0xfff;
> > > + n_up = (n >> 12) & 0xff;
> > > +
> > > + /* 4. set the N/CTS */
> > > + tmp = I915_READ(HSW_AUD_CFG(pipe));
> > > + tmp |= AUD_CONFIG_N_PROG_ENABLE;
> > > + tmp &= ~AUD_CONFIG_UPPER_N_MASK;
> > > + tmp |= (n_up << AUD_CONFIG_UPPER_N_SHIFT);
> > > + tmp &= ~AUD_CONFIG_LOWER_N_MASK;
> > > + tmp |= (n_low << AUD_CONFIG_LOWER_N_SHIFT);
> >
> > You could squash the ors and ands together.
>
> Also read-modify-write considered evil. If you need to save a few bits
> please be explicit about it like
>
> tmp &= BITS_WE_WANT_TO_KEEP;
OK, I will try to use this format.
>
> if there's no bits to keep just start out with 0. If we have too much rwm
> to hw registers then probably something with the overall design is
> botched, e.g. with the pipe config precomputation we managed to
> remove
> almost all the rwm code for modesets.
Yes, if we can set the register by starting out with 0,
it will be better. But in this case, there are some reserved
bits. We should reserve its bits for compatibility, I think.
> -Daniel
>
> >
> > > + I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static const struct i915_audio_component_ops
> i915_audio_component_ops = {
> > > .owner = THIS_MODULE,
> > > .get_power = i915_audio_component_get_power,
> > > .put_power = i915_audio_component_put_power,
> > > .codec_wake_override =
> i915_audio_component_codec_wake_override,
> > > .get_cdclk_freq = i915_audio_component_get_cdclk_freq,
> > > + .set_ncts = i915_audio_component_set_ncts,
> > > };
> > >
> > > static int i915_audio_component_bind(struct device *i915_dev,
> > > --
> > > 1.9.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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> 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 v2 2/4] drm/i915: implement set_ncts callback
Hi Daniel,
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, August 12, 2015 9:06 PM
> To: Jani Nikula
> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> > > From: Libin Yang
> > >
> > > Display audio may not work at some frequencies
> > > with the HW provided N/CTS.
> > >
> > > This patch sets the proper N value for the
> > > given audio sample rate at the impacted frequencies.
> > > At other frequencies, it will use the N/CTS value
> > > which HW provides.
> > >
> > > Signed-off-by: Libin Yang
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
> > > drivers/gpu/drm/i915/intel_audio.c | 95
> ++
> > > 2 files changed, 97 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > > index ea46d68..da2d128 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
> > > _HSW_AUD_MISC_CTRL_A, \
> > > _HSW_AUD_MISC_CTRL_B)
> > >
> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> > > +
> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> > > index dc32cf4..eddf37f 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -68,6 +68,30 @@ static const struct {
> > > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> > > };
> > >
> > > +#define TMDS_297M 297000
> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> > > +static const struct {
> > > + int sample_rate;
> > > + int clock;
> > > + int n;
> > > + int cts;
> > > +} aud_ncts[] = {
> > > + { 44100, TMDS_296M, 4459, 234375 },
> > > + { 44100, TMDS_297M, 4704, 247500 },
> > > + { 48000, TMDS_296M, 5824, 281250 },
> > > + { 48000, TMDS_297M, 5120, 247500 },
> > > + { 32000, TMDS_296M, 5824, 421875 },
> > > + { 32000, TMDS_297M, 3072, 222750 },
> > > + { 88200, TMDS_296M, 8918, 234375 },
> > > + { 88200, TMDS_297M, 9408, 247500 },
> > > + { 96000, TMDS_296M, 11648, 281250 },
> > > + { 96000, TMDS_297M, 10240, 247500 },
> > > + { 176400, TMDS_296M, 17836, 234375 },
> > > + { 176400, TMDS_297M, 18816, 247500 },
> > > + { 44100, TMDS_296M, 23296, 281250 },
> > > + { 44100, TMDS_297M, 20480, 247500 },
> > > +};
> > > +
> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> > > static u32 audio_config_hdmi_pixel_clock(struct
> drm_display_mode *mode)
> > > {
> > > @@ -514,12 +538,83 @@ static int
> i915_audio_component_get_cdclk_freq(struct device *dev)
> > > return ret;
> > > }
> > >
> > > +static int i915_audio_component_set_ncts(struct device *dev, int
> port,
> > > + int dev_entry, int rate)
> > > +{
> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> > > + struct drm_device *drm_dev = dev_priv->dev;
> > > + struct intel_encoder *intel_encoder;
> > > + struct intel_digital_port *intel_dig_port;
> > > + struct intel_crtc *crtc;
> > > + struct drm_display_mode *mode;
> > > + enum pipe pipe = -1;
> > > + u32 tmp;
> > > + int i;
> > > + int n_low, n_up, n = 0;
> >
> > I think you'll need the power well get here, and put at the end. Or
> > check that we it.
>
> If we call this and end up actually dropping the power well then the
> register writes will go exactly nowhere at all. Which indicates a bug in
> how this is orchestrated. There is probably one ...
Sorry, I'm not understanding your meaning clearly.
Do you mean if we put the power well, the register's value will
be invalid? Actually, we found another issue for audio power
management (this is another bug, not related to this feature),
and I'm thinking to add get_power/put_power as Jani said
in another patch.
Regards,
Libin
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> 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: Do not check or a stalled pageflip prior to it being queued
On Wed, Aug 12, 2015 at 04:54:09PM +0300, Ville Syrjälä wrote: > On Wed, Aug 12, 2015 at 01:08:22PM +0100, Chris Wilson wrote: > > When we queue the command or operation to change the scanout address, we > > mark the flip as in progress. We can use this flag to prevent us from > > checking for a stalled flip prior to its existence! > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/intel_display.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index aab8dfd1f8a5..edc7d4a7c9de 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -11248,6 +11248,9 @@ static bool __intel_pageflip_stall_check(struct > > drm_device *dev, > > if (atomic_read(&work->pending) >= INTEL_FLIP_COMPLETE) > > return true; > > > > + if (atomic_read(&work->pending) < INTEL_FLIP_PENDING) > > + return false; > > + > > unpin_work is assigned and the lock dropped before the flip is marked as > INTEL_FLIP_PENDING. Makes sense. > > Reviewed-by: Ville Syrjälä Queued for -next, thanks for the patch. -Daniel > > > if (!work->enable_stall_check) > > return false; > > > > -- > > 2.5.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> Hi Daniel,
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
>> Daniel Vetter
>> Sent: Wednesday, August 12, 2015 9:06 PM
>> To: Jani Nikula
>> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
>> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
>> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
>> callback
>>
>> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
>> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
>> > > From: Libin Yang
>> > >
>> > > Display audio may not work at some frequencies
>> > > with the HW provided N/CTS.
>> > >
>> > > This patch sets the proper N value for the
>> > > given audio sample rate at the impacted frequencies.
>> > > At other frequencies, it will use the N/CTS value
>> > > which HW provides.
>> > >
>> > > Signed-off-by: Libin Yang
>> > > ---
>> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
>> > > drivers/gpu/drm/i915/intel_audio.c | 95
>> ++
>> > > 2 files changed, 97 insertions(+)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> > > index ea46d68..da2d128 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
>> > > _HSW_AUD_MISC_CTRL_A, \
>> > > _HSW_AUD_MISC_CTRL_B)
>> > >
>> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
>> > > +
>> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
>> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
>> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
>> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> > > index dc32cf4..eddf37f 100644
>> > > --- a/drivers/gpu/drm/i915/intel_audio.c
>> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> > > @@ -68,6 +68,30 @@ static const struct {
>> > > { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
>> > > };
>> > >
>> > > +#define TMDS_297M 297000
>> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
>> > > +static const struct {
>> > > +int sample_rate;
>> > > +int clock;
>> > > +int n;
>> > > +int cts;
>> > > +} aud_ncts[] = {
>> > > +{ 44100, TMDS_296M, 4459, 234375 },
>> > > +{ 44100, TMDS_297M, 4704, 247500 },
>> > > +{ 48000, TMDS_296M, 5824, 281250 },
>> > > +{ 48000, TMDS_297M, 5120, 247500 },
>> > > +{ 32000, TMDS_296M, 5824, 421875 },
>> > > +{ 32000, TMDS_297M, 3072, 222750 },
>> > > +{ 88200, TMDS_296M, 8918, 234375 },
>> > > +{ 88200, TMDS_297M, 9408, 247500 },
>> > > +{ 96000, TMDS_296M, 11648, 281250 },
>> > > +{ 96000, TMDS_297M, 10240, 247500 },
>> > > +{ 176400, TMDS_296M, 17836, 234375 },
>> > > +{ 176400, TMDS_297M, 18816, 247500 },
>> > > +{ 44100, TMDS_296M, 23296, 281250 },
>> > > +{ 44100, TMDS_297M, 20480, 247500 },
>> > > +};
>> > > +
>> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
>> > > static u32 audio_config_hdmi_pixel_clock(struct
>> drm_display_mode *mode)
>> > > {
>> > > @@ -514,12 +538,83 @@ static int
>> i915_audio_component_get_cdclk_freq(struct device *dev)
>> > > return ret;
>> > > }
>> > >
>> > > +static int i915_audio_component_set_ncts(struct device *dev, int
>> port,
>> > > +int dev_entry, int rate)
>> > > +{
>> > > +struct drm_i915_private *dev_priv = dev_to_i915(dev);
>> > > +struct drm_device *drm_dev = dev_priv->dev;
>> > > +struct intel_encoder *intel_encoder;
>> > > +struct intel_digital_port *intel_dig_port;
>> > > +struct intel_crtc *crtc;
>> > > +struct drm_display_mode *mode;
>> > > +enum pipe pipe = -1;
>> > > +u32 tmp;
>> > > +int i;
>> > > +int n_low, n_up, n = 0;
>> >
>> > I think you'll need the power well get here, and put at the end. Or
>> > check that we it.
>>
>> If we call this and end up actually dropping the power well then the
>> register writes will go exactly nowhere at all. Which indicates a bug in
>> how this is orchestrated. There is probably one ...
>
> Sorry, I'm not understanding your meaning clearly.
> Do you mean if we put the power well, the register's value will
> be invalid? Actually, we found another issue for audio power
> management (this is another bug, not related to this feature),
> and I'm thinking to add get_power/put_power as Jani said
> in another patch.
No, the point was that you should rather check that we have power. If
there isn't, and you get/put, you'll lose the values at the put.
BR,
Jani.
>
> Regards,
> Libin
>
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
--
Jani Nikula, Intel Open Source
[Intel-gfx] [PATCH 5/9 v6] drm/i915: Enable GuC firmware log
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 29 +++
drivers/gpu/drm/i915/i915_guc_submission.c | 46 ++
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3609b13..529d2fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2412,6 +2412,34 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_guc_log_dump(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *log_obj = dev_priv->guc.log_obj;
+ u32 *log;
+ int i = 0, pg;
+
+ if (!log_obj)
+ return 0;
+
+ for (pg = 0; pg < log_obj->base.size / PAGE_SIZE; pg++) {
+ log = kmap_atomic(i915_gem_object_get_page(log_obj, pg));
+
+ for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
+ seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+ *(log + i), *(log + i + 1),
+ *(log + i + 2), *(log + i + 3));
+
+ kunmap_atomic(log);
+ }
+
+ seq_putc(m, '\n');
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5072,6 +5100,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
+ {"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 8ff59aa..669c889 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -79,6 +79,47 @@ static void gem_release_guc_obj(struct drm_i915_gem_object
*obj)
drm_gem_object_unreference(&obj->base);
}
+static void guc_create_log(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_gem_object *obj;
+ unsigned long offset;
+ uint32_t size, flags;
+
+ if (i915.guc_log_level < GUC_LOG_VERBOSITY_MIN)
+ return;
+
+ if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
+ i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
+
+ /* The first page is to save log buffer state. Allocate one
+* extra page for others in case for overlap */
+ size = (1 + GUC_LOG_DPC_PAGES + 1 +
+ GUC_LOG_ISR_PAGES + 1 +
+ GUC_LOG_CRASH_PAGES + 1) << PAGE_SHIFT;
+
+ obj = guc->log_obj;
+ if (!obj) {
+ obj = gem_allocate_guc_obj(dev_priv->dev, size);
+ if (!obj) {
+ /* logging will be off */
+ i915.guc_log_level = -1;
+ return;
+ }
+
+ guc->log_obj = obj;
+ }
+
+ /* each allocated unit is a page */
+ flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
+ (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
+ (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT);
+
+ offset = i915_gem_obj_ggtt_offset(obj) >> PAGE_SHIFT; /* in pages */
+ guc->log_flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
+}
+
/*
* Set up the memory resources to be shared with the GuC. At this point,
* we require just one object that can be mapped through the GGTT.
@@ -103,6 +144,8 @@ int i915_guc_submission_init(struct drm_device *dev)
ida_init(&guc->ctx_ids);
+ guc_create_log(guc);
+
return 0;
}
@@ -111,6 +154,9 @@ void i915_guc_submission_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
+ gem_release_guc_obj(dev_priv->guc.log_obj);
+ guc->log_obj = NULL;
+
if (guc->ctx_pool_obj)
ida_destroy(&guc->ctx_ids);
gem_release_guc_obj(guc->ctx_pool_obj);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index be3cad8..5b51b05 100644
--- a/
[Intel-gfx] [PATCH 0/9 v6] Batch submission via GuC
This patch series enables command submission via the GuC. In this mode, instead of the host CPU driving the execlist port directly, it hands over work items to the GuC, using a doorbell mechanism to tell the GuC that new items have been added to its work queue. The GuC then dispatches contexts to the various GPU engines, and manages the resulting context- switch interrupts. Completion of a batch is however still signalled to the CPU; the GuC is not involved in handling user interrupts. There are two subsequences within the patch series: drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status These two patches provide the GuC loader and a debugfs interface to verify the resulting state. At this point in the sequence we can load and activate the GuC firmware, but not submit any batches through it. (This is nonetheless a potentially useful state, as the GuC could do other useful work even when not handling batch submissions). drm/i915: Expose one LRC function for GuC submission mode drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Integrate GuC-based command submission drm/i915: Debugfs interface for GuC submission statistics In this second section, we implement the GuC submission mechanism, and link it into the (execlist-based) submission path. At this stage, it is not yet enabled by default; it is activated only if the kernel command line explicitly switches it on. The GuC firmware itself is not included in this patchset; it is or will be available for download from https://01.org/linuxgraphics/downloads/ This driver works with and requires GuC firmware revision 3.x. It will not work with any firmware version 1.x, as the GuC protocol in those revisions was incompatible and is no longer supported. On platforms where there is no GuC, or where GuC submission is not specifically enabled, batch submission will continue to use the execlist (or ringbuffer) mechanisms. On the other hand, if GuC submission is requested but the GuC firmware cannot be found or is invalid, the GPU will be unusable. It is expected that a subsequent patch will enable GuC submission by default once the signed firmware is published on 01.org. Ben Widawsky (0): Vinit Azad (0): Michael H. Nguyen (0): created the original versions on which some of these patches are based. Alex Dai (5): drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Integrate GuC-based command submission Dave Gordon (4): drm/i915: Expose one LRC function for GuC submission mode drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Debugfs interface for GuC submission statistics Documentation/DocBook/drm.tmpl | 14 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_debugfs.c| 146 - drivers/gpu/drm/i915/i915_dma.c| 9 + drivers/gpu/drm/i915/i915_drv.h| 11 + drivers/gpu/drm/i915/i915_gem.c| 16 + drivers/gpu/drm/i915/i915_gpu_error.c | 14 +- drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- drivers/gpu/drm/i915/i915_guc_submission.c | 901 + drivers/gpu/drm/i915/i915_reg.h| 15 +- drivers/gpu/drm/i915/intel_guc.h | 122 drivers/gpu/drm/i915/intel_guc_fwif.h | 9 +- drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++ drivers/gpu/drm/i915/intel_lrc.c | 65 ++- drivers/gpu/drm/i915/intel_lrc.h | 8 + 15 files changed, 1918 insertions(+), 44 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9 v6] drm/i915: Expose one LRC function for GuC submission mode
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to describe a context for submission via
the GuC, we need one of the same functions used in execlist mode.
This commit exposes one such function, changing its name to better
describe what it does (it's related to logical ring contexts rather
than to execlists per se).
v2:
Replaces previous "drm/i915: Move execlists defines from .c to .h"
v3:
Incorporates a change to one of the functions exposed here that was
previously part of an internal patch, but which was omitted from
the version recently committed to drm-intel-nightly:
7a01a0a drm/i915/lrc: Update PDPx registers with lri commands
So we reinstate this change here.
v4:
Drop v3 change, update function parameters due to collision with
8ee3615 drm/i915: Convert execlists_ctx_descriptor() for requests
v5:
Don't expose execlists_update_context() after all. The current
version is no longer compatible with GuC submission; trying to
share the execlist version of this function results in both GuC
and CPU updating TAIL in the context image, with bad results when
they get out of step. The GuC submission path now has its own
private version that just updates the ringbuffer start address,
and not TAIL or PDPx.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.h | 2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 138964a..f3411f8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -270,11 +270,11 @@ u32 intel_execlists_ctx_id(struct drm_i915_gem_object
*ctx_obj)
return lrca >> 12;
}
-static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request *rq)
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring)
{
- struct intel_engine_cs *ring = rq->ring;
struct drm_device *dev = ring->dev;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
uint64_t desc;
uint64_t lrca = i915_gem_obj_ggtt_offset(ctx_obj);
@@ -312,13 +312,13 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
uint64_t desc[2];
if (rq1) {
- desc[1] = execlists_ctx_descriptor(rq1);
+ desc[1] = intel_lr_context_descriptor(rq1->ctx, rq1->ring);
rq1->elsp_submitted++;
} else {
desc[1] = 0;
}
- desc[0] = execlists_ctx_descriptor(rq0);
+ desc[0] = intel_lr_context_descriptor(rq0->ctx, rq0->ring);
rq0->elsp_submitted++;
/* You must always write both descriptors in the order below. */
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 64f89f99..5e5788c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -74,6 +74,8 @@ int intel_lr_context_deferred_create(struct intel_context
*ctx,
void intel_lr_context_unpin(struct drm_i915_gem_request *req);
void intel_lr_context_reset(struct drm_device *dev,
struct intel_context *ctx);
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring);
/* Execlists */
int intel_sanitize_enable_execlists(struct drm_device *dev, int
enable_execlists);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9 v6] drm/i915: Debugfs interface to read GuC load status
From: Alex Dai
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 86734be..3609b13 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2374,6 +2374,44 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
}
+static int i915_guc_load_status_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_private *dev_priv = node->minor->dev->dev_private;
+ struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+ u32 tmp, i;
+
+ if (!HAS_GUC_UCODE(dev_priv->dev))
+ return 0;
+
+ seq_printf(m, "GuC firmware status:\n");
+ seq_printf(m, "\tpath: %s\n",
+ guc_fw->guc_fw_path);
+ seq_printf(m, "\tfetch: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+ seq_printf(m, "\tload: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ seq_printf(m, "\tversion wanted: %d.%d\n",
+ guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+ seq_printf(m, "\tversion found: %d.%d\n",
+ guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+
+ tmp = I915_READ(GUC_STATUS);
+
+ seq_printf(m, "\nGuC status 0x%08x:\n", tmp);
+ seq_printf(m, "\tBootrom status = 0x%x\n",
+ (tmp & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
+ seq_printf(m, "\tuKernel status = 0x%x\n",
+ (tmp & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
+ seq_printf(m, "\tMIA Core status = 0x%x\n",
+ (tmp & GS_MIA_MASK) >> GS_MIA_SHIFT);
+ seq_puts(m, "\nScratch registers:\n");
+ for (i = 0; i < 16; i++)
+ seq_printf(m, "\t%2d: \t0x%x\n", i, I915_READ(SOFT_SCRATCH(i)));
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5033,6 +5071,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9 v6] drm/i915: Integrate GuC-based command submission
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes also required, notably:
1. Contexts must be pinned at GGTT addresses accessible by the GuC
i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
2. The GuC's TLB must be invalidated after a context is pinned at
a new GGTT address.
3. GuC firmware uses the one page before Ring Context as shared data.
Therefore, whenever driver wants to get base address of LRC, we
will offset one page for it. LRC_PPHWSP_PN is defined as the page
number of LRCA.
4. In the work queue used to pass requests to the GuC, the GuC
firmware requires the ring-tail-offset to be represented as an
11-bit value, expressed in QWords. Therefore, the ringbuffer
size must be reduced to the representable range (4 pages).
v2:
Defer adding #defines until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v4:
Squashed kerneldoc patch into here [Daniel Vetter]
v5:
Update request->tail in code common to both GuC and execlist modes.
Add a private version of lr_context_update(), as sharing the
execlist version leads to race conditions when the CPU and
the GuC both update TAIL in the context image.
Conversion of error-captured HWS page to string must account
for offset from start of object to actual HWS (LRC_PPHWSP_PN).
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
Documentation/DocBook/drm.tmpl | 14 ++
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 14 +++---
drivers/gpu/drm/i915/i915_guc_submission.c | 79 --
drivers/gpu/drm/i915/intel_guc.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 55 ++---
drivers/gpu/drm/i915/intel_lrc.h | 6 +++
7 files changed, 142 insertions(+), 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4111902..a01fca9 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4152,6 +4152,20 @@ int num_ioctls;
+ GuC-based Command Submission
+
+GuC
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
+!Idrivers/gpu/drm/i915/intel_guc_loader.c
+
+
+GuC Client
+!Pdrivers/gpu/drm/i915/intel_guc_submission.c GuC-based command submissison
+!Idrivers/gpu/drm/i915/intel_guc_submission.c
+
+
+
+
Tracing
This sections covers all things related to the tracepoints implemented in
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 529d2fd..cfddc9a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1995,7 +1995,7 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
- page = i915_gem_object_get_page(ctx_obj, 1);
+ page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
if (!WARN_ON(page == NULL)) {
reg_state = kmap_atomic(page);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f79c952..94012e7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -461,17 +461,17 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
}
if ((obj = error->ring[i].hws_page)) {
- err_printf(m, "%s --- HW Status = 0x%08x\n",
- dev_priv->ring[i].name,
- lower_32_bits(obj->gtt_offset));
+ err_printf(m, "%s --- HW Status = 0x%08llx\n",
+ dev_priv->ring[i].name,
+ obj->gtt_offset + LRC_PPHWSP_PN * PAGE_SIZE);
offset = 0;
for (elt = 0; elt < PAGE_SIZE/16; elt += 4) {
err_printf(m, "[%04x] %08x %08x %08x %08x\n",
offset,
- obj->pages[0][elt],
- obj->pages[0][elt+1],
- obj->pages[0][elt+2],
- obj->pages[0][elt+3]);
+ obj->pages[LRC_PPHWSP_PN][elt],
+ obj->pages[LRC_PPHWSP_PN][elt+1],
+ obj->pages[LRC_PPHWSP_PN][elt+2],
+ obj->pages[LRC_PPHWSP_PN][elt+3])
[Intel-gfx] [PATCH 4/9 v6] drm/i915: Prepare for GuC-based command submission
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the range [0..WOPCM_TOP), as that range of GGTT
addresses is not accessible to the GuC (from the GuC's point of view,
it's permanently reserved for other objects such as the BootROM & SRAM).
Later, we will need to allocate additional GuC-sharable objects for the
submission client(s) and the GuC's debug log.
v2:
Remove redundant initialisation [Chris Wilson]
Defer adding struct members until needed [Chris Wilson]
Local functions should pass dev_priv rather than dev [Chris Wilson]
v5:
Invalidate GuC TLB after allocating and pinning a new object
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 118 +
drivers/gpu/drm/i915/intel_guc.h | 7 ++
drivers/gpu/drm/i915/intel_guc_loader.c| 21 +
4 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 65e52fa..44d290a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -41,7 +41,8 @@ i915-y += i915_cmd_parser.o \
intel_uncore.o
# general-purpose microcontroller (GuC) support
-i915-y += intel_guc_loader.o
+i915-y += intel_guc_loader.o \
+ i915_guc_submission.o
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
new file mode 100644
index 000..8ff59aa
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+#include
+#include
+#include "i915_drv.h"
+#include "intel_guc.h"
+
+/**
+ * gem_allocate_guc_obj() - Allocate gem object for GuC usage
+ * @dev: drm device
+ * @size: size of object
+ *
+ * This is a wrapper to create a gem obj. In order to use it inside GuC, the
+ * object needs to be pinned lifetime. Also we must pin it to gtt space other
+ * than [0, GUC_WOPCM_TOP) because this range is reserved inside GuC.
+ *
+ * Return: A drm_i915_gem_object if successful, otherwise NULL.
+ */
+static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
+ u32 size)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_alloc_object(dev, size);
+ if (!obj)
+ return NULL;
+
+ if (i915_gem_object_get_pages(obj)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ if (i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+ PIN_OFFSET_BIAS | GUC_WOPCM_TOP)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+ return obj;
+}
+
+/**
+ * gem_release_guc_obj() - Release gem object allocated for GuC usage
+ * @obj: gem obj to be released
+ */
+static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
+{
+ if (!obj)
+ return;
+
+ if (i915_gem_obj_is_pinned(obj))
+ i915_gem_object_ggtt_unpin(obj);
+
+ drm_gem_object_unreference(&obj->base);
+}
+
+/*
+ * Set up the memory resources to be shared with the GuC. At
[Intel-gfx] [PATCH 9/9 v6] drm/i915: Debugfs interface for GuC submission statistics
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v5:
Added GuC per-engine submission & seqno statistics
v6:
Add per-ring statistics to client, refactor client-dumper.
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index cfddc9a..7a28de5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2412,6 +2412,81 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static void i915_guc_client_info(struct seq_file *m,
+struct drm_i915_private *dev_priv,
+struct i915_guc_client *client)
+{
+ struct intel_engine_cs *ring;
+ uint64_t tot = 0;
+ uint32_t i;
+
+ seq_printf(m, "\tPriority %d, GuC ctx index: %u, PD offset 0x%x\n",
+ client->priority, client->ctx_index, client->proc_desc_offset);
+ seq_printf(m, "\tDoorbell id %d, offset: 0x%x, cookie 0x%x\n",
+ client->doorbell_id, client->doorbell_offset, client->cookie);
+ seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n",
+ client->wq_size, client->wq_offset, client->wq_tail);
+
+ seq_printf(m, "\tFailed to queue: %u\n", client->q_fail);
+ seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail);
+ seq_printf(m, "\tLast submission result: %d\n", client->retcode);
+
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "\tSubmissions: %llu %s\n",
+ client->submissions[i],
+ ring->name);
+ tot += client->submissions[i];
+ }
+ seq_printf(m, "\tTotal: %llu\n", tot);
+}
+
+static int i915_guc_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_guc guc;
+ struct i915_guc_client client = { .client_obj = 0 };
+ struct intel_engine_cs *ring;
+ enum intel_ring_id i;
+ u64 total = 0;
+
+ if (!HAS_GUC_SCHED(dev_priv->dev))
+ return 0;
+
+ /* Take a local copy of the GuC data, so we can dump it at leisure */
+ spin_lock(&dev_priv->guc.host2guc_lock);
+ guc = dev_priv->guc;
+ if (guc.execbuf_client) {
+ spin_lock(&guc.execbuf_client->wq_lock);
+ client = *guc.execbuf_client;
+ spin_unlock(&guc.execbuf_client->wq_lock);
+ }
+ spin_unlock(&dev_priv->guc.host2guc_lock);
+
+ seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
+ seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
+ seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
+ seq_printf(m, "GuC last action status: 0x%x\n", guc.action_status);
+ seq_printf(m, "GuC last action error code: %d\n", guc.action_err);
+
+ seq_printf(m, "\nGuC submissions:\n");
+ for_each_ring(ring, dev_priv, i) {
+ seq_printf(m, "\t%-24s: %10llu, last seqno 0x%08x %9d\n",
+ ring->name, guc.submissions[i],
+ guc.last_seqno[i], guc.last_seqno[i]);
+ total += guc.submissions[i];
+ }
+ seq_printf(m, "\t%s: %llu\n", "Total", total);
+
+ seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
+ i915_guc_client_info(m, dev_priv, &client);
+
+ /* Add more as required ... */
+
+ return 0;
+}
+
static int i915_guc_log_dump(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5099,6 +5174,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9 v6] drm/i915: Interrupt routing for GuC submission
Turn on interrupt steering to route necessary interrupts to GuC.
v6:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d54dc2c..d4dfd06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1674,6 +1674,7 @@ enum skl_disp_power_wells {
#define GFX_MODE_GEN7 0x0229c
#define RING_MODE_GEN7(ring) ((ring)->mmio_base+0x29c)
#define GFX_RUN_LIST_ENABLE (1<<15)
+#define GFX_INTERRUPT_STEERING (1<<14)
#define GFX_TLB_INVALIDATE_EXPLICIT (1<<13)
#define GFX_SURFACE_FAULT_ENABLE (1<<12)
#define GFX_REPLAY_MODE (1<<11)
@@ -1681,6 +1682,11 @@ enum skl_disp_power_wells {
#define GFX_PPGTT_ENABLE (1<<9)
#define GEN8_GFX_PPGTT_48B (1<<7)
+#define GFX_FORWARD_VBLANK_MASK (3<<5)
+#define GFX_FORWARD_VBLANK_NEVER (0<<5)
+#define GFX_FORWARD_VBLANK_ALWAYS(1<<5)
+#define GFX_FORWARD_VBLANK_COND (2<<5)
+
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
@@ -5694,11 +5700,12 @@ enum skl_disp_power_wells {
#define GEN8_GT_IIR(which) (0x44308 + (0x10 * (which)))
#define GEN8_GT_IER(which) (0x4430c + (0x10 * (which)))
-#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_RCS_IRQ_SHIFT 0
-#define GEN8_VCS2_IRQ_SHIFT 16
+#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_VCS1_IRQ_SHIFT 0
+#define GEN8_VCS2_IRQ_SHIFT 16
#define GEN8_VECS_IRQ_SHIFT 0
+#define GEN8_WD_IRQ_SHIFT 16
#define GEN8_DE_PIPE_ISR(pipe) (0x44400 + (0x10 * (pipe)))
#define GEN8_DE_PIPE_IMR(pipe) (0x44404 + (0x10 * (pipe)))
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b4b057..13e75f6 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -79,6 +79,53 @@ const char *intel_guc_fw_status_repr(enum
intel_guc_fw_status status)
}
};
+static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers NOT to forward interrupts and vblank to
GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK, GFX_FORWARD_VBLANK_NEVER);
+ irqs |= _MASKED_BIT_DISABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send nothing to GuC */
+ I915_WRITE(DE_GUCRMR, ~0);
+
+ /* route all GT interrupts to the host */
+ I915_WRITE(GUC_BCS_RCS_IER, 0);
+ I915_WRITE(GUC_VCS2_VCS1_IER, 0);
+ I915_WRITE(GUC_WD_VECS_IER, 0);
+}
+
+static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers to forward interrupts and vblank to GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK,
GFX_FORWARD_VBLANK_ALWAYS);
+ irqs |= _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send (all) flip_done to GuC */
+ irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
+ DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
+ DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
+ /* Unmasked bits will cause GuC response message to be sent */
+ I915_WRITE(DE_GUCRMR, ~irqs);
+
+ /* route USER_INTERRUPT to Host, all others are sent to GuC. */
+ irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
+ GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
+ /* These three registers have the same bit definitions */
+ I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
+ I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
+ I915_WRITE(GUC_WD_VECS_IER, ~irqs);
+}
+
static u32 get_gttype(struct drm_i915_private *dev_priv)
{
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -342,6 +389,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ direct_interrupts_to_host(dev_priv);
i915_guc_submission_disable(dev);
if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_NONE)
@@ -395,6 +443,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
err = i915_guc_submission_enable(dev);
if (err)
goto fail;
+ direct_interrupts_to_guc(dev_priv);
}
return 0;
@@ -403,6 +452,7 @@ fail:
if (guc_fw->guc_fw_load_status == GUC_FIRMWAR
[Intel-gfx] [PATCH 6/9 v6] drm/i915: Implementation of GuC submission client
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbell
allocation will fail as we haven't yet linked the GuC's context
descriptor to the default contexts for each ring (see later patch).
v2:
Defer adding structure members until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v5:
Add GuC per-engine submission & seqno statistics.
Move wq locking to encompass both get_space() and add_item().
Take forcewake lock in host2guc_action() [Tom O'Rourke]
v6:
Fix GuC doorbell cacheline selection code (the
cacheline-within-page calculation was wrong).
Rename GuC priorities to make them closer to the names used in
the GuC firmware source, matching what the autogenerated
versions will (probably) be.
Add per-ring statistics to client.
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 666 +
drivers/gpu/drm/i915/intel_guc.h | 46 ++
drivers/gpu/drm/i915/intel_guc_fwif.h | 6 +-
drivers/gpu/drm/i915/intel_guc_loader.c| 10 +
4 files changed, 725 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 669c889..3352b85 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -27,6 +27,529 @@
#include "intel_guc.h"
/**
+ * DOC: GuC Client
+ *
+ * i915_guc_client:
+ * We use the term client to avoid confusion with contexts. A i915_guc_client
is
+ * equivalent to GuC object guc_context_desc. This context descriptor is
+ * allocated from a pool of 1024 entries. Kernel driver will allocate doorbell
+ * and workqueue for it. Also the process descriptor (guc_process_desc), which
+ * is mapped to client space. So the client can write Work Item then ring the
+ * doorbell.
+ *
+ * To simplify the implementation, we allocate one gem object that contains all
+ * pages for doorbell, process descriptor and workqueue.
+ *
+ * The Scratch registers:
+ * There are 16 MMIO-based registers start from 0xC180. The kernel driver
writes
+ * a value to the action register (SOFT_SCRATCH_0) along with any data. It then
+ * triggers an interrupt on the GuC via another register write (0xC4C8).
+ * Firmware writes a success/fail code back to the action register after
+ * processes the request. The kernel driver polls waiting for this update and
+ * then proceeds.
+ * See host2guc_action()
+ *
+ * Doorbells:
+ * Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
+ * mapped into process space.
+ *
+ * Work Items:
+ * There are several types of work items that the host may place into a
+ * workqueue, each with its own requirements and limitations. Currently only
+ * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
+ * represents in-order queue. The kernel driver packs ring tail pointer and an
+ * ELSP context descriptor dword into Work Item.
+ * See guc_add_workqueue_item()
+ *
+ */
+
+/*
+ * Read GuC command/status register (SOFT_SCRATCH_0)
+ * Return true if it contains a response rather than a command
+ */
+static inline bool host2guc_action_response(struct drm_i915_private *dev_priv,
+ u32 *status)
+{
+ u32 val = I915_READ(SOFT_SCRATCH(0));
+ *status = val;
+ return GUC2HOST_IS_RESPONSE(val);
+}
+
+static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 status;
+ int i;
+ int ret;
+
+ if (WARN_ON(len < 1 || len > 15))
+ return -EINVAL;
+
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ spin_lock(&dev_priv->guc.host2guc_lock);
+
+ dev_priv->guc.action_count += 1;
+ dev_priv->guc.action_cmd = data[0];
+
+ for (i = 0; i < len; i++)
+ I915_WRITE(SOFT_SCRATCH(i), data[i]);
+
+ POSTING_READ(SOFT_SCRATCH(i - 1));
+
+ I915_WRITE(HOST2GUC_INTERRUPT, HOST2GUC_TRIGGER);
+
+ /* No HOST2GUC command should take longer than 10ms */
+ ret = wait_for_atomic(host2guc_action_response(dev_priv, &status), 10);
+ if (status != GUC2HOST_STATUS_SUCCESS) {
+ /*
+* Either the GuC explicitly returned an error (which
+* we convert to -EIO here) or no response at all was
+* received within the timeout limit (-ETIMEDOUT)
+*/
+ if (ret != -ETIMEDOUT)
+ ret = -EIO;
+
+ DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
+ "status=0x%08X response=0x%
[Intel-gfx] [PATCH 1/9 v6] drm/i915: GuC-specific firmware loader
From: Alex Dai
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wilson
v3:
Removed 'wait' parameter to intel_guc_ucode_load() as firmware
prefetch is no longer supported in the common firmware loader,
per Daniel Vetter's request.
Firmware checker callback fn now returns errno rather than bool.
v4:
Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
Don't keep the driver working (by falling back to execlist mode)
if GuC firmware loading fails [Daniel Vetter]
v5:
Clarify WOPCM-related #defines [Tom O'Rourke]
Delete obsolete code no longer required with current h/w & f/w
[Tom O'Rourke]
Move the call to intel_guc_ucode_init() later, so that it can
allocate GEM objects, and have it fetch the firmware; then
intel_guc_ucode_load() doesn't need to fetch it later.
[Daniel Vetter].
v6:
Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_dma.c | 9 +
drivers/gpu/drm/i915/i915_drv.h | 11 +
drivers/gpu/drm/i915/i915_gem.c | 16 +
drivers/gpu/drm/i915/i915_guc_reg.h | 17 +-
drivers/gpu/drm/i915/i915_reg.h | 4 +-
drivers/gpu/drm/i915/intel_guc.h| 67
drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +-
drivers/gpu/drm/i915/intel_guc_loader.c | 529
9 files changed, 650 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 998b464..65e52fa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,6 +40,9 @@ i915-y += i915_cmd_parser.o \
intel_ringbuffer.o \
intel_uncore.o
+# general-purpose microcontroller (GuC) support
+i915-y += intel_guc_loader.o
+
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
intel_renderstate_gen7.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ab37d11..2193cc2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -435,6 +435,11 @@ static int i915_load_modeset_init(struct drm_device *dev)
* working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
+ /* intel_guc_ucode_init() needs the mutex to allocate GEM objects */
+ mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_init(dev);
+ mutex_unlock(&dev->struct_mutex);
+
ret = i915_gem_init(dev);
if (ret)
goto cleanup_irq;
@@ -476,6 +481,9 @@ cleanup_gem:
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
cleanup_irq:
+ mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
+ mutex_unlock(&dev->struct_mutex);
drm_irq_uninstall(dev);
cleanup_gem_stolen:
i915_gem_cleanup_stolen(dev);
@@ -1128,6 +1136,7 @@ int i915_driver_unload(struct drm_device *dev)
flush_workqueue(dev_priv->wq);
mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 674b223..0c0125c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include "intel_guc.h"
/* General customization:
*/
@@ -1706,6 +1707,8 @@ struct drm_i915_private {
struct i915_virtual_gpu vgpu;
+ struct intel_guc guc;
+
struct intel_csr csr;
/* Display CSR-related protection */
@@ -1950,6 +1953,11 @@ static inline struct drm_i915_private
*dev_to_i915(struct device *dev)
return to_i915(dev_get_drvdata(dev));
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return container_of(guc, struct drm_i915_private, guc);
+}
+
/* Iterate over initialised rings */
#define for_each_ring(ring__, dev_priv__, i__) \
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
@@ -2554,6 +2562,9 @@ struct drm_i915_cmd_table {
#define HAS_CSR(dev) (IS_SKYLAKE(dev))
+#define HAS_GUC_UCODE(dev) (IS_GEN9(dev))
+#define HAS_GUC_SCHED(dev) (IS_GEN9(dev))
+
#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c5
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Commit planes on each crtc separately.
For both patches,
Reviewed-by: Ander Conselvan de Oliveira
On Tue, 2015-08-11 at 12:31 +0200, Maarten Lankhorst wrote:
> This patch is based on the upstream commit 5ac1c4bcf073ad and amended
> for v4.2 to make sure it works as intended.
>
> Repeated calls to begin_crtc_commit can cause warnings like this:
> [ 169.127746] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:616
> [ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
> [ 169.127840] 3 locks held by kms_flip/1947:
> [ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at:
> []
> __drm_modeset_lock_all+0x9c/0x130
> [ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at:
> []
> __drm_modeset_lock_all+0xad/0x130
> [ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: []
> drm_modeset_lock+0x38/0x110
> [ 169.127879] irq event stamp: 665690
> [ 169.127882] hardirqs last enabled at (665689): []
> _raw_spin_unlock_irqrestore+0x55/0x70
> [ 169.127889] hardirqs last disabled at (665690): []
> intel_pipe_update_start+0x113/0x5c0 [i915]
> [ 169.127936] softirqs last enabled at (665470): []
> __do_softirq+0x236/0x650
> [ 169.127942] softirqs last disabled at (665465): []
> irq_exit+0xc5/0xd0
> [ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+
> #4039
> [ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 )
> 04/15/2014
> [ 169.127957] 8800c49036f0 8800cde5fa28 817f6907
> 8001
> [ 169.127964] 8800cde5fa58 810aebed
> 0046
> [ 169.127970] 81c5d518 0268
> 8800cde5fa88
> [ 169.127981] Call Trace:
> [ 169.127992] [] dump_stack+0x4f/0x7b
> [ 169.128001] [] ___might_sleep+0x16d/0x270
> [ 169.128008] [] __might_sleep+0x48/0x90
> [ 169.128017] [] mutex_lock_nested+0x29/0x410
> [ 169.128073] [] ? vgpu_write64+0x220/0x220 [i915]
> [ 169.128138] [] ?
> ironlake_update_primary_plane+0x2ff/0x410 [i915]
> [ 169.128198] [] intel_frontbuffer_flush+0x25/0x70 [i915]
> [ 169.128253] [] intel_finish_crtc_commit+0x4c/0x180
> [i915]
> [ 169.128279] []
> drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
> [ 169.128338] [] __intel_set_mode+0x684/0x830 [i915]
> [ 169.128378] [] intel_crtc_set_config+0x49a/0x620 [i915]
> [ 169.128385] [] ? mutex_unlock+0x9/0x10
> [ 169.128391] [] drm_mode_set_config_internal+0x69/0x120
> [ 169.128398] [] ? might_fault+0x57/0xb0
> [ 169.128403] [] drm_mode_setcrtc+0x253/0x620
> [ 169.128409] [] drm_ioctl+0x1a0/0x6a0
> [ 169.128415] [] ? get_parent_ip+0x11/0x50
> [ 169.128424] [] do_vfs_ioctl+0x2f8/0x530
> [ 169.128429] [] ? trace_hardirqs_on+0xd/0x10
> [ 169.128435] [] ? selinux_file_ioctl+0x56/0x100
> [ 169.128439] [] SyS_ioctl+0x81/0xa0
> [ 169.128445] [] system_call_fastpath+0x12/0x6f
>
> Solve it by using the newly introduced
> drm_atomic_helper_commit_planes_on_crtc.
>
> The problem here was that the drm_atomic_helper_commit_planes() helper
> we were using was basically designed to do
>
> begin_crtc_commit(crtc #1)
> begin_crtc_commit(crtc #2)
> ...
> commit all planes
> finish_crtc_commit(crtc #1)
> finish_crtc_commit(crtc #2)
>
> The problem here is that since our hardware relies on vblank evasion,
> our CRTC 'begin' function waits until we're out of the danger zone in
> which register writes might wind up straddling the vblank, then disables
> interrupts; our 'finish' function re-enables interrupts after the
> registers have been written. The expectation is that the operations between
> 'begin' and 'end' must be performed without sleeping (since interrupts
> are disabled) and should happen as quickly as possible. By clumping all
> of the 'begin' calls together, we introducing a couple problems:
> * Subsequent 'begin' invocations might sleep (which is illegal)
> * The first 'begin' ensured that we were far enough from the vblank that
>we could write our registers safely and ensure they all fell within
>the same frame. Adding extra delay waiting for subsequent CRTC's
>wasn't accounted for and could put us back into the 'danger zone' for
>CRTC #1.
>
> This commit solves the problem by using a new helper that allows an
> order of operations like:
>
>for each crtc {
> begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts
> commit planes for this specific CRTC
> end_crtc_commit(crtc)// reenable interrupts
>}
>
> so that sleeps will only be performed while interrupts are enabled and
> we can be sure that registers for a CRTC will be written immediately
> once we know we're in the safe zone.
>
> The crtc->config->base.crtc update may seem unrelated, but the helper
> will use it to obtain the crtc for the state. Without the update it
> will dereference NULL and crash.
>
> Changes since v1:
> - Use Matt Roper's commit message.
>
> Signed-off-by: M
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts callback
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, August 12, 2015 10:45 PM
> To: Yang, Libin; Daniel Vetter
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement set_ncts
> callback
>
> On Wed, 12 Aug 2015, "Yang, Libin" wrote:
> > Hi Daniel,
> >
> >> -Original Message-
> >> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> >> Daniel Vetter
> >> Sent: Wednesday, August 12, 2015 9:06 PM
> >> To: Jani Nikula
> >> Cc: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> >> Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: implement
> set_ncts
> >> callback
> >>
> >> On Mon, Aug 10, 2015 at 03:16:46PM +0300, Jani Nikula wrote:
> >> > On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> >> > > From: Libin Yang
> >> > >
> >> > > Display audio may not work at some frequencies
> >> > > with the HW provided N/CTS.
> >> > >
> >> > > This patch sets the proper N value for the
> >> > > given audio sample rate at the impacted frequencies.
> >> > > At other frequencies, it will use the N/CTS value
> >> > > which HW provides.
> >> > >
> >> > > Signed-off-by: Libin Yang
> >> > > ---
> >> > > drivers/gpu/drm/i915/i915_reg.h| 2 +
> >> > > drivers/gpu/drm/i915/intel_audio.c | 95
> >> ++
> >> > > 2 files changed, 97 insertions(+)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> > > index ea46d68..da2d128 100644
> >> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > > @@ -7014,6 +7014,8 @@ enum skl_disp_power_wells {
> >> > >_HSW_AUD_MISC_CTRL_A, \
> >> > >_HSW_AUD_MISC_CTRL_B)
> >> > >
> >> > > +#define HSW_AUD_PIPE_CONN_SEL_CTRL 0x650ac
> >> > > +
> >> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_A0x650b4
> >> > > #define _HSW_AUD_DIP_ELD_CTRL_ST_B0x651b4
> >> > > #define HSW_AUD_DIP_ELD_CTRL(pipe) _PIPE(pipe, \
> >> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> >> b/drivers/gpu/drm/i915/intel_audio.c
> >> > > index dc32cf4..eddf37f 100644
> >> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> > > @@ -68,6 +68,30 @@ static const struct {
> >> > >{ 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
> >> > > };
> >> > >
> >> > > +#define TMDS_297M 297000
> >> > > +#define TMDS_296M DIV_ROUND_UP(297000 * 1000, 1001)
> >> > > +static const struct {
> >> > > + int sample_rate;
> >> > > + int clock;
> >> > > + int n;
> >> > > + int cts;
> >> > > +} aud_ncts[] = {
> >> > > + { 44100, TMDS_296M, 4459, 234375 },
> >> > > + { 44100, TMDS_297M, 4704, 247500 },
> >> > > + { 48000, TMDS_296M, 5824, 281250 },
> >> > > + { 48000, TMDS_297M, 5120, 247500 },
> >> > > + { 32000, TMDS_296M, 5824, 421875 },
> >> > > + { 32000, TMDS_297M, 3072, 222750 },
> >> > > + { 88200, TMDS_296M, 8918, 234375 },
> >> > > + { 88200, TMDS_297M, 9408, 247500 },
> >> > > + { 96000, TMDS_296M, 11648, 281250 },
> >> > > + { 96000, TMDS_297M, 10240, 247500 },
> >> > > + { 176400, TMDS_296M, 17836, 234375 },
> >> > > + { 176400, TMDS_297M, 18816, 247500 },
> >> > > + { 44100, TMDS_296M, 23296, 281250 },
> >> > > + { 44100, TMDS_297M, 20480, 247500 },
> >> > > +};
> >> > > +
> >> > > /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
> >> > > static u32 audio_config_hdmi_pixel_clock(struct
> >> drm_display_mode *mode)
> >> > > {
> >> > > @@ -514,12 +538,83 @@ static int
> >> i915_audio_component_get_cdclk_freq(struct device *dev)
> >> > >return ret;
> >> > > }
> >> > >
> >> > > +static int i915_audio_component_set_ncts(struct device *dev,
> int
> >> port,
> >> > > + int dev_entry, int rate)
> >> > > +{
> >> > > + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> >> > > + struct drm_device *drm_dev = dev_priv->dev;
> >> > > + struct intel_encoder *intel_encoder;
> >> > > + struct intel_digital_port *intel_dig_port;
> >> > > + struct intel_crtc *crtc;
> >> > > + struct drm_display_mode *mode;
> >> > > + enum pipe pipe = -1;
> >> > > + u32 tmp;
> >> > > + int i;
> >> > > + int n_low, n_up, n = 0;
> >> >
> >> > I think you'll need the power well get here, and put at the end. Or
> >> > check that we it.
> >>
> >> If we call this and end up actually dropping the power well then the
> >> register writes will go exactly nowhere at all. Which indicates a bug
> in
> >> how this is orchestrated. There is probably one ...
> >
> > Sorry, I'm not understanding your meaning clearly.
> > Do you mean if we put the power well, the register's
Re: [Intel-gfx] [PATCH 0/9 v6] Batch submission via GuC
On 12/08/15 15:43, Dave Gordon wrote: This patch series enables command submission via the GuC. In this mode, instead of the host CPU driving the execlist port directly, it hands over work items to the GuC, using a doorbell mechanism to tell the GuC that new items have been added to its work queue. The GuC then dispatches contexts to the various GPU engines, and manages the resulting context- switch interrupts. Completion of a batch is however still signalled to the CPU; the GuC is not involved in handling user interrupts. There are two subsequences within the patch series: drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status These two patches provide the GuC loader and a debugfs interface to verify the resulting state. At this point in the sequence we can load and activate the GuC firmware, but not submit any batches through it. (This is nonetheless a potentially useful state, as the GuC could do other useful work even when not handling batch submissions). drm/i915: Expose one LRC function for GuC submission mode drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Integrate GuC-based command submission drm/i915: Debugfs interface for GuC submission statistics In this second section, we implement the GuC submission mechanism, and link it into the (execlist-based) submission path. At this stage, it is not yet enabled by default; it is activated only if the kernel command line explicitly switches it on. The GuC firmware itself is not included in this patchset; it is or will be available for download from https://01.org/linuxgraphics/downloads/ This driver works with and requires GuC firmware revision 3.x. It will not work with any firmware version 1.x, as the GuC protocol in those revisions was incompatible and is no longer supported. On platforms where there is no GuC, or where GuC submission is not specifically enabled, batch submission will continue to use the execlist (or ringbuffer) mechanisms. On the other hand, if GuC submission is requested but the GuC firmware cannot be found or is invalid, the GPU will be unusable. It is expected that a subsequent patch will enable GuC submission by default once the signed firmware is published on 01.org. Ben Widawsky (0): Vinit Azad (0): Michael H. Nguyen (0): created the original versions on which some of these patches are based. Alex Dai (5): drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status drm/i915: Prepare for GuC-based command submission drm/i915: Enable GuC firmware log drm/i915: Integrate GuC-based command submission Dave Gordon (4): drm/i915: Expose one LRC function for GuC submission mode drm/i915: Implementation of GuC submission client drm/i915: Interrupt routing for GuC submission drm/i915: Debugfs interface for GuC submission statistics Documentation/DocBook/drm.tmpl | 14 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_debugfs.c| 146 - drivers/gpu/drm/i915/i915_dma.c| 9 + drivers/gpu/drm/i915/i915_drv.h| 11 + drivers/gpu/drm/i915/i915_gem.c| 16 + drivers/gpu/drm/i915/i915_gpu_error.c | 14 +- drivers/gpu/drm/i915/i915_guc_reg.h| 17 +- drivers/gpu/drm/i915/i915_guc_submission.c | 901 + drivers/gpu/drm/i915/i915_reg.h| 15 +- drivers/gpu/drm/i915/intel_guc.h | 122 drivers/gpu/drm/i915/intel_guc_fwif.h | 9 +- drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++ drivers/gpu/drm/i915/intel_lrc.c | 65 ++- drivers/gpu/drm/i915/intel_lrc.h | 8 + 15 files changed, 1918 insertions(+), 44 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c Tom O'Rourke has already R-B'ed the previous [v5] versions of these, and there are no substantive changes to patches 2, 3, 4, 5, 7 and 8, so we can carry that over; also, the change in patch 1 is just an update to a comment noted in Tom's earlier reviews as being out-of-date. I haven't included patch 10 (enable-by-default) as we've decided to wait until the signed firmware is publicly available on 01.org before making it the default. So, it's really just patches 6/9 and 9/9 that need a re-review from Tom. Thanks, .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm/i915/gtt: Workaround for HW preload not flushing pdps
On 12/08/15 08:56, Thierry, Michel wrote: On 8/11/2015 1:05 PM, Zhiyuan Lv wrote: Hi Mika/Dave/Michel, I saw the patch of using LRI for root pointer update has been merged to drm-intel. When we consider i915 driver to run inside a virtual machine, e.g. with XenGT, we may still need Mika's this patch like below: " if (intel_vgpu_active(ppgtt->base.dev)) gen8_preallocate_top_level_pdps(ppgtt); " Could you share with us your opinion? Thanks in advance! Hi Zhiyuan, The change looks ok to me. If you need to preallocate the PDPs, gen8_ppgtt_init is the right place to do it. Only add a similar vgpu_active check to disable the LRI updates (in gen8_emit_bb_start). The reason behind is that LRI command will make shadow PPGTT implementation hard. In XenGT, we construct shadow page table for each PPGTT in guest i915 driver, and then track every guest page table change in order to update shadow page table accordingly. The problem of page table updates with GPU command is that they cannot be trapped by hypervisor to finish the shadow page table update work. In XenGT, the only change we have is the command scan in context submission. But that is not exactly the right time to do shadow page table update. Mika's patch can address the problem nicely. With the preallocation, the root pointers in EXECLIST context will always keep the same. Then we can treat any attempt to change guest PPGTT with GPU commands as malicious behavior. Thanks! Regards, -Zhiyuan The bad thing that was happening if we didn't use LRIs was that the CPU would try to push the new mappings to the GPU by updating PDP registers in the saved context image. This is unsafe if the context is running, as switching away from it would result in the CPU-updated values being overwritten by the older values in the GPU h/w registers (if the context were known to be idle, then it would be safe). Preallocating the top-level PDPs should mean that the values need never change, so there's then no need to update the context image, thus avoiding the write hazard :) .Dave. On Thu, Jun 11, 2015 at 04:57:42PM +0300, Mika Kuoppala wrote: Dave Gordon writes: On 10/06/15 12:42, Michel Thierry wrote: On 5/29/2015 1:53 PM, Michel Thierry wrote: On 5/29/2015 12:05 PM, Michel Thierry wrote: On 5/22/2015 6:04 PM, Mika Kuoppala wrote: With BDW/SKL and 32bit addressing mode only, the hardware preloads pdps. However the TLB invalidation only has effect on levels below the pdps. This means that if pdps change, hw might access with stale pdp entry. To combat this problem, preallocate the top pdps so that hw sees them as immutable for each context. Cc: Ville Syrjälä Cc: Rafael Barbalho Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50 + drivers/gpu/drm/i915/i915_reg.h | 17 + drivers/gpu/drm/i915/intel_lrc.c| 15 +-- 3 files changed, 68 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0ffd459..1a5ad4c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -941,6 +941,48 @@ err_out: return ret; } +/* With some architectures and 32bit legacy mode, hardware pre-loads + * the top level pdps but the tlb invalidation only invalidates the + * lower levels. + * This might lead to hw fetching with stale pdp entries if top level + * structure changes, ie va space grows with dynamic page tables. + */ Is this still necessary if we reload PDPs via LRI instructions whenever the address map has changed? That always (AFAICT) causes sufficient invalidation, so then we might not need to preallocate at all :) LRI reload gets my vote. Please ignore this patch. -Mika .Dave. ___ 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 v4 4/4] drm/i915: set proper N/CTS in modeset
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Wednesday, August 12, 2015 9:43 PM > To: Jani Nikula > Cc: Daniel Vetter; Yang, Libin; alsa-de...@alsa-project.org; > ti...@suse.de; intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch > Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper N/CTS in > modeset > > On Wed, Aug 12, 2015 at 04:23:12PM +0300, Jani Nikula wrote: > > On Wed, 12 Aug 2015, Daniel Vetter wrote: > > > On Wed, Aug 12, 2015 at 09:20:17AM +0300, Jani Nikula wrote: > > >> On Wed, 12 Aug 2015, "Yang, Libin" wrote: > > >> > Hi Jani, > > >> > > > >> >> -Original Message- > > >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> Sent: Tuesday, August 11, 2015 4:14 PM > > >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > intel- > > >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper > N/CTS in > > >> >> modeset > > >> >> > > >> >> On Tue, 11 Aug 2015, "Yang, Libin" > wrote: > > >> >> > Hi Jani, > > >> >> > > > >> >> >> -Original Message- > > >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> >> Sent: Tuesday, August 11, 2015 3:14 PM > > >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; > intel- > > >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> >> Subject: RE: [Intel-gfx] [PATCH v4 4/4] drm/i915: set proper > N/CTS in > > >> >> >> modeset > > >> >> >> > > >> >> >> On Tue, 11 Aug 2015, "Yang, Libin" > wrote: > > >> >> >> > Hi Jani, > > >> >> >> > > > >> >> >> > Thanks for careful reviewing for all the patches, please > > >> >> >> > see my comments. > > >> >> >> > > > >> >> >> >> -Original Message- > > >> >> >> >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > > >> >> >> >> Sent: Monday, August 10, 2015 8:10 PM > > >> >> >> >> To: Yang, Libin; alsa-de...@alsa-project.org; > ti...@suse.de; intel- > > >> >> >> >> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch > > >> >> >> >> Subject: Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: set > proper N/CTS > > >> >> in > > >> >> >> >> modeset > > >> >> >> >> > > >> >> >> >> On Mon, 10 Aug 2015, libin.y...@intel.com wrote: > > >> >> >> >> > From: Libin Yang > > >> >> >> >> > > > >> >> >> >> > When modeset occurs and the TMDS frequency is set > to some > > >> >> >> >> > speical value, the N/CTS need to be set manually if > audio > > >> >> >> >> > is playing. > > >> >> >> >> > > >> >> >> >> When modeset occurs, we disable everything, and then > re-enable > > >> >> >> >> everything, and notify the audio driver every step of the > way. IIUC > > >> >> >> >> there should be no audio playing across the modeset, > and when > > >> >> the > > >> >> >> >> modeset is complete and we've set the valid ELD, the > audio driver > > >> >> >> >> should > > >> >> >> >> call the callback from the earlier patches to set the > correct audio > > >> >> >> >> rate. > > >> >> >> >> > > >> >> >> >> Why is this patch needed? Please enlighten me. > > >> >> >> > > > >> >> >> > Please image this scenario: when audio is playing, the gfx > driver > > >> >> >> > does the modeset. In this situation, after modeset, audio > driver > > >> >> >> > will do nothing and continue playing. And audio driver will > not call > > >> >> >> > set_ncts. > > >> >> >> > > >> >> >> Why does the audio driver not do anything here? Whenever > there's > > >> >> a > > >> >> >> modeset, the graphics driver will disable audio and > invalidate the > > >> >> ELD, > > >> >> >> which should cause an interrupt to notify the audio driver > about > > >> >> >> this. This is no different from a hot-unplug, in fact I can't see > how > > >> >> >> the audio driver could even detect whether there's been a > hotplug > > >> >> or > > >> >> >> not > > >> >> >> when there's a codec disable/enable. > > >> >> > > > >> >> > Yes, it will trigger an interrupt to audio driver when unplug > > >> >> > and another interrupt for hotplug. But from audio driver, > > >> >> > we will not stop the playing and resume the playing based > > >> >> > on the hotplug or modeset. The audio is always playing > during > > >> >> > the hotplug/modeset. > > >> >> > > >> >> But the whole display, and consequently ELD, might have > changed > > >> >> during > > >> >> the hotplug, why do you assume you can just keep playing?! > The > > >> >> display > > >> >> might even have changed from HDMI to DP or vice versa. > > >> > > > >> > The eld info changing will not impact the audio playing. > > >> > Actually, you can image the monitor as a digital speaker, just > > >> > like the headphone to the analog audio. Unplug the speaker > > >> > will not impact on the audio playing. Of course , there is a > > >> > little difference, when monitor hotplug, in the interrupt, > > >> > we may change the codec configuration dynamically. > > >> > > > >> > And audio driver supply th
Re: [Intel-gfx] [PATCH v1 1/2] drm/i915: Contain the WA_REG macro
On 11/08/15 15:44, Arun Siluvery wrote:
From: Mika Kuoppala
Prevent leaking the if scoping by containing the WA_REG
macro inside its own scope.
Reported-by: Arun Siluvery
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1c14233..cf61262 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -780,11 +780,11 @@ static int wa_add(struct drm_i915_private *dev_priv,
return 0;
}
-#define WA_REG(addr, mask, val) { \
+#define WA_REG(addr, mask, val) do { \
const int r = wa_add(dev_priv, (addr), (mask), (val)); \
if (r) \
return r; \
- }
+ } while(0)
#define WA_SET_BIT_MASKED(addr, mask) \
WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
On the one hand, yes, this definitely needs the do-while wrapper.
OTOH, hiding a conditional 'return' inside a macro is an abomination :(
At least it's only local to this file ...
So, on the grounds that this makes it more correct if no less ugly:
Reviewed-by: Dave Gordon
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915/gen9: Disable gather at set shader bit
On 11/08/15 15:44, Arun Siluvery wrote: From Gen9, Push constant instruction parsing behaviour varies according to whether set shader is enabled or not. If we want legacy behaviour then it can be achieved by disabling set shader. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959 Cc: Ben Widawsky Cc: Joonas Lahtinen Cc: Mika Kuoppala Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 5 + drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 2 files changed, 15 insertions(+) [snip] diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index cf61262..7d284ed 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -983,6 +983,16 @@ static int gen9_init_workarounds(struct intel_engine_cs *ring) tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE; WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp); + /* Chicken bits to disable set shader is in multiple places, +* set bits in all required registers to disable it correctly +*/ + WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, GEN9_DISABLE_GATHER_SET_SHADER_SLICE); + if ((IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_D0) || + (IS_BROXTON(dev) && INTEL_REVID(dev) == BXT_REVID_A0)) + WA_SET_BIT_MASKED(RS_CHICKEN, RS_CHICKEN_DISABLE_GATHER_AT_SHADER); + else + WA_SET_BIT_MASKED(CS_RCS_BE, CS_RCS_DISABLE_GATHER_AT_SHADER); + return 0; } This workaround isn't tagged with a specific /* WaXyz:chip */ comment. Also, the style isn't consistent with the other paragraphs earlier in this function: those have braces round the body part even when there's only one line of code, possibly to make it clear where the WA comment applies (of course, this is why the buggy WA_REG() macro wasn't spotted earlier). So, maybe prettify this a bit, if possible? The code actually looks correct, just ugly. Oh, and keep patch 1 even if you decide to abandon this one! .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915: Clean up various HPD defines
From: Ville Syrjälä
Indent the PORTx_HOTPLUG_... defines appropriately, and fix some space
vs. tab issues.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 72 +
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6786e94..ed2d150 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5364,15 +5364,17 @@ enum skl_disp_power_wells {
#define CPU_VGACNTRL 0x41000
-#define DIGITAL_PORT_HOTPLUG_CNTRL 0x44030
-#define DIGITAL_PORTA_HOTPLUG_ENABLE (1 << 4)
-#define DIGITAL_PORTA_SHORT_PULSE_2MS (0 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_4_5MS(1 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_6MS (2 << 2)
-#define DIGITAL_PORTA_SHORT_PULSE_100MS(3 << 2)
-#define DIGITAL_PORTA_NO_DETECT(0 << 0)
-#define DIGITAL_PORTA_LONG_PULSE_DETECT_MASK (1 << 1)
-#define DIGITAL_PORTA_SHORT_PULSE_DETECT_MASK (1 << 0)
+#define DIGITAL_PORT_HOTPLUG_CNTRL 0x44030
+#define DIGITAL_PORTA_HOTPLUG_ENABLE (1 << 4)
+#define DIGITAL_PORTA_PULSE_DURATION_2ms (0 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_4_5ms(1 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_6ms (2 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_100ms(3 << 2)
+#define DIGITAL_PORTA_PULSE_DURATION_MASK (3 << 2)
+#define DIGITAL_PORTA_HOTPLUG_STATUS_MASK (3 << 0)
+#define DIGITAL_PORTA_HOTPLUG_NO_DETECT (0 << 0)
+#define DIGITAL_PORTA_HOTPLUG_SHORT_DETECT(1 << 0)
+#define DIGITAL_PORTA_HOTPLUG_LONG_DETECT (2 << 0)
/* refresh rate hardware control */
#define RR_HW_CTL 0x45300
@@ -6000,45 +6002,45 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
-#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
-#define BXT_PORTA_HOTPLUG_STATUS_MASK (0x3 << 24)
+#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
+#define BXT_PORTA_HOTPLUG_STATUS_MASK (3 << 24)
#define BXT_PORTA_HOTPLUG_NO_DETECT (0 << 24)
#define BXT_PORTA_HOTPLUG_SHORT_DETECT(1 << 24)
#define BXT_PORTA_HOTPLUG_LONG_DETECT (2 << 24)
-#define PORTD_HOTPLUG_ENABLE(1 << 20)
-#define PORTD_PULSE_DURATION_2ms(0)
-#define PORTD_PULSE_DURATION_4_5ms (1 << 18)
-#define PORTD_PULSE_DURATION_6ms(2 << 18)
-#define PORTD_PULSE_DURATION_100ms (3 << 18)
-#define PORTD_PULSE_DURATION_MASK (3 << 18)
-#define PORTD_HOTPLUG_STATUS_MASK (0x3 << 16)
+#define PORTD_HOTPLUG_ENABLE (1 << 20)
+#define PORTD_PULSE_DURATION_2ms (0 << 18)
+#define PORTD_PULSE_DURATION_4_5ms(1 << 18)
+#define PORTD_PULSE_DURATION_6ms (2 << 18)
+#define PORTD_PULSE_DURATION_100ms(3 << 18)
+#define PORTD_PULSE_DURATION_MASK (3 << 18)
+#define PORTD_HOTPLUG_STATUS_MASK (3 << 16)
#define PORTD_HOTPLUG_NO_DETECT (0 << 16)
#define PORTD_HOTPLUG_SHORT_DETECT(1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
-#define PORTC_HOTPLUG_ENABLE(1 << 12)
-#define PORTC_PULSE_DURATION_2ms(0)
-#define PORTC_PULSE_DURATION_4_5ms (1 << 10)
-#define PORTC_PULSE_DURATION_6ms(2 << 10)
-#define PORTC_PULSE_DURATION_100ms (3 << 10)
-#define PORTC_PULSE_DURATION_MASK (3 << 10)
-#define PORTC_HOTPLUG_STATUS_MASK (0x3 << 8)
+#define PORTC_HOTPLUG_ENABLE (1 << 12)
+#define PORTC_PULSE_DURATION_2ms (0 << 10)
+#define PORTC_PULSE_DURATION_4_5ms(1 << 10)
+#define PORTC_PULSE_DURATION_6ms (2 << 10)
+#define PORTC_PULSE_DURATION_100ms(3 << 10)
+#define PORTC_PULSE_DURATION_MASK (3 << 10)
+#define PORTC_HOTPLUG_STATUS_MASK (3 << 8)
#define PORTC_HOTPLUG_NO_DETECT (0 << 8)
#define PORTC_HOTPLUG_SHORT_DETECT(1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
-#define PORTB_HOTPLUG_ENABLE(1 << 4)
-#define PORTB_PULSE_DURATION_2ms(0)
-#define PORTB_PULSE_DURATION_4_5ms (1 << 2)
-#define PORTB_PULSE_DURATION_6ms(2 << 2)
-#define PORTB_PULSE_DURATION_100ms (3 << 2)
-#define PORTB_PULSE_DURATION_MASK (3 << 2)
-#define PORTB_HOTPLUG_STATUS_MASK (0x3 << 0)
+#define PORTB_HOTPLUG_ENABLE (1 << 4)
+#define PORTB_PULSE_DURATION_2ms (0 << 2)
+#define PORTB_PULSE_DURATION_4_5ms(1 << 2)
+#define PORTB_PULSE_DURATION_6ms (2 << 2)
+#define PORTB_PULSE_DURATION_100ms(3 << 2)
+#define PORTB_PULSE_DURATION_MASK (3 << 2)
+#define PORTB_HOTPLUG_STATUS_MASK (3 << 0)
#define PORTB_HOTPLUG_NO_DETECT (0 << 0)
#define PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
-#define PCH_PORT_HOTPLUG20xc403C /* SHOTPLUG_CTL2 */
-#define PORTE_HOTPLUG_ENABLE(1 << 4)
-#define PORTE_HOTPLUG_STATUS_MASK (0x3 << 0)
+#define PCH_PORT_H
[Intel-gfx] [PATCH 05/11] drm/i915: Rename BXT PORTA HPD defines
From: Ville Syrjälä
The PORTA HPD defines are not BXT specific. They also exist on SPT,
and partially already on LPT:LP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8a1e35e..d12106c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1248,7 +1248,7 @@ static bool bxt_port_hotplug_long_detect(enum port port,
u32 val)
{
switch (port) {
case PORT_A:
- return val & BXT_PORTA_HOTPLUG_LONG_DETECT;
+ return val & PORTA_HOTPLUG_LONG_DETECT;
case PORT_B:
return val & PORTB_HOTPLUG_LONG_DETECT;
case PORT_C:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ed2d150..0e9990b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6002,11 +6002,11 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG0xc4030/* SHOTPLUG_CTL */
-#define BXT_PORTA_HOTPLUG_ENABLE (1 << 28)
-#define BXT_PORTA_HOTPLUG_STATUS_MASK (3 << 24)
-#define BXT_PORTA_HOTPLUG_NO_DETECT (0 << 24)
-#define BXT_PORTA_HOTPLUG_SHORT_DETECT(1 << 24)
-#define BXT_PORTA_HOTPLUG_LONG_DETECT (2 << 24)
+#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
+#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
+#define PORTA_HOTPLUG_LONG_DETECT (2 << 24) /* SPT+ & BXT */
#define PORTD_HOTPLUG_ENABLE (1 << 20)
#define PORTD_PULSE_DURATION_2ms (0 << 18)
#define PORTD_PULSE_DURATION_4_5ms(1 << 18)
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] drm/i915: Port A HPD and other HPD cleanups
From: Ville Syrjälä I've had a bunch of this stuff sitting in a branch for quite a while, almost a year by the looks of the git dates :P I also had port E HPD in there but something similar has already landed in the meantime so I just rebased my junk on top. I've only quickly tested the port A HPD on my ILK. Don't have other machines with eDP on port A here. Ville Syrjälä (11): drm/i915: Clean up various HPD defines drm/i915; Extract intel_hpd_enabled_irqs() drm/i915: Factor out ilk_update_display_irq() drm/i915: Add HAS_PCH_LPT_LP() macro drm/i915: Rename BXT PORTA HPD defines drm/i915: Introduce spt_irq_handler() drm/i915: Add port A HPD support for ILK/SNB drm/i915: Add port A HPD support for IVB/HSW drm/i915: LPT:LP needs port A HPD enabled in both north and south drm/i915: Add port A HPD support for BDW drm/i915: Add port A HPD support for SPT drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 367 +++ drivers/gpu/drm/i915/i915_reg.h | 82 drivers/gpu/drm/i915/intel_display.c | 13 +- drivers/gpu/drm/i915/intel_pm.c | 4 +- 5 files changed, 336 insertions(+), 131 deletions(-) -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: Add port A HPD support for ILK/SNB
From: Ville Syrjälä
ILK/SNB support port A HPD. While HPD is optional on eDP let's at least
try to wite it up so that we might notice if the link has issues.
The eDP spec suggests that if HPD is not wired up, one should poll the
link status instead. We don't even do that currently.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 59 ++---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e2485bd..152be8b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -45,6 +45,10 @@
* and related files, but that will be described in separate chapters.
*/
+static const u32 hpd_ilk[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = DE_DP_A_HOTPLUG,
+};
+
static const u32 hpd_ibx[HPD_NUM_PINS] = {
[HPD_CRT] = SDE_CRT_HOTPLUG,
[HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
@@ -1270,6 +1274,16 @@ static bool spt_port_hotplug2_long_detect(enum port
port, u32 val)
}
}
+static bool ilk_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_A:
+ return val & DIGITAL_PORTA_HOTPLUG_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
static bool pch_port_hotplug_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -1864,6 +1878,19 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
{
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
+ u32 hotplug_trigger = de_iir & DE_DP_A_HOTPLUG;
+
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
+ dig_hotplug_reg, hpd_ilk,
+ ilk_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
if (de_iir & DE_AUX_CHANNEL_A)
dp_aux_irq_handler(dev);
@@ -3105,6 +3132,28 @@ static void spt_hpd_irq_setup(struct drm_device *dev)
I915_WRITE(PCH_PORT_HOTPLUG2, hotplug);
}
+static void ilk_hpd_irq_setup(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 hotplug_irqs, hotplug, enabled_irqs;
+
+ hotplug_irqs = DE_DP_A_HOTPLUG;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
+
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+
+ /*
+* Enable digital hotplug on the CPU, and configure the DP short pulse
+* duration to 2ms (which is the minimum in the Display Port spec)
+*/
+ hotplug = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ hotplug &= ~DIGITAL_PORTA_PULSE_DURATION_MASK;
+ hotplug |= DIGITAL_PORTA_HOTPLUG_ENABLE |
DIGITAL_PORTA_PULSE_DURATION_2ms;
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, hotplug);
+
+ ibx_hpd_irq_setup(dev);
+}
+
static void bxt_hpd_irq_setup(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3203,8 +3252,9 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
DE_AUX_CHANNEL_A |
DE_PIPEB_CRC_DONE | DE_PIPEA_CRC_DONE |
DE_POISON);
- extra_mask = DE_PIPEA_VBLANK | DE_PIPEB_VBLANK | DE_PCU_EVENT |
- DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN;
+ extra_mask = (DE_PIPEA_VBLANK | DE_PIPEB_VBLANK | DE_PCU_EVENT |
+ DE_PIPEB_FIFO_UNDERRUN | DE_PIPEA_FIFO_UNDERRUN |
+ DE_DP_A_HOTPLUG);
}
dev_priv->irq_mask = ~display_mask;
@@ -4220,7 +4270,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->irq_uninstall = ironlake_irq_uninstall;
dev->driver->enable_vblank = ironlake_enable_vblank;
dev->driver->disable_vblank = ironlake_disable_vblank;
- dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
+ if (INTEL_INFO(dev)->gen >= 7)
+ dev_priv->display.hpd_irq_setup = ibx_hpd_irq_setup;
+ else
+ dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
} else {
if (INTEL_INFO(dev_priv)->gen == 2) {
dev->driver->irq_preinstall = i8xx_irq_preinstall;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: LPT:LP needs port A HPD enabled in both north and south
From: Ville Syrjälä Supposedly we have to enable port A HPD also in the south on LPT:LP. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index d994b80..de60174 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -3125,6 +3125,8 @@ static void ibx_hpd_irq_setup(struct drm_device *dev) hotplug |= PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_2ms; hotplug |= PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_2ms; hotplug |= PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_2ms; + if (HAS_PCH_LPT_LP(dev)) + hotplug |= PORTA_HOTPLUG_ENABLE; I915_WRITE(PCH_PORT_HOTPLUG, hotplug); } -- 2.4.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: Add port A HPD support for BDW
From: Ville Syrjälä
Wire up the port A HPD for BDW. Compared to earlier platforms the
interrupt setup is a bit different, but basically everything else
looks the same.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 72 +
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index de60174..aefa6c4 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -53,6 +53,10 @@ static const u32 hpd_ivb[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
};
+static const u32 hpd_bdw[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = GEN8_PORT_DP_A_HOTPLUG,
+};
+
static const u32 hpd_ibx[HPD_NUM_PINS] = {
[HPD_CRT] = SDE_CRT_HOTPLUG,
[HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
@@ -369,6 +373,36 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
}
/**
+ * bdw_update_port_irq - update DE port interrupt
+ * @dev_priv: driver private
+ * @interrupt_mask: mask of interrupt bits to update
+ * @enabled_irq_mask: mask of interrupt bits to enable
+ */
+static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
+ uint32_t interrupt_mask,
+ uint32_t enabled_irq_mask)
+{
+ uint32_t new_val;
+ uint32_t old_val;
+
+ assert_spin_locked(&dev_priv->irq_lock);
+
+ if (WARN_ON(!intel_irqs_enabled(dev_priv)))
+ return;
+
+ old_val = I915_READ(GEN8_DE_PORT_IMR);
+
+ new_val = old_val;
+ new_val &= ~interrupt_mask;
+ new_val |= (~enabled_irq_mask & interrupt_mask);
+
+ if (new_val != old_val) {
+ I915_WRITE(GEN8_DE_PORT_IMR, new_val);
+ POSTING_READ(GEN8_DE_PORT_IMR);
+ }
+}
+
+/**
* ibx_display_interrupt_update - update SDEIMR
* @dev_priv: driver private
* @interrupt_mask: mask of interrupt bits to update
@@ -2139,10 +2173,23 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
tmp = I915_READ(GEN8_DE_PORT_IIR);
if (tmp) {
bool found = false;
+ u32 hotplug_trigger = tmp & GEN8_PORT_DP_A_HOTPLUG;
I915_WRITE(GEN8_DE_PORT_IIR, tmp);
ret = IRQ_HANDLED;
+ if (hotplug_trigger) {
+ u32 dig_hotplug_reg, pin_mask, long_mask;
+
+ dig_hotplug_reg =
I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
+ I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL,
dig_hotplug_reg);
+
+ intel_get_hpd_pins(&pin_mask, &long_mask,
hotplug_trigger,
+ dig_hotplug_reg, hpd_bdw,
+
ilk_port_hotplug_long_detect);
+ intel_hpd_irq_handler(dev, pin_mask, long_mask);
+ }
+
if (tmp & aux_mask) {
dp_aux_irq_handler(dev);
found = true;
@@ -3156,15 +3203,22 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 hotplug_irqs, hotplug, enabled_irqs;
- if (INTEL_INFO(dev)->gen >= 7) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ hotplug_irqs = GEN8_PORT_DP_A_HOTPLUG;
+ enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_bdw);
+
+ bdw_update_port_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ } else if (INTEL_INFO(dev)->gen >= 7) {
hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
+
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
} else {
hotplug_irqs = DE_DP_A_HOTPLUG;
enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
- }
- ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
+ }
/*
* Enable digital hotplug on the CPU, and configure the DP short pulse
@@ -3477,6 +3531,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
uint32_t de_pipe_enables;
int pipe;
u32 de_port_en = GEN8_AUX_CHANNEL_A;
+ u32 de_port_masked;
if (IS_GEN9(dev_priv)) {
de_pipe_masked |= GEN9_PIPE_PLANE1_FLIP_DONE |
@@ -3486,9 +3541,14 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (IS_BROXTON(dev_priv))
de_port_en |= BXT_DE_PORT_GMBUS;
- } else
+ } else {
de_pipe_masked |= GEN8_PIPE_PRIMARY_FLIP_DONE |
GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
+ }
+
+ de_port_masked
[Intel-gfx] [PATCH 04/11] drm/i915: Add HAS_PCH_LPT_LP() macro
From: Ville Syrjälä
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 55611d8..4e391dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2573,6 +2573,7 @@ struct drm_i915_cmd_table {
#define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
#define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
#define HAS_PCH_LPT(dev) (INTEL_PCH_TYPE(dev) == PCH_LPT)
+#define HAS_PCH_LPT_LP(dev) (__I915__(dev)->pch_id ==
INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4b3012b..97c6368 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8381,8 +8381,7 @@ static void lpt_enable_clkout_dp(struct drm_device *dev,
bool with_spread,
if (WARN(with_fdi && !with_spread, "FDI requires downspread\n"))
with_spread = true;
- if (WARN(dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE &&
-with_fdi, "LP PCH doesn't have FDI\n"))
+ if (WARN(HAS_PCH_LPT_LP(dev) && with_fdi, "LP PCH doesn't have FDI\n"))
with_fdi = false;
mutex_lock(&dev_priv->sb_lock);
@@ -8405,8 +8404,7 @@ static void lpt_enable_clkout_dp(struct drm_device *dev,
bool with_spread,
}
}
- reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
- SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -8422,8 +8420,7 @@ static void lpt_disable_clkout_dp(struct drm_device *dev)
mutex_lock(&dev_priv->sb_lock);
- reg = (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
- SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_PCH_LPT_LP(dev) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp &= ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -9435,7 +9432,7 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv)
DRM_DEBUG_KMS("Enabling package C8+\n");
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
val = I915_READ(SOUTH_DSPCLK_GATE_D);
val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
@@ -9455,7 +9452,7 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
hsw_restore_lcpll(dev_priv);
lpt_init_pch_refclk(dev);
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
val = I915_READ(SOUTH_DSPCLK_GATE_D);
val |= PCH_LP_PARTITION_LEVEL_DISABLE;
I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index fff0c226..ea49661 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6588,7 +6588,7 @@ static void lpt_init_clock_gating(struct drm_device *dev)
* TODO: this bit should only be enabled when really needed, then
* disabled when not needed anymore in order to save power.
*/
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+ if (HAS_PCH_LPT_LP(dev))
I915_WRITE(SOUTH_DSPCLK_GATE_D,
I915_READ(SOUTH_DSPCLK_GATE_D) |
PCH_LP_PARTITION_LEVEL_DISABLE);
@@ -6603,7 +6603,7 @@ static void lpt_suspend_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (dev_priv->pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_PCH_LPT_LP(dev)) {
uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
--
2.4.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
