[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Just an lvds clock gating fix and a pte clearing hack for hsw to avoid memory corruption when hibernating - something doesn't seem to switch off properly, we're still investigating. Cheers, Daniel The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2: Linux 3.12-rc5 (2013-10-13 15:41:28 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-10-21 for you to fetch changes up to 828c79087cec61eaf4c76bb32c222fbe35ac3930: drm/i915: Disable GGTT PTEs on GEN6+ suspend (2013-10-18 15:44:47 +0200) Ben Widawsky (2): drm/i915: Make PTE valid encoding optional drm/i915: Disable GGTT PTEs on GEN6+ suspend Jesse Barnes (1): drm/i915: disable LVDS clock gating on CPT v2 drivers/gpu/drm/i915/i915_drv.c | 5 +- drivers/gpu/drm/i915/i915_drv.h | 8 ++- drivers/gpu/drm/i915/i915_gem_gtt.c | 109 drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_pm.c | 4 +- 5 files changed, 104 insertions(+), 28 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix open-coded DIV_ROUND_UP
On Sat, 19 Oct 2013, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Use the nice Kernel macro, it makes the code much more readable.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 34df59b..e7b39d7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -261,7 +261,7 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_mode_create_dumb *args)
{
/* have to work out size/pitch and return them */
- args-pitch = ALIGN(args-width * ((args-bpp + 7) / 8), 64);
+ args-pitch = ALIGN(args-width * DIV_ROUND_UP(args-bpp, 8), 64);
args-size = args-pitch * args-height;
return i915_gem_create(file, dev,
args-size, args-handle);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index acc8395..895fcb4 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -78,8 +78,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
mode_cmd.width = sizes-surface_width;
mode_cmd.height = sizes-surface_height;
- mode_cmd.pitches[0] = ALIGN(mode_cmd.width * ((sizes-surface_bpp + 7) /
- 8), 64);
+ mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
+ DIV_ROUND_UP(sizes-surface_bpp, 8), 64);
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes-surface_bpp,
sizes-surface_depth);
--
1.8.4.rc3
___
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 for 3.12/-fixes 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.
There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.
Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.
The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat May 4 10:09:18 2013 +0200
Revert drm/i915: revert eDP bpp clamping code changes
which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.
Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.
We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
Tested-by: Ulf Winkelvos u...@winkelvos.de
Tested-by: jkp j...@iki.fi
CC: sta...@vger.kernel.org
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c555f9..1a43137 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1401,6 +1401,26 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
else
pipe_config-port_clock = 27;
}
+
+ if (is_edp(intel_dp) dev_priv-vbt.edp_bpp
+ pipe_config-pipe_bpp dev_priv-vbt.edp_bpp) {
+ /*
+* This is a big fat ugly hack.
+*
+* Some machines in UEFI boot mode provide us a VBT that has 18
+* bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+* unknown we fail to light up. Yet the same BIOS boots up with
+* 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+* max, not what it tells us to use.
+*
+* Note: This will still be broken if the eDP panel is not lit
+* up by the BIOS, and thus we can't get the mode at module
+* load.
+*/
+ DRM_DEBUG_KMS(pipe has %d bpp for eDP panel, overriding
BIOS-provided max %d bpp\n,
+ pipe_config-pipe_bpp, dev_priv-vbt.edp_bpp);
+ dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
+ }
}
static bool is_edp_psr(struct intel_dp *intel_dp)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix open-coded DIV_ROUND_UP
On Mon, Oct 21, 2013 at 10:03:47AM +0300, Jani Nikula wrote: On Sat, 19 Oct 2013, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Use the nice Kernel macro, it makes the code much more readable. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Reviewed-by: Jani Nikula jani.nik...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Print RC6 info less often
On Sat, Oct 19, 2013 at 12:53:12PM +0100, Chris Wilson wrote: On Fri, Oct 18, 2013 at 12:32:07PM -0700, Ben Widawsky wrote: Since we use intel_enable_rc6() now for more than just when we're enabling RC6, we'll see this message many times, and it is just confusing. I agree. Ok, had to double check that i915.i915_enable_rc6 was not writable at runtime, so it looks like the defaults are fixed and so it is not possible for intel_enable_rc6() to return different values over its lifetime. As an example, calc_residency calls this function whenever poked via sysfs. This leaves the impression in dmesg that we're constantly re-enabling RC6. While at it, move the defines and description from drv.h to intel_pm.c, since these are only ever used in that code. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH for 3.12/-fixes 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue
On Mon, Oct 21, 2013 at 10:52:07AM +0300, Jani Nikula wrote: This isn't a real fix to the problem, but rather a stopgap measure while trying to find a proper solution. There are several laptops out there that fail to light up the eDP panel in UEFI boot mode. They seem to be mostly IVB machines, including but apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot. The difference between UEFI and CSM is that the BIOS provides a different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz link, and for reasons yet unknown fail to light up the panel. Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with 2.7 GHz link, the eDP panel lights up. So essentially this is a link speed issue, and *not* a bpp clamping issue. The bug raised its head since commit 657445fe8660100ad174600ebfa61536392b7624 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Sat May 4 10:09:18 2013 +0200 Revert drm/i915: revert eDP bpp clamping code changes which started clamping bpp *before* computing the link requirements, and thus affecting the required bandwidth. Clamping after the computations kept the link at 2.7 GHz. Even though the BIOS tells us to use 18 bpp through the VBT, it happily boots up at 24 bpp and 2.7 GHz itself! Use this information to selectively ignore the VBT provided value. We can't ignore the VBT eDP bpp altogether, as there are other laptops that do require the clamping to be used due to EDID reporting higher bpp than the panel can support. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950 Tested-by: Ulf Winkelvos u...@winkelvos.de Tested-by: jkp j...@iki.fi CC: sta...@vger.kernel.org Signed-off-by: Jani Nikula jani.nik...@intel.com Both merged to -fixes, thanks for the quick backport. I've added the note about we need the first patch to the commit message and also added the cc: stable tag. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Whitespace alignment fix for block header in display error state
The current output looks like:
Num Pipes: 2
Pipe [0]:
SRC: 027f01df
Plane [0]:
CNTR: d900
STRIDE: 1400
SIZE: 031f04ff
POS:
ADDR: 0002
Cursor [0]:
CNTR:
POS:
BASE:
Pipe [1]:
SRC: 04ff031f
Plane [1]:
CNTR: 0100
STRIDE:
SIZE: 018f02cf
POS:
ADDR:
Cursor [1]:
CNTR:
POS:
BASE:
CPU transcoder: A
CONF:
HTOTAL: 031f027f
HBLANK: 03170287
HSYNC: 02ef028f
VTOTAL: 020c01df
VBLANK: 020401e7
VSYNC: 01eb01e9
CPU transcoder: B
CONF: 8000
HTOTAL: 059f04ff
HBLANK: 059f04ff
HSYNC: 054f052f
VTOTAL: 0336031f
VBLANK: 0336031f
VSYNC: 03280322
which lacks the important visual clue to demarque the transcoder blocks
from the last cursor.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
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 05ac789ec773..6d91b9db63ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11156,7 +11156,7 @@ intel_display_print_error_state(struct
drm_i915_error_state_buf *m,
}
for (i = 0; i error-num_transcoders; i++) {
- err_printf(m, CPU transcoder: %c\n,
+ err_printf(m, CPU transcoder: %c\n,
transcoder_name(error-transcoder[i].cpu_transcoder));
err_printf(m, CONF: %08x\n, error-transcoder[i].conf);
err_printf(m, HTOTAL: %08x\n, error-transcoder[i].htotal);
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915 X crashes on 835GM (IBM R31)
Daniel, others, last Friday, I tried drm-intel-nightly on an IBM R31 Thinkpad. This also comes with a 835GM chipset (same as the Fujitsu), but the display is connected via LVDS and not via the NS2501 DVO. *) Panning also causes the flicker we know already. Interestingly, kernel 3.2.0-4 *does not* cause this flicker, it only flickers on the external screen, but not internally. Is there any way to read the i915 registers from the working 3.2.0-4 panning and compare that to what the drm-nightly kernel installs? Something must be different. *) If I connect an external monitor *before* turning the machine on, X creates a segfault. On this machine, no Xorg.conf exists and it is up to X to configure the screens correctly: X.Org X Server 1.12.4 Release Date: 2012-08-27 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian Current Operating System: Linux pike 3.12.0-rc5+ #1 SMP Fri Oct 18 19:44:00 CEST 2013 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.12.0-rc5+ root=UUID=b82e565b-91ce-41aa-bb56-7e7a7aabc436 ro single Build Date: 17 April 2013 11:13:16AM xorg-server 2:1.12.4-6 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.26.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Oct 21 10:02:04 2013 (==) Using system config directory /usr/share/X11/xorg.conf.d Fatal server error: AddScreen/ScreenInit failed for driver 0 Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. Backtrace: 0: X (xorg_backtrace+0x49) [0xb7791769] 1: X (0xb7614000+0x181186) [0xb7795186] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb75f540c] 3: X (0xb7614000+0x90d2d) [0xb76a4d2d] 4: X (AbortDDX+0x7d) [0xb76919ed] 5: X (0xb7614000+0x188cb1) [0xb779ccb1] 6: X (0xb7614000+0x188dd5) [0xb779cdd5] 7: X (InitOutput+0xf09) [0xb7693bf9] 8: X (0xb7614000+0x29cc6) [0xb763dcc6] 9: /lib/i386-linux-gnu/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb72abe46] 10: X (0xb7614000+0x2a1e9) [0xb763e1e9] Segmentation fault at address 0x84 Then, both screens go black and I can only reboot the machine. *) If I connect the external monitor *after* the kernel loaded the i915 module, X works, but I get no display on the external monitor: xrandr finds the monitor, though: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048 LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0* 800x60060.3 56.2 848x48060.0 640x48059.9 59.9 VGA1 connected (normal left inverted right x axis y axis) 1280x1024 60.0 + 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 640x48075.0 72.8 66.7 60.0 720x40070.1 but trying to enable it with any type of command (e.g. xrandr --output VGA1 --auto or xrandr --output VGA1 --mode 1280x1024) just returns an error: xrandr: cannot find crtc for output VGA1 I'm not sure what xrandr is trying to say here. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/vlv: enable HDMI audio for Valleyview2
From: Mengdong Lin mengdong@intel.com
This patch defines audio configuration registers and adds audio enabling code
for Valleyview2.
Signed-off-by: Mengdong Lin mengdong@intel.com
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9538502..04e5a8b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4844,6 +4844,18 @@
CPT_AUD_CNTL_ST_B)
#define CPT_AUD_CNTRL_ST2 0xE50C0
+#define VLV_HDMIW_HDMIEDID_A (VLV_DISPLAY_BASE + 0x62050)
+#define VLV_HDMIW_HDMIEDID_B (VLV_DISPLAY_BASE + 0x62150)
+#define VLV_HDMIW_HDMIEDID(pipe) _PIPE(pipe, \
+ VLV_HDMIW_HDMIEDID_A, \
+ VLV_HDMIW_HDMIEDID_B)
+#define VLV_AUD_CNTL_ST_A (VLV_DISPLAY_BASE + 0x620B4)
+#define VLV_AUD_CNTL_ST_B (VLV_DISPLAY_BASE + 0x621B4)
+#define VLV_AUD_CNTL_ST(pipe) _PIPE(pipe, \
+ VLV_AUD_CNTL_ST_A, \
+ VLV_AUD_CNTL_ST_B)
+#define VLV_AUD_CNTL_ST2 (VLV_DISPLAY_BASE + 0x620C0)
+
/* These are the 4 32-bit write offset registers for each stream
* output buffer. It determines the offset from the
* 3DSTATE_SO_BUFFERs that the next streamed vertex output goes to.
@@ -4860,6 +4872,12 @@
#define CPT_AUD_CFG(pipe) _PIPE(pipe, \
CPT_AUD_CONFIG_A, \
CPT_AUD_CONFIG_B)
+#define VLV_AUD_CONFIG_A 0x62000
+#define VLV_AUD_CONFIG_B 0x62100
+#define VLV_AUD_CFG(pipe) _PIPE(pipe, \
+ VLV_AUD_CONFIG_A, \
+ VLV_AUD_CONFIG_B)
+
#define AUD_CONFIG_N_VALUE_INDEX (1 29)
#define AUD_CONFIG_N_PROG_ENABLE (1 28)
#define AUD_CONFIG_UPPER_N_SHIFT 20
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe5d08..25abba96 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6896,6 +6896,11 @@ static void ironlake_write_eld(struct drm_connector
*connector,
aud_config = IBX_AUD_CFG(pipe);
aud_cntl_st = IBX_AUD_CNTL_ST(pipe);
aud_cntrl_st2 = IBX_AUD_CNTL_ST2;
+ } else if (IS_VALLEYVIEW(connector-dev)) {
+ hdmiw_hdmiedid = VLV_HDMIW_HDMIEDID(pipe);
+ aud_config = VLV_AUD_CFG(pipe);
+ aud_cntl_st = VLV_AUD_CNTL_ST(pipe);
+ aud_cntrl_st2 = VLV_AUD_CNTL_ST2;
} else {
hdmiw_hdmiedid = CPT_HDMIW_HDMIEDID(pipe);
aud_config = CPT_AUD_CFG(pipe);
@@ -6905,8 +6910,19 @@ static void ironlake_write_eld(struct drm_connector
*connector,
DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
- i = I915_READ(aud_cntl_st);
- i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select, 0x1
= PortB */
+ if (IS_VALLEYVIEW(connector-dev)) {
+ struct intel_encoder *intel_encoder;
+ int port = 0;
+ intel_encoder = intel_attached_encoder(connector);
+ if (intel_encoder)
+ port = intel_ddi_get_encoder_port(intel_encoder);
+ i = port;
+ } else {
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK;
+ /* DIP_Port_Select, 0x1 = PortB */
+ }
+
if (!i) {
DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
/* operate blindly on all ports */
@@ -10195,7 +10211,8 @@ static void intel_init_display(struct drm_device *dev)
}
} else if (IS_G4X(dev)) {
dev_priv-display.write_eld = g4x_write_eld;
- }
+ } else if (IS_VALLEYVIEW(dev))
+ dev_priv-display.write_eld = ironlake_write_eld;
/* Default just returns -ENODEV to indicate unsupported */
dev_priv-display.queue_flip = intel_default_queue_flip;
--
1.8.1.2
___
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: Wire up gen2 CRC support
On Fri, Oct 18, 2013 at 04:37:05PM +0200, Daniel Vetter wrote:
Really simple, and we don't even have working frame numbers.
v2: Actually enable it ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3f0980..3f4fd7c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,20 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+ uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE;
On gen3+ the border is always included in the crc. Maybe we should
always include it on gen2 as well?
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
enum intel_pipe_crc_source source,
uint32_t *val)
@@ -2039,7 +2053,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
u32 val;
int ret;
- if (!(INTEL_INFO(dev)-gen = 3 !IS_VALLEYVIEW(dev)))
+ if (IS_VALLEYVIEW(dev))
return -ENODEV;
if (pipe_crc-source == source)
@@ -2049,7 +2063,9 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
- if (INTEL_INFO(dev)-gen 5)
+ if (IS_GEN2(dev))
+ ret = i8xx_pipe_crc_ctl_reg(source, val);
+ else if (INTEL_INFO(dev)-gen 5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
--
1.8.4.rc3
___
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 11/16] drm/i915: Enable CRC interrupts on pre-gen5/vlv
On Wed, Oct 16, 2013 at 10:55:56PM +0200, Daniel Vetter wrote:
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b31e7ca..5c3baa0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2574,7 +2574,8 @@ static int valleyview_irq_postinstall(struct drm_device
*dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
u32 enable_mask;
- u32 pipestat_enable = PLANE_FLIP_DONE_INT_EN_VLV;
+ u32 pipestat_enable = PLANE_FLIP_DONE_INT_EN_VLV |
+ PIPE_CRC_DONE_ENABLE;
unsigned long irqflags;
enable_mask = I915_DISPLAY_PORT_INTERRUPT;
@@ -2697,6 +2698,7 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
static int i8xx_irq_postinstall(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+ unsigned long irqflags;
I915_WRITE16(EMR,
~(I915_ERROR_PAGE_TABLE | I915_ERROR_MEMORY_REFRESH));
@@ -2717,6 +2719,13 @@ static int i8xx_irq_postinstall(struct drm_device *dev)
I915_USER_INTERRUPT);
POSTING_READ16(IER);
+ /* Interrupt setup is already guaranteed to be single-threaded, this is
+ * just to make the assert_spin_locked check happy. */
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ i915_enable_pipestat(dev_priv, 0, PIPE_CRC_DONE_ENABLE);
+ i915_enable_pipestat(dev_priv, 1, PIPE_CRC_DONE_ENABLE);
Could use PIPE_A/B instead of raw numbers. Maybe a separate patch
to fix it all up since we're already using raw numbers in some
other places in i915_irq.c.
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
return 0;
}
@@ -2857,6 +2866,7 @@ static int i915_irq_postinstall(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
u32 enable_mask;
+ unsigned long irqflags;
I915_WRITE(EMR, ~(I915_ERROR_PAGE_TABLE | I915_ERROR_MEMORY_REFRESH));
@@ -2892,6 +2902,13 @@ static int i915_irq_postinstall(struct drm_device *dev)
i915_enable_asle_pipestat(dev);
+ /* Interrupt setup is already guaranteed to be single-threaded, this is
+ * just to make the assert_spin_locked check happy. */
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ i915_enable_pipestat(dev_priv, 0, PIPE_CRC_DONE_ENABLE);
+ i915_enable_pipestat(dev_priv, 1, PIPE_CRC_DONE_ENABLE);
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
return 0;
}
@@ -3105,6 +3122,8 @@ static int i965_irq_postinstall(struct drm_device *dev)
* just to make the assert_spin_locked check happy. */
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
i915_enable_pipestat(dev_priv, 0, PIPE_GMBUS_EVENT_ENABLE);
+ i915_enable_pipestat(dev_priv, 0, PIPE_CRC_DONE_ENABLE);
+ i915_enable_pipestat(dev_priv, 1, PIPE_CRC_DONE_ENABLE);
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
/*
--
1.8.4.rc3
___
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 12/16] drm/i915: Fix PIPE_CRC_CTL for vlv
On Wed, Oct 16, 2013 at 10:55:57PM +0200, Daniel Vetter wrote: The PIPE_B #define was missing the display mmio offset. Use the _PIPE_INC macro instead, it's simpler. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ad8fe21..4e0f0b7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1887,14 +1887,13 @@ #define _PIPE_CRC_RES_RES2_A_G4X (dev_priv-info-display_mmio_offset + 0x60080) /* Pipe B CRC regs */ -#define _PIPE_CRC_CTL_B 0x61050 #define _PIPE_CRC_RES_1_B_IVB0x61064 #define _PIPE_CRC_RES_2_B_IVB0x61068 #define _PIPE_CRC_RES_3_B_IVB0x6106c #define _PIPE_CRC_RES_4_B_IVB0x61070 #define _PIPE_CRC_RES_5_B_IVB0x61074 Maybe use _PIPE_INC() for these IVB regs as well. They're the only CRC regs left using _PIPE(), so they feel a bit out of place. -#define PIPE_CRC_CTL(pipe) _PIPE(pipe, _PIPE_CRC_CTL_A, _PIPE_CRC_CTL_B) +#define PIPE_CRC_CTL(pipe) _PIPE_INC(pipe, _PIPE_CRC_CTL_A, 0x01000) #define PIPE_CRC_RES_1_IVB(pipe) \ _PIPE(pipe, _PIPE_CRC_RES_1_A_IVB, _PIPE_CRC_RES_1_B_IVB) #define PIPE_CRC_RES_2_IVB(pipe) \ -- 1.8.4.rc3 ___ 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] [IGT PATCH 1/2] intel_opregion_decode: new tool for decoding graphics opregion
Thanks.
really odd, but if it was wrong you would probably already face other
errors even more odd ;)
So, all reviewed and merged up.
On Fri, Oct 18, 2013 at 6:08 AM, Jani Nikula jani.nik...@intel.com wrote:
On Thu, 17 Oct 2013, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Tue, Oct 8, 2013 at 3:18 PM, Jani Nikula jani.nik...@intel.com wrote:
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
tools/Makefile.am |1 +
tools/intel_opregion_decode.c | 438
+
2 files changed, 439 insertions(+)
create mode 100644 tools/intel_opregion_decode.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 19810cf..59fea97 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -13,6 +13,7 @@ bin_PROGRAMS =\
intel_gpu_top \
intel_gpu_time \
intel_gtt \
+ intel_opregion_decode \
intel_perf_counters \
intel_stepping \
intel_reg_checker \
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
new file mode 100644
index 000..e5f79df
--- /dev/null
+++ b/tools/intel_opregion_decode.c
@@ -0,0 +1,438 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
Software),
+ * to deal in the Software without restriction, including without
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
next
+ * paragraph) shall be included in all copies or substantial portions of
the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Jani Nikula jani.nik...@intel.com
+ *
+ */
+
+#include errno.h
+#include fcntl.h
+#include getopt.h
+#include stdint.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/mman.h
+#include sys/stat.h
+#include sys/types.h
+
+#include intel_gpu_tools.h
+
+#define OPREGION_HEADER_OFFSET 0
+#define OPREGION_ACPI_OFFSET 0x100
+#define OPREGION_SWSCI_OFFSET 0x200
+#define OPREGION_ASLE_OFFSET 0x300
+#define OPREGION_VBT_OFFSET0x400
+#define OPREGION_ASLE_EXT_OFFSET 0x1C00
+
+#define MBOX_ACPI (1 0)
+#define MBOX_SWSCI (1 1)
+#define MBOX_ASLE (1 2)
+#define MBOX_VBT (1 3)
+#define MBOX_ASLE_EXT (1 4)
+
+struct opregion_header {
+ char sign[16];
+ uint32_t size;
+ uint32_t over;
+ char sver[32];
+ char vver[16];
+ char gver[16];
+ uint32_t mbox;
+ uint32_t dmod;
+ uint32_t pcon;
+ char dver[32];
+ uint8_t rsv1[124];
+} __attribute__((packed));
+
+/* OpRegion mailbox #1: public ACPI methods */
+struct opregion_acpi {
+ uint32_t drdy; /* driver readiness */
+ uint32_t csts; /* notification status */
+ uint32_t cevt; /* current event */
+ uint8_t rsvd1[20];
+ uint32_t didl[8]; /* supported display devices ID list */
+ uint32_t cpdl[8]; /* currently presented display list */
+ uint32_t cadl[8]; /* currently active display list */
+ uint32_t nadl[8]; /* next active devices list */
+ uint32_t aslp; /* ASL sleep time-out */
+ uint32_t tidx; /* toggle table index */
+ uint32_t chpd; /* current hotplug enable indicator */
+ uint32_t clid; /* current lid state*/
+ uint32_t cdck; /* current docking state */
+ uint32_t sxsw; /* Sx state resume */
+ uint32_t evts; /* ASL supported events */
+ uint32_t cnot; /* current OS notification */
+ uint32_t nrdy; /* driver status */
+ uint32_t did2[7];
+ uint32_t cpd2[7];
+ uint8_t rsvd2[4];
+} __attribute__((packed));
+
+/* OpRegion mailbox #2: SWSCI */
+struct opregion_swsci {
+ uint32_t scic; /* SWSCI command|status|data */
+ uint32_t parm; /* command parameters
Re: [Intel-gfx] [PATCH 00/16] CRC support for non-ivb
On Wed, Oct 16, 2013 at 10:55:45PM +0200, Daniel Vetter wrote: Hi all, I've stitched together basic CRC support for non-ivb platforms. Still need to do a bit more testing on this, but ignoring bugs this should be it. We also need to pimp the igt testcase a bit so that it falls back to the new PIPE source if the PLANE1 source isn't available. Review and comments highly welcome. Apart from the three minor things I commented on, I couldn't find any real problems with the series. So the remainder of the series is: Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Cheers, Daniel Daniel Vetter (16): drm/i915: extract display_pipe_crc_update drm/i915: add CRC #defines for ilk/snb drm/i915: wire up CRC interrupt for ilk/snb drm/i915: use -get_vblank_counter for the crc frame counter drm/i915: wait one vblank when disabling CRCs drm/i915: fix CRC debugfs setup drm/i915: crc support for hsw drm/i915: Adjust CRC capture for pre-gen5/vlv drm/i915: CRC source selection #defines for gmch/vlv chips drm/i915: Wire up CRC interrupts for pre-gen5/vlv drm/i915: Enable CRC interrupts on pre-gen5/vlv drm/i915: Fix PIPE_CRC_CTL for vlv drm/i915: Add new CRC sources drm/i915: Wire up CRC support for gen3/4 drm/i915: Wire up gen2 CRC support drm/i915: Wire up CRC for vlv drivers/gpu/drm/i915/i915_debugfs.c | 164 +++- drivers/gpu/drm/i915/i915_drv.h | 6 ++ drivers/gpu/drm/i915/i915_irq.c | 151 + drivers/gpu/drm/i915/i915_reg.h | 74 +--- 4 files changed, 328 insertions(+), 67 deletions(-) -- 1.8.4.rc3 ___ 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
[Intel-gfx] [PATCH 0/4] drm/i915: Baytrail MIPI DSI support Updated
Hi All - These patches enhance the current support for MIPI DSI for Baytrail. They continue on the sub-encoder design and adds few more dev_ops to handle sequence correctly. Major changes are - 1. DSI Clock calculation based on pixel clock 2. Add new dev_ops for better sequencing the enable/disable path 3. Parameterized the hardcoded DSI parameters. These also forms building block for the generic MIPI driver to come in future based on enhancements in VBT. All these parameters are initialized or computed in the sub-encoder driver. Some of them might look unneccesary for now. I am also aware of the drm_bridge support now comming in and will in future migrate from sub-encoder design to drm_bridge. This DSI sequence has been validated with couple of test panels and is working now. Still no sub-encoder driver is included and this support will be mostly be disabled untill a panel sub-encoder driver is added. Proper detection or VBT is still pending. Regards Shobhit Shobhit Kumar (4): drm/i915: Add more dev ops for MIPI sub encoder drm/i915: Use FLISDSI interface for band gap reset drm/i915: Compute dsi_clk from pixel clock drm/i915: Parameterize the MIPI enabling sequnece and adjust the sequence drivers/gpu/drm/i915/i915_drv.h | 13 ++ drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_dsi.c | 378 + drivers/gpu/drm/i915/intel_dsi.h | 29 +++ drivers/gpu/drm/i915/intel_dsi_pll.c | 75 +-- drivers/gpu/drm/i915/intel_sideband.c | 14 ++ 6 files changed, 318 insertions(+), 192 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Add more dev ops for MIPI sub encoder
Also add new fields in intel_dsi to have all dphy related parameters.
These will be useful even when we go for pure generic MIPI design
Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c |9 -
drivers/gpu/drm/i915/intel_dsi.h | 29 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 9a2fdd2..34e19b7 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -147,6 +147,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
DRM_DEBUG_KMS(\n);
+ if (intel_dsi-dev.dev_ops-panel_reset)
+ intel_dsi-dev.dev_ops-panel_reset(intel_dsi-dev);
+
temp = I915_READ(MIPI_DEVICE_READY(pipe));
if ((temp DEVICE_READY) == 0) {
temp = ~ULPS_STATE_MASK;
@@ -162,6 +165,9 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
I915_WRITE(MIPI_DEVICE_READY(pipe), temp);
}
+ if (intel_dsi-dev.dev_ops-send_otp_cmds)
+ intel_dsi-dev.dev_ops-send_otp_cmds(intel_dsi-dev);
+
if (is_cmd_mode(intel_dsi))
I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(pipe), 8 * 4);
@@ -176,7 +182,8 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
POSTING_READ(MIPI_PORT_CTRL(pipe));
}
- intel_dsi-dev.dev_ops-enable(intel_dsi-dev);
+ if (intel_dsi-dev.dev_ops-enable)
+ intel_dsi-dev.dev_ops-enable(intel_dsi-dev);
}
static void intel_dsi_disable(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index c7765f3..b71c9b3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -39,6 +39,13 @@ struct intel_dsi_device {
struct intel_dsi_dev_ops {
bool (*init)(struct intel_dsi_device *dsi);
+ void (*panel_reset)(struct intel_dsi_device *dsi);
+
+ void (*disable_panel_power)(struct intel_dsi_device *dsi);
+
+ /* send one time programmable commands */
+ void (*send_otp_cmds)(struct intel_dsi_device *dsi);
+
/* This callback must be able to assume DSI commands can be sent */
void (*enable)(struct intel_dsi_device *dsi);
@@ -89,6 +96,28 @@ struct intel_dsi {
/* eot for MIPI_EOT_DISABLE register */
u32 eot_disable;
+
+ u16 dsi_clock_freq;
+ u8 video_mode_type;
+ u32 data_width;
+ u8 dither;
+ u32 port_bits;
+ u8 escape_clk_div;
+ u32 lp_rx_timeout;
+ u8 turn_arnd_val;
+ u16 init_count;
+ u16 rst_timer_val;
+ u16 hs_to_lp_count;
+ u16 lp_byte_clk;
+ u32 bw_timer;
+ u16 clk_lp_to_hs_count;
+ u16 clk_hs_to_lp_count;
+ u32 video_frmt_cfg_bits;
+ u32 dphy_reg;
+
+ u8 backlight_off_delay; /*in ms*/
+ bool send_shutdown;
+ u8 shutdown_pkt_delay; /*in ms*/
};
static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: Use FLISDSI interface for band gap reset
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 47 ++---
drivers/gpu/drm/i915/intel_sideband.c | 14 ++
4 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index faf4dc1..1c42bb4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2334,6 +2334,8 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16
reg,
enum intel_sbi_destination destination);
void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
enum intel_sbi_destination destination);
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
int vlv_gpu_freq(int ddr_freq, int val);
int vlv_freq_opcode(int ddr_freq, int val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 852d3c4..172f490 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -355,6 +355,7 @@
#define IOSF_PORT_CCK0x14
#define IOSF_PORT_CCU0xA9
#define IOSF_PORT_GPS_CORE 0x48
+#define IOSF_PORT_FLISDSI0x1B
#define VLV_IOSF_DATA (VLV_DISPLAY_BASE + 0x2104)
#define VLV_IOSF_ADDR (VLV_DISPLAY_BASE + 0x2108)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 34e19b7..5a9dbfd 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -37,49 +37,18 @@
static const struct intel_dsi_device intel_dsi_devices[] = {
};
-
-static void vlv_cck_modify(struct drm_i915_private *dev_priv, u32 reg, u32 val,
- u32 mask)
-{
- u32 tmp = vlv_cck_read(dev_priv, reg);
- tmp = ~mask;
- tmp |= val;
- vlv_cck_write(dev_priv, reg, tmp);
-}
-
-static void band_gap_wa(struct drm_i915_private *dev_priv)
+static void band_gap_reset(struct drm_i915_private *dev_priv)
{
mutex_lock(dev_priv-dpio_lock);
- /* Enable bandgap fix in GOP driver */
- vlv_cck_modify(dev_priv, 0x6D, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x8000, 0x8000);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x, 0x8000);
- msleep(20);
-
- /* Turn Display Trunk on */
- vlv_cck_modify(dev_priv, 0x6B, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6C, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6D, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0002, 0x0003);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x0001);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0005);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0025);
+ udelay(150);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x);
mutex_unlock(dev_priv-dpio_lock);
-
- /* Need huge delay, otherwise clock is not stable */
- msleep(100);
}
static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
@@ -363,7 +332,7 @@ static void intel_dsi_mode_set(struct intel_encoder
*intel_encoder)
vlv_enable_dsi_pll(intel_encoder);
/* XXX: Location of the call */
- band_gap_wa(dev_priv);
+ band_gap_reset(dev_priv);
/* escape clock divider, 20MHz, shared for A and C. device ready must be
* off when doing this! txclkesc? */
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index acd1cfe..e3f5210 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -239,3 +239,17 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
return;
}
}
+
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI,
+ DPIO_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+{
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI,
+ DPIO_OPCODE_REG_WRITE, reg, val);
+}
--
[Intel-gfx] [PATCH 4/4] drm/i915: Parameterize the MIPI enabling sequnece and adjust the sequence
Has been tested on couple of panels now.
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Vijaykumar Balakrishnan vijayakumar.balakrish...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++
drivers/gpu/drm/i915/intel_dsi.c | 334 +-
2 files changed, 199 insertions(+), 146 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1c42bb4..1c28d02 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2375,6 +2375,17 @@ __i915_write(64)
#define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
+#define I915_WRITE_BITS(reg, val, mask) \
+do { \
+ u32 tmp, data; \
+ tmp = I915_READ((reg)); \
+ tmp = ~(mask); \
+ data = (val) (mask); \
+ data = data | tmp; \
+ I915_WRITE((reg), data); \
+} while(0)
+
+
/* Broadcast RGB property */
#define INTEL_BROADCAST_RGB_AUTO 0
#define INTEL_BROADCAST_RGB_FULL 1
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5a9dbfd..241bb55 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -21,6 +21,8 @@
* DEALINGS IN THE SOFTWARE.
*
* Author: Jani Nikula jani.nik...@intel.com
+ * : Shobhit Kumar shobhit.ku...@intel.com
+ * : Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
*/
#include drm/drmP.h
@@ -101,63 +103,80 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder
*encoder)
vlv_enable_dsi_pll(encoder);
}
-static void intel_dsi_pre_enable(struct intel_encoder *encoder)
-{
- DRM_DEBUG_KMS(\n);
-}
-
-static void intel_dsi_enable(struct intel_encoder *encoder)
+void intel_dsi_device_ready(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
int pipe = intel_crtc-pipe;
- u32 temp;
DRM_DEBUG_KMS(\n);
if (intel_dsi-dev.dev_ops-panel_reset)
intel_dsi-dev.dev_ops-panel_reset(intel_dsi-dev);
- temp = I915_READ(MIPI_DEVICE_READY(pipe));
- if ((temp DEVICE_READY) == 0) {
- temp = ~ULPS_STATE_MASK;
- I915_WRITE(MIPI_DEVICE_READY(pipe), temp | DEVICE_READY);
- } else if (temp ULPS_STATE_MASK) {
- temp = ~ULPS_STATE_MASK;
- I915_WRITE(MIPI_DEVICE_READY(pipe), temp | ULPS_STATE_EXIT);
- /*
-* We need to ensure that there is a minimum of 1 ms time
-* available before clearing the UPLS exit state.
-*/
- msleep(2);
- I915_WRITE(MIPI_DEVICE_READY(pipe), temp);
- }
+ I915_WRITE_BITS(MIPI_PORT_CTRL(pipe), LP_OUTPUT_HOLD, LP_OUTPUT_HOLD);
+ usleep_range(1000, 1500);
+ I915_WRITE_BITS(MIPI_DEVICE_READY(pipe), DEVICE_READY |
+ ULPS_STATE_EXIT, DEVICE_READY | ULPS_STATE_MASK);
+ usleep_range(2000, 2500);
+ I915_WRITE_BITS(MIPI_DEVICE_READY(pipe), DEVICE_READY,
+ DEVICE_READY | ULPS_STATE_MASK);
+ usleep_range(2000, 2500);
+ I915_WRITE_BITS(MIPI_DEVICE_READY(pipe), 0x00,
+ DEVICE_READY | ULPS_STATE_MASK);
+ usleep_range(2000, 2500);
+ I915_WRITE_BITS(MIPI_DEVICE_READY(pipe), DEVICE_READY,
+ DEVICE_READY | ULPS_STATE_MASK);
+ usleep_range(2000, 2500);
if (intel_dsi-dev.dev_ops-send_otp_cmds)
intel_dsi-dev.dev_ops-send_otp_cmds(intel_dsi-dev);
+}
+static void intel_dsi_pre_enable(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+
+ /* put device in ready state */
+ intel_dsi_device_ready(encoder);
+}
+
+static void intel_dsi_enable(struct intel_encoder *encoder)
+{
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ int pipe = intel_crtc-pipe;
+ u32 temp;
+
+ DRM_DEBUG_KMS(\n);
+
if (is_cmd_mode(intel_dsi))
I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(pipe), 8 * 4);
-
- if (is_vid_mode(intel_dsi)) {
+ else {
msleep(20); /* XXX */
dpi_send_cmd(intel_dsi, TURN_ON);
msleep(100);
/* assert ip_tg_enable signal */
temp = I915_READ(MIPI_PORT_CTRL(pipe));
+ temp = temp | intel_dsi-port_bits;
I915_WRITE(MIPI_PORT_CTRL(pipe), temp | DPI_ENABLE);
POSTING_READ(MIPI_PORT_CTRL(pipe));
}
[Intel-gfx] [PATCH 3/4] drm/i915: Compute dsi_clk from pixel clock
Minor modification to m_n_p calculations as well
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 75 --
1 file changed, 63 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 44279b2..bf12335 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,6 +50,8 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
+#ifdef DSI_CLK_FROM_RR
+
static u32 dsi_rr_formula(const struct drm_display_mode *mode,
int pixel_format, int video_mode_format,
int lane_count, bool eotp)
@@ -129,6 +131,40 @@ static u32 dsi_rr_formula(const struct drm_display_mode
*mode,
return dsi_clk;
}
+#else
+
+/* Get DSI clock from pixel clock */
+static u32 dsi_clk_from_pclk(const struct drm_display_mode *mode,
+ int pixel_format, int lane_count)
+{
+ u32 dsi_bit_clock_hz, dsi_clk;
+ u32 bpp;
+
+ switch (pixel_format) {
+ default:
+ case VID_MODE_FORMAT_RGB888:
+ case VID_MODE_FORMAT_RGB666_LOOSE:
+ bpp = 24;
+ break;
+ case VID_MODE_FORMAT_RGB666:
+ bpp = 18;
+ break;
+ case VID_MODE_FORMAT_RGB565:
+ bpp = 16;
+ break;
+ }
+
+ /* DSI data rate = pixel clock * bits per pixel / lane count
+ pixel clock is converted from KHz to Hz */
+ dsi_bit_clock_hz = (((mode-clock * 1000) * bpp) / lane_count);
+
+ /* DSI clock rate */
+ dsi_clk = dsi_bit_clock_hz / (1000 * 1000);
+ return dsi_clk;
+}
+
+#endif
+
#ifdef MNP_FROM_TABLE
struct dsi_clock_table {
@@ -208,29 +244,42 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp
*dsi_mnp)
ref_clk = 25000;
target_dsi_clk = dsi_clk * 1000;
error = 0x;
+ tmp_error = 0x;
calc_m = 0;
calc_p = 0;
for (m = 62; m = 92; m++) {
for (p = 2; p = 6; p++) {
-
+ /* Find the optimal m and p divisors
+ with minimal error +/- the required clock */
calc_dsi_clk = (m * ref_clk) / p;
- if (calc_dsi_clk = target_dsi_clk) {
+ if (calc_dsi_clk == target_dsi_clk) {
+ calc_m = m;
+ calc_p = p;
+ error = 0;
+ break;
+ } else if (calc_dsi_clk target_dsi_clk)
tmp_error = calc_dsi_clk - target_dsi_clk;
- if (tmp_error error) {
- error = tmp_error;
- calc_m = m;
- calc_p = p;
- }
+ else
+ tmp_error = target_dsi_clk - calc_dsi_clk;
+
+ if (tmp_error error) {
+ error = tmp_error;
+ calc_m = m;
+ calc_p = p;
}
}
+
+ if (error == 0)
+ break;
}
m_seed = lfsr_converts[calc_m - 62];
n = 1;
+
dsi_mnp-dsi_pll_ctrl = 1 (DSI_PLL_P1_POST_DIV_SHIFT + calc_p - 2);
dsi_mnp-dsi_pll_div = (n - 1) DSI_PLL_N1_DIV_SHIFT |
- m_seed DSI_PLL_M1_DIV_SHIFT;
+ m_seed DSI_PLL_M1_DIV_SHIFT;
return 0;
}
@@ -249,11 +298,13 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
int ret;
struct dsi_mnp dsi_mnp;
- u32 dsi_clk;
+ u32 dsi_clk = 0;
- dsi_clk = dsi_rr_formula(mode, intel_dsi-pixel_format,
-intel_dsi-video_mode_format,
-intel_dsi-lane_count,
!intel_dsi-eot_disable);
+ if (intel_dsi-dsi_clock_freq)
+ dsi_clk = intel_dsi-dsi_clock_freq;
+ else
+ dsi_clk = dsi_clk_from_pclk(mode, intel_dsi-pixel_format,
+ intel_dsi-lane_count);
ret = dsi_calc_mnp(dsi_clk, dsi_mnp);
if (ret) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915 X crashes on 835GM (IBM R31)
On Mon, Oct 21, 2013 at 10:12:07AM +0200, Thomas Richter wrote: Daniel, others, last Friday, I tried drm-intel-nightly on an IBM R31 Thinkpad. This also comes with a 835GM chipset (same as the Fujitsu), but the display is connected via LVDS and not via the NS2501 DVO. *) Panning also causes the flicker we know already. Interestingly, kernel 3.2.0-4 *does not* cause this flicker, it only flickers on the external screen, but not internally. Is there any way to read the i915 registers from the working 3.2.0-4 panning and compare that to what the drm-nightly kernel installs? Something must be different. *) If I connect an external monitor *before* turning the machine on, X creates a segfault. On this machine, no Xorg.conf exists and it is up to X to configure the screens correctly: A full drm.debug=6 dmesg, Xorg.0.log and xrandr --verbose would be useful starting point to distangling what is going on. Is this an 830gm or an 845g? google says 830gm, so there should be 2 crtcs available for you to drive the two outputs independently, and we need to find out what is going wrong. -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 1/4] drm/i915: Add more dev ops for MIPI sub encoder
Hi Shobhit -
On Mon, 21 Oct 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Also add new fields in intel_dsi to have all dphy related parameters.
These will be useful even when we go for pure generic MIPI design
I feel like we have a different idea of what the ideal generic design
is. For me, the goal is that we change the struct intel_dsi_device to
struct drm_bridge, and those drm_bridge drivers are all about the panel,
and have as few details about i915 or our hardware as possible. Having
the bridge drivers fill in register values to be written by the core DSI
code does not fit that. Yes, I had some of those in my bridge conversion
patches too, but I did not intend we'd keep adding more.
I'd rather we provide generic helpers the bridge driver can call.
Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c |9 -
drivers/gpu/drm/i915/intel_dsi.h | 29 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 9a2fdd2..34e19b7 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -147,6 +147,9 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS(\n);
+ if (intel_dsi-dev.dev_ops-panel_reset)
+ intel_dsi-dev.dev_ops-panel_reset(intel_dsi-dev);
Would this map to -pre_enable in drm_bridge?
+
temp = I915_READ(MIPI_DEVICE_READY(pipe));
if ((temp DEVICE_READY) == 0) {
temp = ~ULPS_STATE_MASK;
@@ -162,6 +165,9 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
I915_WRITE(MIPI_DEVICE_READY(pipe), temp);
}
+ if (intel_dsi-dev.dev_ops-send_otp_cmds)
+ intel_dsi-dev.dev_ops-send_otp_cmds(intel_dsi-dev);
What is otp? one time programming? Why not in -enable?
+
if (is_cmd_mode(intel_dsi))
I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(pipe), 8 * 4);
@@ -176,7 +182,8 @@ static void intel_dsi_enable(struct intel_encoder
*encoder)
POSTING_READ(MIPI_PORT_CTRL(pipe));
}
- intel_dsi-dev.dev_ops-enable(intel_dsi-dev);
+ if (intel_dsi-dev.dev_ops-enable)
+ intel_dsi-dev.dev_ops-enable(intel_dsi-dev);
}
static void intel_dsi_disable(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h
b/drivers/gpu/drm/i915/intel_dsi.h
index c7765f3..b71c9b3 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -39,6 +39,13 @@ struct intel_dsi_device {
struct intel_dsi_dev_ops {
bool (*init)(struct intel_dsi_device *dsi);
+ void (*panel_reset)(struct intel_dsi_device *dsi);
+
+ void (*disable_panel_power)(struct intel_dsi_device *dsi);
What is the enabling counterpart to disable_panel_power? panel_reset?
+
+ /* send one time programmable commands */
+ void (*send_otp_cmds)(struct intel_dsi_device *dsi);
+
/* This callback must be able to assume DSI commands can be sent */
void (*enable)(struct intel_dsi_device *dsi);
@@ -89,6 +96,28 @@ struct intel_dsi {
/* eot for MIPI_EOT_DISABLE register */
u32 eot_disable;
+
+ u16 dsi_clock_freq;
+ u8 video_mode_type;
+ u32 data_width;
+ u8 dither;
+ u32 port_bits;
+ u8 escape_clk_div;
+ u32 lp_rx_timeout;
+ u8 turn_arnd_val;
+ u16 init_count;
+ u16 rst_timer_val;
+ u16 hs_to_lp_count;
+ u16 lp_byte_clk;
+ u32 bw_timer;
+ u16 clk_lp_to_hs_count;
+ u16 clk_hs_to_lp_count;
+ u32 video_frmt_cfg_bits;
+ u32 dphy_reg;
+
+ u8 backlight_off_delay; /*in ms*/
+ bool send_shutdown;
+ u8 shutdown_pkt_delay; /*in ms*/
};
static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
--
1.7.9.5
--
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 3/4] drm/i915: Compute dsi_clk from pixel clock
On Mon, Oct 21, 2013 at 05:51:06PM +0530, Shobhit Kumar wrote:
Minor modification to m_n_p calculations as well
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 75
--
1 file changed, 63 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 44279b2..bf12335 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,6 +50,8 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
+#ifdef DSI_CLK_FROM_RR
+
static u32 dsi_rr_formula(const struct drm_display_mode *mode,
int pixel_format, int video_mode_format,
int lane_count, bool eotp)
@@ -129,6 +131,40 @@ static u32 dsi_rr_formula(const struct drm_display_mode
*mode,
return dsi_clk;
}
+#else
+
+/* Get DSI clock from pixel clock */
+static u32 dsi_clk_from_pclk(const struct drm_display_mode *mode,
+ int pixel_format, int lane_count)
+{
+ u32 dsi_bit_clock_hz, dsi_clk;
+ u32 bpp;
+
+ switch (pixel_format) {
+ default:
+ case VID_MODE_FORMAT_RGB888:
+ case VID_MODE_FORMAT_RGB666_LOOSE:
+ bpp = 24;
+ break;
+ case VID_MODE_FORMAT_RGB666:
+ bpp = 18;
+ break;
+ case VID_MODE_FORMAT_RGB565:
+ bpp = 16;
+ break;
+ }
+
+ /* DSI data rate = pixel clock * bits per pixel / lane count
+pixel clock is converted from KHz to Hz */
+ dsi_bit_clock_hz = (((mode-clock * 1000) * bpp) / lane_count);
+
+ /* DSI clock rate */
+ dsi_clk = dsi_bit_clock_hz / (1000 * 1000);
+ return dsi_clk;
And why is this better than the rr_formula thing that tries to
account for the packetization overhead?
Also I don't understand why you go from kHz to Hz and then to MHz.
I'd just do something like:
return DIV_ROUND_CLOSEST(mode-clock * bpp, lane_count);
and then change the rest of the code to work in kHz as well.
+}
+
+#endif
+
#ifdef MNP_FROM_TABLE
struct dsi_clock_table {
@@ -208,29 +244,42 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp
*dsi_mnp)
ref_clk = 25000;
target_dsi_clk = dsi_clk * 1000;
error = 0x;
+ tmp_error = 0x;
calc_m = 0;
calc_p = 0;
for (m = 62; m = 92; m++) {
for (p = 2; p = 6; p++) {
-
+ /* Find the optimal m and p divisors
+ with minimal error +/- the required clock */
calc_dsi_clk = (m * ref_clk) / p;
- if (calc_dsi_clk = target_dsi_clk) {
+ if (calc_dsi_clk == target_dsi_clk) {
+ calc_m = m;
+ calc_p = p;
+ error = 0;
+ break;
+ } else if (calc_dsi_clk target_dsi_clk)
tmp_error = calc_dsi_clk - target_dsi_clk;
- if (tmp_error error) {
- error = tmp_error;
- calc_m = m;
- calc_p = p;
- }
+ else
+ tmp_error = target_dsi_clk - calc_dsi_clk;
+
+ if (tmp_error error) {
+ error = tmp_error;
+ calc_m = m;
+ calc_p = p;
}
}
+
+ if (error == 0)
+ break;
}
m_seed = lfsr_converts[calc_m - 62];
n = 1;
+
dsi_mnp-dsi_pll_ctrl = 1 (DSI_PLL_P1_POST_DIV_SHIFT + calc_p - 2);
dsi_mnp-dsi_pll_div = (n - 1) DSI_PLL_N1_DIV_SHIFT |
- m_seed DSI_PLL_M1_DIV_SHIFT;
+ m_seed DSI_PLL_M1_DIV_SHIFT;
return 0;
}
@@ -249,11 +298,13 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
int ret;
struct dsi_mnp dsi_mnp;
- u32 dsi_clk;
+ u32 dsi_clk = 0;
- dsi_clk = dsi_rr_formula(mode, intel_dsi-pixel_format,
- intel_dsi-video_mode_format,
- intel_dsi-lane_count,
!intel_dsi-eot_disable);
+ if (intel_dsi-dsi_clock_freq)
+ dsi_clk = intel_dsi-dsi_clock_freq;
+ else
+ dsi_clk = dsi_clk_from_pclk(mode, intel_dsi-pixel_format,
+ intel_dsi-lane_count);
ret = dsi_calc_mnp(dsi_clk, dsi_mnp);
if (ret) {
--
1.7.9.5
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use FLISDSI interface for band gap reset
Hmm, I don't think I have the spec for this one. So did not check the
values, but overall the code looks good.
With the above limitation,
Reviewed-by: Jani Nikula jani.nik...@intel.com
On Mon, 21 Oct 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 47
++---
drivers/gpu/drm/i915/intel_sideband.c | 14 ++
4 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index faf4dc1..1c42bb4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2334,6 +2334,8 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv,
u16 reg,
enum intel_sbi_destination destination);
void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
enum intel_sbi_destination destination);
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
int vlv_gpu_freq(int ddr_freq, int val);
int vlv_freq_opcode(int ddr_freq, int val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 852d3c4..172f490 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -355,6 +355,7 @@
#define IOSF_PORT_CCK 0x14
#define IOSF_PORT_CCU 0xA9
#define IOSF_PORT_GPS_CORE 0x48
+#define IOSF_PORT_FLISDSI 0x1B
#define VLV_IOSF_DATA(VLV_DISPLAY_BASE +
0x2104)
#define VLV_IOSF_ADDR(VLV_DISPLAY_BASE +
0x2108)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 34e19b7..5a9dbfd 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -37,49 +37,18 @@
static const struct intel_dsi_device intel_dsi_devices[] = {
};
-
-static void vlv_cck_modify(struct drm_i915_private *dev_priv, u32 reg, u32
val,
-u32 mask)
-{
- u32 tmp = vlv_cck_read(dev_priv, reg);
- tmp = ~mask;
- tmp |= val;
- vlv_cck_write(dev_priv, reg, tmp);
-}
-
-static void band_gap_wa(struct drm_i915_private *dev_priv)
+static void band_gap_reset(struct drm_i915_private *dev_priv)
{
mutex_lock(dev_priv-dpio_lock);
- /* Enable bandgap fix in GOP driver */
- vlv_cck_modify(dev_priv, 0x6D, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x8000, 0x8000);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x, 0x8000);
- msleep(20);
-
- /* Turn Display Trunk on */
- vlv_cck_modify(dev_priv, 0x6B, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6C, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6D, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0002, 0x0003);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x0001);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0005);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0025);
+ udelay(150);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x);
mutex_unlock(dev_priv-dpio_lock);
-
- /* Need huge delay, otherwise clock is not stable */
- msleep(100);
}
static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
@@ -363,7 +332,7 @@ static void intel_dsi_mode_set(struct intel_encoder
*intel_encoder)
vlv_enable_dsi_pll(intel_encoder);
/* XXX: Location of the call */
- band_gap_wa(dev_priv);
+ band_gap_reset(dev_priv);
/* escape clock divider, 20MHz, shared for A and C. device ready must be
* off when doing this! txclkesc? */
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index acd1cfe..e3f5210 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -239,3 +239,17 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
return;
}
}
+
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI,
+
[Intel-gfx] [PATCH v4] drm/i915: Use a spin lock to protect the pipe crc struct
Daniel pointed out that it was hard to get anything lockless to work
correctly, so don't even try for this non critical piece of code and
just use a spin lock.
v2: Make intel_pipe_crc-opened a bool
v3: Use assert_spin_locked() instead of a comment (Daniel Vetter)
v4: Use spin_lock_irq() in the debugfs functions (they can only be
called from process context),
Use spin_lock() in the pipe_crc_update() function that can only be
called from an interrupt handler,
Use wait_event_interruptible_lock_irq() when waiting for data in the
cicular buffer to ensure proper locking around the condition we are
waiting for. (Daniel Vetter)
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 66 ++---
drivers/gpu/drm/i915/i915_drv.h | 5 +--
drivers/gpu/drm/i915/i915_irq.c | 12 +--
3 files changed, 58 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..fd80064 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,13 +1772,18 @@ static int i915_pipe_crc_open(struct inode *inode,
struct file *filep)
struct drm_i915_private *dev_priv = info-dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[info-pipe];
- if (!atomic_dec_and_test(pipe_crc-available)) {
- atomic_inc(pipe_crc-available);
+ spin_lock_irq(pipe_crc-lock);
+
+ if (pipe_crc-opened) {
+ spin_unlock_irq(pipe_crc-lock);
return -EBUSY; /* already open */
}
+ pipe_crc-opened = true;
filep-private_data = inode-i_private;
+ spin_unlock_irq(pipe_crc-lock);
+
return 0;
}
@@ -1788,7 +1793,9 @@ static int i915_pipe_crc_release(struct inode *inode,
struct file *filep)
struct drm_i915_private *dev_priv = info-dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[info-pipe];
- atomic_inc(pipe_crc-available); /* release the device */
+ spin_lock_irq(pipe_crc-lock);
+ pipe_crc-opened = false;
+ spin_unlock_irq(pipe_crc-lock);
return 0;
}
@@ -1800,12 +1807,9 @@ static int i915_pipe_crc_release(struct inode *inode,
struct file *filep)
static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
{
- int head, tail;
-
- head = atomic_read(pipe_crc-head);
- tail = atomic_read(pipe_crc-tail);
-
- return CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR);
+ assert_spin_locked(pipe_crc-lock);
+ return CIRC_CNT(pipe_crc-head, pipe_crc-tail,
+ INTEL_PIPE_CRC_ENTRIES_NR);
}
static ssize_t
@@ -1831,20 +1835,30 @@ i915_pipe_crc_read(struct file *filep, char __user
*user_buf, size_t count,
return 0;
/* nothing to read */
+ spin_lock_irq(pipe_crc-lock);
while (pipe_crc_data_count(pipe_crc) == 0) {
- if (filep-f_flags O_NONBLOCK)
+ int ret;
+
+ if (filep-f_flags O_NONBLOCK) {
+ spin_unlock_irq(pipe_crc-lock);
return -EAGAIN;
+ }
- if (wait_event_interruptible(pipe_crc-wq,
-pipe_crc_data_count(pipe_crc)))
-return -ERESTARTSYS;
+ ret = wait_event_interruptible_lock_irq(pipe_crc-wq,
+ pipe_crc_data_count(pipe_crc), pipe_crc-lock);
+ if (ret) {
+ spin_unlock_irq(pipe_crc-lock);
+ return ret;
+ }
}
/* We now have one or more entries to read */
- head = atomic_read(pipe_crc-head);
- tail = atomic_read(pipe_crc-tail);
+ head = pipe_crc-head;
+ tail = pipe_crc-tail;
n_entries = min((size_t)CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR),
count / PIPE_CRC_LINE_LEN);
+ spin_unlock_irq(pipe_crc-lock);
+
bytes_read = 0;
n = 0;
do {
@@ -1864,10 +1878,13 @@ i915_pipe_crc_read(struct file *filep, char __user
*user_buf, size_t count,
BUILD_BUG_ON_NOT_POWER_OF_2(INTEL_PIPE_CRC_ENTRIES_NR);
tail = (tail + 1) (INTEL_PIPE_CRC_ENTRIES_NR - 1);
- atomic_set(pipe_crc-tail, tail);
n++;
} while (--n_entries);
+ spin_lock_irq(pipe_crc-lock);
+ pipe_crc-tail = tail;
+ spin_unlock_irq(pipe_crc-lock);
+
return bytes_read;
}
@@ -2026,8 +2043,10 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (!pipe_crc-entries)
return -ENOMEM;
- atomic_set(pipe_crc-head, 0);
- atomic_set(pipe_crc-tail, 0);
+
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Compute dsi_clk from pixel clock
On Mon, 21 Oct 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Minor modification to m_n_p calculations as well
That should probably be a separate patch, unless it's a requirement for
what the main subject of this patch is. The commit message does not say.
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 75
--
1 file changed, 63 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 44279b2..bf12335 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,6 +50,8 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
+#ifdef DSI_CLK_FROM_RR
+
static u32 dsi_rr_formula(const struct drm_display_mode *mode,
int pixel_format, int video_mode_format,
int lane_count, bool eotp)
@@ -129,6 +131,40 @@ static u32 dsi_rr_formula(const struct drm_display_mode
*mode,
return dsi_clk;
}
+#else
+
+/* Get DSI clock from pixel clock */
+static u32 dsi_clk_from_pclk(const struct drm_display_mode *mode,
+ int pixel_format, int lane_count)
+{
+ u32 dsi_bit_clock_hz, dsi_clk;
+ u32 bpp;
+
+ switch (pixel_format) {
+ default:
+ case VID_MODE_FORMAT_RGB888:
+ case VID_MODE_FORMAT_RGB666_LOOSE:
+ bpp = 24;
+ break;
+ case VID_MODE_FORMAT_RGB666:
+ bpp = 18;
+ break;
+ case VID_MODE_FORMAT_RGB565:
+ bpp = 16;
+ break;
+ }
+
+ /* DSI data rate = pixel clock * bits per pixel / lane count
+pixel clock is converted from KHz to Hz */
+ dsi_bit_clock_hz = (((mode-clock * 1000) * bpp) / lane_count);
+
+ /* DSI clock rate */
+ dsi_clk = dsi_bit_clock_hz / (1000 * 1000);
+ return dsi_clk;
+}
+
+#endif
+
#ifdef MNP_FROM_TABLE
struct dsi_clock_table {
@@ -208,29 +244,42 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp
*dsi_mnp)
ref_clk = 25000;
target_dsi_clk = dsi_clk * 1000;
error = 0x;
+ tmp_error = 0x;
calc_m = 0;
calc_p = 0;
for (m = 62; m = 92; m++) {
for (p = 2; p = 6; p++) {
-
+ /* Find the optimal m and p divisors
+ with minimal error +/- the required clock */
calc_dsi_clk = (m * ref_clk) / p;
- if (calc_dsi_clk = target_dsi_clk) {
+ if (calc_dsi_clk == target_dsi_clk) {
+ calc_m = m;
+ calc_p = p;
+ error = 0;
+ break;
+ } else if (calc_dsi_clk target_dsi_clk)
tmp_error = calc_dsi_clk - target_dsi_clk;
- if (tmp_error error) {
- error = tmp_error;
- calc_m = m;
- calc_p = p;
- }
+ else
+ tmp_error = target_dsi_clk - calc_dsi_clk;
+
Using abs() might clean this up a bit.
+ if (tmp_error error) {
+ error = tmp_error;
+ calc_m = m;
+ calc_p = p;
}
}
+
+ if (error == 0)
+ break;
The above changes should be a separate patch, with rationale in the
commit message.
}
m_seed = lfsr_converts[calc_m - 62];
n = 1;
+
dsi_mnp-dsi_pll_ctrl = 1 (DSI_PLL_P1_POST_DIV_SHIFT + calc_p - 2);
dsi_mnp-dsi_pll_div = (n - 1) DSI_PLL_N1_DIV_SHIFT |
- m_seed DSI_PLL_M1_DIV_SHIFT;
+ m_seed DSI_PLL_M1_DIV_SHIFT;
If really needed, style/whitespace changes should also be separated.
return 0;
}
@@ -249,11 +298,13 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
int ret;
struct dsi_mnp dsi_mnp;
- u32 dsi_clk;
+ u32 dsi_clk = 0;
- dsi_clk = dsi_rr_formula(mode, intel_dsi-pixel_format,
- intel_dsi-video_mode_format,
- intel_dsi-lane_count,
!intel_dsi-eot_disable);
+ if (intel_dsi-dsi_clock_freq)
+ dsi_clk = intel_dsi-dsi_clock_freq;
This is the third major change in the patch. Should be separate, with
rationale, or possibly bundled with a different change which starts
using it. Who is responsible for setting and clearing this?
+ else
+
Re: [Intel-gfx] [PATCH 12/16] drm/i915: Fix PIPE_CRC_CTL for vlv
On Mon, Oct 21, 2013 at 01:50:03PM +0300, Ville Syrjälä wrote: On Wed, Oct 16, 2013 at 10:55:57PM +0200, Daniel Vetter wrote: The PIPE_B #define was missing the display mmio offset. Use the _PIPE_INC macro instead, it's simpler. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_reg.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ad8fe21..4e0f0b7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1887,14 +1887,13 @@ #define _PIPE_CRC_RES_RES2_A_G4X (dev_priv-info-display_mmio_offset + 0x60080) /* Pipe B CRC regs */ -#define _PIPE_CRC_CTL_B0x61050 #define _PIPE_CRC_RES_1_B_IVB 0x61064 #define _PIPE_CRC_RES_2_B_IVB 0x61068 #define _PIPE_CRC_RES_3_B_IVB 0x6106c #define _PIPE_CRC_RES_4_B_IVB 0x61070 #define _PIPE_CRC_RES_5_B_IVB 0x61074 Maybe use _PIPE_INC() for these IVB regs as well. They're the only CRC regs left using _PIPE(), so they feel a bit out of place. The _PIPE_INC stuff is essentially just a throw stuff at the wall and see whether it sticks test. The idea is that with the doc rework registers for new platforms are already tightly grouped, so the base+increment is easier to review. If people like it we could do a mass conversion (and decently cut down the size of i915_reg.h). That would also help to make the odd cases like vlv+1 stick out more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Wire up gen2 CRC support
On Mon, Oct 21, 2013 at 01:22:40PM +0300, Ville Syrjälä wrote:
On Fri, Oct 18, 2013 at 04:37:05PM +0200, Daniel Vetter wrote:
Really simple, and we don't even have working frame numbers.
v2: Actually enable it ...
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3f0980..3f4fd7c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,20 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE;
On gen3+ the border is always included in the crc. Maybe we should
always include it on gen2 as well?
I've considered but decided to go meh. But you're right, for consistency
we should enable the border on gen2, too. I'll resend.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Wire up gen2 CRC support
Really simple, and we don't even have working frame numbers.
v2: Actually enable it ...
v3: Review from Ville:
- Unconditionally enable the border in the CRC checksum for
consistency with gen3+.
- Handle the none source to be able to disable the CRC machinery
again.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3f0980..9a4f168 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,23 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_INCLUDE_BORDER_I8XX;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ *val = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
enum intel_pipe_crc_source source,
uint32_t *val)
@@ -2039,7 +2056,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
u32 val;
int ret;
- if (!(INTEL_INFO(dev)-gen = 3 !IS_VALLEYVIEW(dev)))
+ if (IS_VALLEYVIEW(dev))
return -ENODEV;
if (pipe_crc-source == source)
@@ -2049,7 +2066,9 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
- if (INTEL_INFO(dev)-gen 5)
+ if (IS_GEN2(dev))
+ ret = i8xx_pipe_crc_ctl_reg(source, val);
+ else if (INTEL_INFO(dev)-gen 5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d8ef094..c97fc94 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1873,6 +1873,7 @@
#define PIPE_CRC_SOURCE_DP_B_G4X (6 28)
#define PIPE_CRC_SOURCE_DP_C_G4X (7 28)
/* gen2 doesn't have source selection bits */
+#define PIPE_CRC_INCLUDE_BORDER_I8XX (1 30)
#define _PIPE_CRC_RES_1_A_IVB 0x60064
#define _PIPE_CRC_RES_2_A_IVB 0x60068
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Stop CRC gathering when the ctl file is closed
From: Ville Syrjälä ville.syrj...@linux.intel.com
If no one is looking at the CRCs, stop gathering them.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index eb61c4b..e7470b8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2294,12 +2294,25 @@ out:
return len;
}
+static int display_crc_ctl_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *m = file-private_data;
+ struct drm_device *dev = m-private;
+ enum pipe pipe;
+
+ /* stop gathering CRCs */
+ for_each_pipe(pipe)
+ pipe_crc_set_source(dev, pipe, INTEL_PIPE_CRC_SOURCE_NONE);
+
+ return single_release(inode, file);
+}
+
static const struct file_operations i915_display_crc_ctl_fops = {
.owner = THIS_MODULE,
.open = display_crc_ctl_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = single_release,
+ .release = display_crc_ctl_release,
.write = display_crc_ctl_write
};
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clamp cursor coordinates to int16_t range
From: Ville Syrjälä ville.syrj...@linux.intel.com
We store cursor_x/y as int16_t internally, but the user provided
coordinates are int32_t. Clamp the coordinates so that they don't
overflow the int16_t. Since the cursor is only 64x64 in size, the
clamping can't cause any visual changes.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d4a480c..8f554f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7272,8 +7272,8 @@ static int intel_crtc_cursor_move(struct drm_crtc *crtc,
int x, int y)
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- intel_crtc-cursor_x = x;
- intel_crtc-cursor_y = y;
+ intel_crtc-cursor_x = clamp_t(int, x, SHRT_MIN, SHRT_MAX);
+ intel_crtc-cursor_y = clamp_t(int, y, SHRT_MIN, SHRT_MAX);
if (intel_crtc-active)
intel_crtc_update_cursor(crtc, intel_crtc-cursor_bo != NULL);
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: use enum pipe consistently in i915_irq.c
Request by Ville in his review of the CRC stuff. This converts
everything but ilk_display_irq_handler since that needs a bit more
than a simple searchreplace to look nice.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 37 +++--
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a0b60f..6993ab9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1883,10 +1883,10 @@ extern void intel_uncore_check_errors(struct drm_device
*dev);
extern void intel_uncore_fini(struct drm_device *dev);
void
-i915_enable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask);
+i915_enable_pipestat(drm_i915_private_t *dev_priv, enum pipe pipe, u32 mask);
void
-i915_disable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask);
+i915_disable_pipestat(drm_i915_private_t *dev_priv, enum pipe pipe, u32 mask);
/* i915_gem.c */
int i915_gem_init_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8f7baad..ce94afc 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -442,7 +442,7 @@ done:
void
-i915_enable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask)
+i915_enable_pipestat(drm_i915_private_t *dev_priv, enum pipe pipe, u32 mask)
{
u32 reg = PIPESTAT(pipe);
u32 pipestat = I915_READ(reg) 0x7fff;
@@ -459,7 +459,7 @@ i915_enable_pipestat(drm_i915_private_t *dev_priv, int
pipe, u32 mask)
}
void
-i915_disable_pipestat(drm_i915_private_t *dev_priv, int pipe, u32 mask)
+i915_disable_pipestat(drm_i915_private_t *dev_priv, enum pipe pipe, u32 mask)
{
u32 reg = PIPESTAT(pipe);
u32 pipestat = I915_READ(reg) 0x7fff;
@@ -487,9 +487,10 @@ static void i915_enable_asle_pipestat(struct drm_device
*dev)
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
- i915_enable_pipestat(dev_priv, 1, PIPE_LEGACY_BLC_EVENT_ENABLE);
+ i915_enable_pipestat(dev_priv, PIPE_B, PIPE_LEGACY_BLC_EVENT_ENABLE);
if (INTEL_INFO(dev)-gen = 4)
- i915_enable_pipestat(dev_priv, 0, PIPE_LEGACY_BLC_EVENT_ENABLE);
+ i915_enable_pipestat(dev_priv, PIPE_A,
+PIPE_LEGACY_BLC_EVENT_ENABLE);
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
}
@@ -1594,7 +1595,7 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
static void ivb_display_irq_handler(struct drm_device *dev, u32 de_iir)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int i;
+ enum pipe i;
if (de_iir DE_ERR_INT_IVB)
ivb_err_int_handler(dev);
@@ -1605,7 +1606,7 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
if (de_iir DE_GSE_IVB)
intel_opregion_asle_intr(dev);
- for (i = 0; i 3; i++) {
+ for_each_pipe(i) {
if (de_iir (DE_PIPEA_VBLANK_IVB (5 * i)))
drm_handle_vblank(dev, i);
if (de_iir (DE_PLANEA_FLIP_DONE_IVB (5 * i))) {
@@ -2034,7 +2035,7 @@ static int valleyview_enable_vblank(struct drm_device
*dev, int pipe)
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
imr = I915_READ(VLV_IMR);
- if (pipe == 0)
+ if (pipe == PIPE_A)
imr = ~I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT;
else
imr = ~I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
@@ -2086,7 +2087,7 @@ static void valleyview_disable_vblank(struct drm_device
*dev, int pipe)
i915_disable_pipestat(dev_priv, pipe,
PIPE_START_VBLANK_INTERRUPT_ENABLE);
imr = I915_READ(VLV_IMR);
- if (pipe == 0)
+ if (pipe == PIPE_A)
imr |= I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT;
else
imr |= I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
@@ -2608,9 +2609,9 @@ static int valleyview_irq_postinstall(struct drm_device
*dev)
/* Interrupt setup is already guaranteed to be single-threaded, this is
* just to make the assert_spin_locked check happy. */
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
- i915_enable_pipestat(dev_priv, 0, pipestat_enable);
- i915_enable_pipestat(dev_priv, 0, PIPE_GMBUS_EVENT_ENABLE);
- i915_enable_pipestat(dev_priv, 1, pipestat_enable);
+ i915_enable_pipestat(dev_priv, PIPE_A, pipestat_enable);
+ i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_EVENT_ENABLE);
+ i915_enable_pipestat(dev_priv, PIPE_B, pipestat_enable);
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
I915_WRITE(VLV_IIR, 0x);
@@ -2725,8 +2726,8 @@ static int i8xx_irq_postinstall(struct drm_device
Re: [Intel-gfx] [PATCH] drm/i915: Clamp cursor coordinates to int16_t range
On Mon, Oct 21, 2013 at 07:01:58PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We store cursor_x/y as int16_t internally, but the user provided coordinates are int32_t. Clamp the coordinates so that they don't overflow the int16_t. Since the cursor is only 64x64 in size, the clamping can't cause any visual changes. EINVAL? That would appear to be a nuisance as we don't already tell the user off for being silly with the cursor position. Bump the internal range? Future proof against tomorrow's 64k super-ultra-high definition monitors? The valid range for cursor is currently (-64, 8192) and we don't compute relative cursor position, so we will be fine for a few years yet with int16_t. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
[Intel-gfx] [PATCH 2/2] drm/i915: refactor ilk display interrupt handling
- Use a for_each_loop and add the corresponding #defines.
- Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for
consistency with everything else.
- Also use macros (and add the missing one for plane flips) for the
ivb display interrupt handler.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 50 +
drivers/gpu/drm/i915/i915_reg.h | 7 --
2 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ce94afc..062a6d6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1535,6 +1535,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
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;
if (de_iir DE_AUX_CHANNEL_A)
dp_aux_irq_handler(dev);
@@ -1542,37 +1543,26 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
if (de_iir DE_GSE)
intel_opregion_asle_intr(dev);
- if (de_iir DE_PIPEA_VBLANK)
- drm_handle_vblank(dev, 0);
-
- if (de_iir DE_PIPEB_VBLANK)
- drm_handle_vblank(dev, 1);
-
if (de_iir DE_POISON)
DRM_ERROR(Poison interrupt\n);
- if (de_iir DE_PIPEA_FIFO_UNDERRUN)
- if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_A, false))
- DRM_DEBUG_DRIVER(Pipe A FIFO underrun\n);
-
- if (de_iir DE_PIPEB_FIFO_UNDERRUN)
- if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_B, false))
- DRM_DEBUG_DRIVER(Pipe B FIFO underrun\n);
-
- if (de_iir DE_PIPEA_CRC_DONE)
- i9xx_pipe_crc_irq_handler(dev, PIPE_A);
+ for_each_pipe(pipe) {
+ if (de_iir DE_PIPE_VBLANK(pipe))
+ drm_handle_vblank(dev, pipe);
- if (de_iir DE_PIPEB_CRC_DONE)
- i9xx_pipe_crc_irq_handler(dev, PIPE_B);
+ if (de_iir DE_PIPE_FIFO_UNDERRUN(pipe))
+ if (intel_set_cpu_fifo_underrun_reporting(dev, pipe,
false))
+ DRM_DEBUG_DRIVER(Pipe %c FIFO underrun\n,
+pipe_name(pipe));
- if (de_iir DE_PLANEA_FLIP_DONE) {
- intel_prepare_page_flip(dev, 0);
- intel_finish_page_flip_plane(dev, 0);
- }
+ if (de_iir DE_PIPE_CRC_DONE(pipe))
+ i9xx_pipe_crc_irq_handler(dev, pipe);
- if (de_iir DE_PLANEB_FLIP_DONE) {
- intel_prepare_page_flip(dev, 1);
- intel_finish_page_flip_plane(dev, 1);
+ /* plane/pipes map 1:1 on ilk+ */
+ if (de_iir DE_PLANE_FLIP_DONE(pipe)) {
+ intel_prepare_page_flip(dev, pipe);
+ intel_finish_page_flip_plane(dev, pipe);
+ }
}
/* check event from PCH */
@@ -1607,9 +1597,11 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
intel_opregion_asle_intr(dev);
for_each_pipe(i) {
- if (de_iir (DE_PIPEA_VBLANK_IVB (5 * i)))
+ if (de_iir (DE_PIPE_VBLANK_IVB(i)))
drm_handle_vblank(dev, i);
- if (de_iir (DE_PLANEA_FLIP_DONE_IVB (5 * i))) {
+
+ /* plane/pipes map 1:1 on ilk+ */
+ if (de_iir (DE_PLANE_FLIP_DONE_IVB(i))) {
intel_prepare_page_flip(dev, i);
intel_finish_page_flip_plane(dev, i);
}
@@ -2012,7 +2004,7 @@ static int ironlake_enable_vblank(struct drm_device *dev,
int pipe)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
unsigned long irqflags;
uint32_t bit = (INTEL_INFO(dev)-gen = 7) ? DE_PIPE_VBLANK_IVB(pipe) :
-DE_PIPE_VBLANK_ILK(pipe);
+DE_PIPE_VBLANK(pipe);
if (!i915_pipe_enabled(dev, pipe))
return -EINVAL;
@@ -2070,7 +2062,7 @@ static void ironlake_disable_vblank(struct drm_device
*dev, int pipe)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
unsigned long irqflags;
uint32_t bit = (INTEL_INFO(dev)-gen = 7) ? DE_PIPE_VBLANK_IVB(pipe) :
-DE_PIPE_VBLANK_ILK(pipe);
+DE_PIPE_VBLANK(pipe);
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
ironlake_disable_display_irq(dev_priv, bit);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c97fc94..1af080a
Re: [Intel-gfx] [PATCH] drm/i915: Clamp cursor coordinates to int16_t range
On Mon, Oct 21, 2013 at 6:01 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We store cursor_x/y as int16_t internally, but the user provided coordinates are int32_t. Clamp the coordinates so that they don't overflow the int16_t. Since the cursor is only 64x64 in size, the clamping can't cause any visual changes. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com For shitsgiggles: You've bothered with a subtest for this in your crc cursor test? Should be a one-liner and would neatly test whether QA catches it ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Wire up gen2 CRC support
On Mon, Oct 21, 2013 at 05:26:38PM +0200, Daniel Vetter wrote:
Really simple, and we don't even have working frame numbers.
v2: Actually enable it ...
v3: Review from Ville:
- Unconditionally enable the border in the CRC checksum for
consistency with gen3+.
- Handle the none source to be able to disable the CRC machinery
again.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 23 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3f0980..9a4f168 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,23 @@ static int display_crc_ctl_open(struct inode *inode,
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
}
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+ uint32_t *val)
+{
+ switch (source) {
+ case INTEL_PIPE_CRC_SOURCE_PIPE:
+ *val = PIPE_CRC_ENABLE | PIPE_CRC_INCLUDE_BORDER_I8XX;
+ break;
+ case INTEL_PIPE_CRC_SOURCE_NONE:
+ *val = 0;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
enum intel_pipe_crc_source source,
uint32_t *val)
@@ -2039,7 +2056,7 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
u32 val;
int ret;
- if (!(INTEL_INFO(dev)-gen = 3 !IS_VALLEYVIEW(dev)))
+ if (IS_VALLEYVIEW(dev))
return -ENODEV;
if (pipe_crc-source == source)
@@ -2049,7 +2066,9 @@ static int pipe_crc_set_source(struct drm_device *dev,
enum pipe pipe,
if (pipe_crc-source source)
return -EINVAL;
- if (INTEL_INFO(dev)-gen 5)
+ if (IS_GEN2(dev))
+ ret = i8xx_pipe_crc_ctl_reg(source, val);
+ else if (INTEL_INFO(dev)-gen 5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d8ef094..c97fc94 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1873,6 +1873,7 @@
#define PIPE_CRC_SOURCE_DP_B_G4X (6 28)
#define PIPE_CRC_SOURCE_DP_C_G4X (7 28)
/* gen2 doesn't have source selection bits */
+#define PIPE_CRC_INCLUDE_BORDER_I8XX (1 30)
#define _PIPE_CRC_RES_1_A_IVB0x60064
#define _PIPE_CRC_RES_2_A_IVB0x60068
--
1.8.4.rc3
--
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: Stop CRC gathering when the ctl file is closed
On Mon, Oct 21, 2013 at 6:01 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com If no one is looking at the CRCs, stop gathering them. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com As discussed on irc this prevents fools like me from wreaking havoc directly with the cli, at least if you still want to interactively test stuff easily (background processes and all would work around this). Imo it's better to disable (and maybe re-enable) the CRC stuff when we disable/enable the pipe. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clamp cursor coordinates to int16_t range
On Mon, Oct 21, 2013 at 06:15:06PM +0200, Daniel Vetter wrote: On Mon, Oct 21, 2013 at 6:01 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We store cursor_x/y as int16_t internally, but the user provided coordinates are int32_t. Clamp the coordinates so that they don't overflow the int16_t. Since the cursor is only 64x64 in size, the clamping can't cause any visual changes. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com For shitsgiggles: You've bothered with a subtest for this in your crc cursor test? Should be a one-liner and would neatly test whether QA catches it ... Yeah it's there. Actually I added the test before I knew the bug existed. The test is what found the bug for me. It's not a specific subtest though, but part of all the bigger cursor-offscreen subtests. The subtest split I'm using there isn't very fine grained. Maybe I should change that actually. It would help in pinpointing the failing cases more accurately. -- 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: Stop CRC gathering when the ctl file is closed
On Mon, Oct 21, 2013 at 06:17:30PM +0200, Daniel Vetter wrote: On Mon, Oct 21, 2013 at 6:01 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com If no one is looking at the CRCs, stop gathering them. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com As discussed on irc this prevents fools like me from wreaking havoc directly with the cli, at least if you still want to interactively test stuff easily (background processes and all would work around this). Imo it's better to disable (and maybe re-enable) the CRC stuff when we disable/enable the pipe. I would still suggest using exec for keeping the file open. Especially if we go for the auto re-enable, since then we'd essientially never turn off the crc capture once it's started unless someone explicitly writes to the ctl file. We'd just pause it while the pipe is off. Also I would assume we want to avoid full modesets in the future if possible, so relying on that doesn't feel very robust to me. -- 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: Wire up gen2 CRC support
On Mon, Oct 21, 2013 at 07:16:24PM +0300, Ville Syrjälä wrote: On Mon, Oct 21, 2013 at 05:26:38PM +0200, Daniel Vetter wrote: Really simple, and we don't even have working frame numbers. v2: Actually enable it ... v3: Review from Ville: - Unconditionally enable the border in the CRC checksum for consistency with gen3+. - Handle the none source to be able to disable the CRC machinery again. Cc: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Thanks for your review, I've merged all the patches to dinq. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HPD flood warning since b8f102e8b
Hi Jiri, Just found your email, it got missed do to a temporary inaccessibility to my email. Jiri Kosina writes: On Thu, 3 Oct 2013, Daniel Vetter wrote: Can you please attach full dmesg from boot up to the first WARN with drm.debug=0xe? This really shouldn't happen and indicates a bug somewhere ... A bit difficult ... I originally thought that it was reliably reproducible, but now I didn't get it after 10 suspend/resume cycles. Will keep following it, and once it appears, will send you the dmesg. Could you check if you get any messages regarding HPD storms after suspend/resume ie messages like: [drm] HPD interrupt storm detected on connector HDMI-A-1 but without the annouing warn messages? I cannot find anything obviously wrong in the code. However there are several code paths for different hardware though - could you give me an 'lspci -n' output so I can narrow them down? Thanks! Cheers, Egbert. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: refactor ilk display interrupt handling
On Mon, Oct 21, 2013 at 06:04:36PM +0200, Daniel Vetter wrote:
- Use a for_each_loop and add the corresponding #defines.
- Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for
consistency with everything else.
- Also use macros (and add the missing one for plane flips) for the
ivb display interrupt handler.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 50
+
drivers/gpu/drm/i915/i915_reg.h | 7 --
2 files changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ce94afc..062a6d6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1535,6 +1535,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32
pch_iir)
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;
if (de_iir DE_AUX_CHANNEL_A)
dp_aux_irq_handler(dev);
@@ -1542,37 +1543,26 @@ static void ilk_display_irq_handler(struct drm_device
*dev, u32 de_iir)
if (de_iir DE_GSE)
intel_opregion_asle_intr(dev);
- if (de_iir DE_PIPEA_VBLANK)
- drm_handle_vblank(dev, 0);
-
- if (de_iir DE_PIPEB_VBLANK)
- drm_handle_vblank(dev, 1);
-
if (de_iir DE_POISON)
DRM_ERROR(Poison interrupt\n);
- if (de_iir DE_PIPEA_FIFO_UNDERRUN)
- if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_A, false))
- DRM_DEBUG_DRIVER(Pipe A FIFO underrun\n);
-
- if (de_iir DE_PIPEB_FIFO_UNDERRUN)
- if (intel_set_cpu_fifo_underrun_reporting(dev, PIPE_B, false))
- DRM_DEBUG_DRIVER(Pipe B FIFO underrun\n);
-
- if (de_iir DE_PIPEA_CRC_DONE)
- i9xx_pipe_crc_irq_handler(dev, PIPE_A);
+ for_each_pipe(pipe) {
+ if (de_iir DE_PIPE_VBLANK(pipe))
+ drm_handle_vblank(dev, pipe);
- if (de_iir DE_PIPEB_CRC_DONE)
- i9xx_pipe_crc_irq_handler(dev, PIPE_B);
+ if (de_iir DE_PIPE_FIFO_UNDERRUN(pipe))
+ if (intel_set_cpu_fifo_underrun_reporting(dev, pipe,
false))
+ DRM_DEBUG_DRIVER(Pipe %c FIFO underrun\n,
+ pipe_name(pipe));
- if (de_iir DE_PLANEA_FLIP_DONE) {
- intel_prepare_page_flip(dev, 0);
- intel_finish_page_flip_plane(dev, 0);
- }
+ if (de_iir DE_PIPE_CRC_DONE(pipe))
+ i9xx_pipe_crc_irq_handler(dev, pipe);
- if (de_iir DE_PLANEB_FLIP_DONE) {
- intel_prepare_page_flip(dev, 1);
- intel_finish_page_flip_plane(dev, 1);
+ /* plane/pipes map 1:1 on ilk+ */
+ if (de_iir DE_PLANE_FLIP_DONE(pipe)) {
+ intel_prepare_page_flip(dev, pipe);
+ intel_finish_page_flip_plane(dev, pipe);
+ }
}
/* check event from PCH */
@@ -1607,9 +1597,11 @@ static void ivb_display_irq_handler(struct drm_device
*dev, u32 de_iir)
intel_opregion_asle_intr(dev);
for_each_pipe(i) {
- if (de_iir (DE_PIPEA_VBLANK_IVB (5 * i)))
+ if (de_iir (DE_PIPE_VBLANK_IVB(i)))
^ ^
drm_handle_vblank(dev, i);
- if (de_iir (DE_PLANEA_FLIP_DONE_IVB (5 * i))) {
+
+ /* plane/pipes map 1:1 on ilk+ */
+ if (de_iir (DE_PLANE_FLIP_DONE_IVB(i))) {
^ ^
Just a minor complaint about the useless parens.
But otherwise both patches look good, so:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
intel_prepare_page_flip(dev, i);
intel_finish_page_flip_plane(dev, i);
}
@@ -2012,7 +2004,7 @@ static int ironlake_enable_vblank(struct drm_device
*dev, int pipe)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
unsigned long irqflags;
uint32_t bit = (INTEL_INFO(dev)-gen = 7) ? DE_PIPE_VBLANK_IVB(pipe) :
- DE_PIPE_VBLANK_ILK(pipe);
+ DE_PIPE_VBLANK(pipe);
if (!i915_pipe_enabled(dev, pipe))
return -EINVAL;
@@ -2070,7 +2062,7 @@ static void ironlake_disable_vblank(struct drm_device
*dev, int pipe)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
unsigned long irqflags;
uint32_t bit = (INTEL_INFO(dev)-gen = 7) ? DE_PIPE_VBLANK_IVB(pipe) :
-
[Intel-gfx] [PATCH 1/2] drm/i915: Abstract backlight registers a bit
Many GENs generally perform the same actions just on different
registers. This is true going forward as well. To ease the transition a
bit, extract the common code where possible.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_panel.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 1f29960..83e174b 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -430,24 +430,25 @@ static u32 intel_panel_compute_brightness(struct
drm_device *dev, u32 val)
static u32 intel_panel_get_backlight(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 val;
+ u32 reg, val;
unsigned long flags;
spin_lock_irqsave(dev_priv-backlight.lock, flags);
- if (HAS_PCH_SPLIT(dev)) {
- val = I915_READ(BLC_PWM_CPU_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
- } else {
- val = I915_READ(BLC_PWM_CTL) BACKLIGHT_DUTY_CYCLE_MASK;
- if (INTEL_INFO(dev)-gen 4)
- val = 1;
+ if (HAS_PCH_SPLIT(dev))
+ reg = BLC_PWM_CPU_CTL;
+ else
+ reg = BLC_PWM_CTL;
- if (is_backlight_combination_mode(dev)) {
- u8 lbpc;
+ val = I915_READ(reg) BACKLIGHT_DUTY_CYCLE_MASK;
+ if (INTEL_INFO(dev)-gen 4)
+ val = 1;
- pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
- val *= lbpc;
- }
+ if (is_backlight_combination_mode(dev)) {
+ u8 lbpc;
+
+ pci_read_config_byte(dev-pdev, PCI_LBPC, lbpc);
+ val *= lbpc;
}
val = intel_panel_compute_brightness(dev, val);
--
1.8.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Move the pipe CRC stuff to other pipe data
Adding stuff to the bottom of struct drm_i915_driver_private is
nowadays considered uncool.
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index faface9..2e1e884 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1380,6 +1380,10 @@ typedef struct drm_i915_private {
struct drm_crtc *pipe_to_crtc_mapping[3];
wait_queue_head_t pending_flip_queue;
+#ifdef CONFIG_DEBUG_FS
+ struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
+#endif
+
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
struct intel_ddi_plls ddi_plls;
@@ -1460,10 +1464,6 @@ typedef struct drm_i915_private {
struct i915_dri1_state dri1;
/* Old ums support infrastructure, same warning applies. */
struct i915_ums_state ums;
-
-#ifdef CONFIG_DEBUG_FS
- struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
-#endif
} drm_i915_private_t;
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
--
1.8.4.rc3
___
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: use power get/put instead of set for power on after init
On Wed, Oct 16, 2013 at 05:25:53PM +0300, Imre Deak wrote:
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
power well on during init logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.
For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.
Signed-off-by: Imre Deak imre.d...@intel.com
---
[snip]
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4354dd..0557c6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,6 +100,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
+ POWER_DOMAIN_INIT,
POWER_DOMAIN_NUM,
};
@@ -913,7 +914,6 @@ struct i915_power_well {
struct mutex lock;
/* power well enable/disable usage count */
int count;
- int i915_request;
};
struct i915_dri1_state {
@@ -1369,6 +1369,11 @@ typedef struct drm_i915_private {
* mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
+ /*
+ * Power wells needed for initialization at driver init and suspend
+ * time are on. They are kept on until after the first modeset.
+ */
+ bool init_power_on;
Please move this into the nice power_well structure we have to avoid
overtly polluting our i915_driver_private thing ... All patches up to this
one merged, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move the pipe CRC stuff to other pipe data
On Mon, Oct 21, 2013 at 09:10:20PM +0200, Daniel Vetter wrote:
Adding stuff to the bottom of struct drm_i915_driver_private is
nowadays considered uncool.
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Ville was suggesting moving the pipe_crc struct into intel_crtc. Might
be even better! But anyway:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
drivers/gpu/drm/i915/i915_drv.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index faface9..2e1e884 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1380,6 +1380,10 @@ typedef struct drm_i915_private {
struct drm_crtc *pipe_to_crtc_mapping[3];
wait_queue_head_t pending_flip_queue;
+#ifdef CONFIG_DEBUG_FS
+ struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
+#endif
+
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
struct intel_ddi_plls ddi_plls;
@@ -1460,10 +1464,6 @@ typedef struct drm_i915_private {
struct i915_dri1_state dri1;
/* Old ums support infrastructure, same warning applies. */
struct i915_ums_state ums;
-
-#ifdef CONFIG_DEBUG_FS
- struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
-#endif
} drm_i915_private_t;
static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm-intel-collector - review request
This is another drm-intel-collector push for review: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the list in order for better reviewers assignment: Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewed Patch drm/i915: Initialise min/max frequencies before updating RPS registers - Reviewer: Ville Syrjälä ville.syrj...@linux.intel.com Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Chris Wilson (2): drm/i915: Asynchronously perform the set-base for a simple modeset drm/i915: Initialise min/max frequencies before updating RPS registers drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_sysfs.c| 16 drivers/gpu/drm/i915/intel_display.c | 11 +++ drivers/gpu/drm/i915/intel_pm.c | 19 +-- 4 files changed, 21 insertions(+), 27 deletions(-) -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Initialise min/max frequencies before updating RPS registers
From: Chris Wilson ch...@chris-wilson.co.uk
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling sequences to be correct, and remove the then
unrequired clamping from inside set_rps(). And for a bonus, fix the bug
of calling gen6_set_rps() from Valleyview.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewer: Ville Syrjälä ville.syrj...@linux.intel.com
CC: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_sysfs.c | 16
drivers/gpu/drm/i915/intel_pm.c | 19 +--
3 files changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 061182a..b67f34b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2474,7 +2474,7 @@ i915_max_freq_set(void *data, u64 val)
if (IS_VALLEYVIEW(dev)) {
val = vlv_freq_opcode(dev_priv-mem_freq, val);
dev_priv-rps.max_delay = val;
- gen6_set_rps(dev, val);
+ valleyview_set_rps(dev, val);
} else {
do_div(val, GT_FREQUENCY_MULTIPLIER);
dev_priv-rps.max_delay = val;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index bb31ff3..19deec3 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -342,15 +342,15 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
DRM_DEBUG(User requested overclocking to %d\n,
val * GT_FREQUENCY_MULTIPLIER);
+ dev_priv-rps.max_delay = val;
+
if (dev_priv-rps.cur_delay val) {
- if (IS_VALLEYVIEW(dev_priv-dev))
- valleyview_set_rps(dev_priv-dev, val);
+ if (IS_VALLEYVIEW(dev))
+ valleyview_set_rps(dev, val);
else
- gen6_set_rps(dev_priv-dev, val);
+ gen6_set_rps(dev, val);
}
- dev_priv-rps.max_delay = val;
-
mutex_unlock(dev_priv-rps.hw_lock);
return count;
@@ -411,15 +411,15 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
return -EINVAL;
}
+ dev_priv-rps.min_delay = val;
+
if (dev_priv-rps.cur_delay val) {
if (IS_VALLEYVIEW(dev))
valleyview_set_rps(dev, val);
else
- gen6_set_rps(dev_priv-dev, val);
+ gen6_set_rps(dev, val);
}
- dev_priv-rps.min_delay = val;
-
mutex_unlock(dev_priv-rps.hw_lock);
return count;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bf5261f..4774aca 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3413,26 +3413,19 @@ static void ironlake_disable_drps(struct drm_device
*dev)
* ourselves, instead of doing a rmw cycle (which might result in us clearing
* all limits and the gpu stuck at whatever frequency it is at atm).
*/
-static u32 gen6_rps_limits(struct drm_i915_private *dev_priv, u8 *val)
+static u32 gen6_rps_limits(struct drm_i915_private *dev_priv, u8 val)
{
u32 limits;
- limits = 0;
-
- if (*val = dev_priv-rps.max_delay)
- *val = dev_priv-rps.max_delay;
- limits |= dev_priv-rps.max_delay 24;
-
/* Only set the down limit when we've reached the lowest level to avoid
* getting more interrupts, otherwise leave this clear. This prevents a
* race in the hw when coming out of rc6: There's a tiny window where
* the hw runs at the minimal clock before selecting the desired
* frequency, if the down threshold expires in that window we will not
* receive a down interrupt. */
- if (*val = dev_priv-rps.min_delay) {
- *val = dev_priv-rps.min_delay;
+ limits = dev_priv-rps.max_delay 24;
+ if (val = dev_priv-rps.min_delay)
limits |= dev_priv-rps.min_delay 16;
- }
return limits;
}
@@ -3532,7 +3525,6 @@ static void gen6_set_rps_thresholds(struct
drm_i915_private *dev_priv, u8 val)
void gen6_set_rps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 limits = gen6_rps_limits(dev_priv, val);
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
WARN_ON(val dev_priv-rps.max_delay);
@@ -3555,7 +3547,8 @@ void gen6_set_rps(struct drm_device *dev, u8 val)
/* Make sure we continue to get interrupts
* until we hit the minimum or maximum
Re: [Intel-gfx] [PATCH] drm/i915: Move the pipe CRC stuff to other pipe data
On Mon, Oct 21, 2013 at 10:47 PM, Damien Lespiau damien.lesp...@intel.com wrote: On Mon, Oct 21, 2013 at 09:10:20PM +0200, Daniel Vetter wrote: Adding stuff to the bottom of struct drm_i915_driver_private is nowadays considered uncool. Cc: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ville was suggesting moving the pipe_crc struct into intel_crtc. Might be even better! But anyway: We enable interrupts before we allocate the intel_crtc structs. So if we'd store the CRC stuff in there we'd need to be a bit more paranoid with clearing hw state (since every time we trust the BIOS we end up burning our hands). So I think this is safer ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] testcases: Slice Shutdown testscases.
1. sysfs half/full switch.
2. on full execbuf without I915_EXEC_USE_PREDICATE
3. on full execbuf with I915_EXEC_USE_PREDICATE
4. on half execbuf without I915_EXEC_USE_PREDICATE
5. on half execbuf with I915_EXEC_USE_PREDICATE
v2: include more tests and s/GT_FULL/USE_PREDICATE
v3: make it more reliable and fix few comments
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/Makefile.am | 1 +
tests/gt_slice_config.c | 343
2 files changed, 344 insertions(+)
create mode 100644 tests/gt_slice_config.c
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 0290ae0..cf105e4 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -50,6 +50,7 @@ TESTS_progs_M = \
gem_tiled_blits \
gem_tiled_partial_pwrite_pread \
gem_write_read_ring_switch \
+ gt_slice_config \
kms_flip \
kms_render \
kms_setmode \
diff --git a/tests/gt_slice_config.c b/tests/gt_slice_config.c
new file mode 100644
index 000..58e53cf
--- /dev/null
+++ b/tests/gt_slice_config.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rodrigo Vivi rodrigo.v...@intel.com
+ *
+ */
+
+/*
+ * Testcase: Test GT slice shutdown feature
+ *
+ * Sub tests:
+ * 1. sysfs half/full switch.
+ * 2. on full execbuf without I915_EXEC_USE_PREDICATE
+ * 3. on full execbuf with I915_EXEC_USE_PREDICATE
+ * 4. on half execbuf without I915_EXEC_USE_PREDICATE
+ * 5. on half execbuf with I915_EXEC_USE_PREDICATE
+ */
+
+#define _GNU_SOURCE
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include drmtest.h
+
+static void exec(int fd, uint32_t handle, bool use_predicate)
+{
+struct drm_i915_gem_execbuffer2 execbuf;
+struct drm_i915_gem_exec_object2 gem_exec[1];
+uint32_t b[2] = {MI_BATCH_BUFFER_END};
+int loops = 100;
+int ret = 0;
+
+gem_write(fd, handle, 0, b, sizeof(b));
+
+gem_exec[0].handle = handle;
+gem_exec[0].relocation_count = 0;
+gem_exec[0].relocs_ptr = 0;
+gem_exec[0].alignment = 0;
+gem_exec[0].offset = 0;
+gem_exec[0].flags = 0;
+gem_exec[0].rsvd1 = 0;
+gem_exec[0].rsvd2 = 0;
+
+execbuf.buffers_ptr = (uintptr_t)gem_exec;
+execbuf.buffer_count = 1;
+execbuf.batch_start_offset = 0;
+execbuf.batch_len = 8;
+execbuf.cliprects_ptr = 0;
+execbuf.num_cliprects = 0;
+execbuf.DR1 = 0;
+execbuf.DR4 = 0;
+execbuf.flags = I915_EXEC_RENDER;
+ if (use_predicate)
+ execbuf.flags |= I915_EXEC_USE_PREDICATE;
+i915_execbuffer2_set_context_id(execbuf, 0);
+execbuf.rsvd2 = 0;
+
+while (loops-- ret == 0) {
+ret = drmIoctl(fd,
+ DRM_IOCTL_I915_GEM_EXECBUFFER2,
+ execbuf);
+}
+ gem_sync(fd, handle);
+}
+
+static bool is_full(const int device)
+{
+ char *path;
+ FILE *file;
+ int ret;
+ char str[5];
+
+ ret = asprintf(path, /sys/class/drm/card%d/power/gt_slice_config,
+ device);
+ igt_assert(ret != -1);
+
+ file = fopen(path, r);
+ igt_require(file);
+
+ ret = fscanf(file, %s, str);
+ igt_assert(ret != 0);
+
+ fclose(file);
+ return strcmp(str, half);
+}
+
+static int set_status(const int device, bool full)
+{
+ char *path;
+ FILE *file;
+ int ret;
+ char str[5];
+ int attempts = 10;
+
+ ret = asprintf(path, /sys/class/drm/card%d/power/gt_slice_config,
+ device);
+ igt_assert(ret != -1);
+
+ file = fopen(path, r);
+ igt_require(file);
+
+ ret = fscanf(file, %s, str);
+ igt_assert(ret != 0);
+
+
[Intel-gfx] [PATCH] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication
If Userspace isn't using MI_PREDICATE all slices must be enabled for
backward compatibility.
If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
force
all slices on.
v2: fix the inverted logic for backwards compatibility
USE_PREDICATE unset force gt_full when defaul is half
instead of GT_FULL flag.
v3: Accepting Chris's suggestions: better variable names;
better logic around state_default x legacy_userspace_busy;
remove unecessary mutex;
CC: Chris Wilson ch...@chris-wilson.co.uk
CC: Eric Anholt e...@anholt.net
CC: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h| 8
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 69 ++
drivers/gpu/drm/i915/i915_reg.h| 11 +
drivers/gpu/drm/i915/i915_sysfs.c | 6 ++-
drivers/gpu/drm/i915/intel_display.c | 6 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c| 45 ++-
include/uapi/drm/i915_drm.h| 8 +++-
8 files changed, 149 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 685fb1d..67bbbce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1219,6 +1219,12 @@ struct i915_package_c8 {
} regsave;
};
+struct i915_gt_slices {
+ int state_default;
+ int legacy_userspace_busy;
+ struct mutex lock; /* locks access to this scruct and slice registers */
+};
+
typedef struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *slab;
@@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {
struct i915_package_c8 pc8;
+ struct i915_gt_slices gt_slices;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ce0d47..1d8187a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -923,6 +923,70 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
}
static int
+i915_legacy_userspace_busy(struct drm_device *dev,
+ struct intel_ring_buffer *ring)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ int ret;
+
+ if (!HAS_SLICE_SHUTDOWN(dev) || ring == dev_priv-ring[BCS])
+ return -ENODEV;
+
+ if (dev_priv-gt_slices.state_default == 1)
+ return -EBADE;
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_GT_SLICE_INFO);
+ intel_ring_emit(ring, SLICE_SEL_BOTH);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
+ intel_ring_emit(ring, LOWER_SLICE_ENABLED);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, HSW_SLICESHUTDOWN);
+ intel_ring_emit(ring, ~SLICE_SHUTDOWN);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_1US);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
+ intel_ring_emit(ring, WAIT_RC6_EXIT | MASK_WAIT_RC6_EXIT);
+ intel_ring_advance(ring);
+
+ ret = intel_ring_begin(ring, 3);
+ if (ret)
+ return ret;
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
+ intel_ring_emit(ring, CS_IDLE_COUNT_5US);
+ intel_ring_advance(ring);
+
+ return 0;
+}
+
+static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
@@ -999,6 +1063,11 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
}
+ if ((args-flags I915_EXEC_USE_PREDICATE) == 0
+ !dev_priv-gt_slices.legacy_userspace_busy)
+ if (i915_legacy_userspace_busy(dev, ring) == 0)
+ dev_priv-gt_slices.legacy_userspace_busy = true;
+
mode = args-flags
Re: [Intel-gfx] [PATCH v4] drm/i915: Use a spin lock to protect the pipe crc struct
On Mon, Oct 21, 2013 at 02:29:30PM +0100, Damien Lespiau wrote: Daniel pointed out that it was hard to get anything lockless to work correctly, so don't even try for this non critical piece of code and just use a spin lock. v2: Make intel_pipe_crc-opened a bool v3: Use assert_spin_locked() instead of a comment (Daniel Vetter) v4: Use spin_lock_irq() in the debugfs functions (they can only be called from process context), Use spin_lock() in the pipe_crc_update() function that can only be called from an interrupt handler, Use wait_event_interruptible_lock_irq() when waiting for data in the cicular buffer to ensure proper locking around the condition we are waiting for. (Daniel Vetter) Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Damien Lespiau damien.lesp...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Abstract backlight registers a bit
On Tue, Oct 22, 2013 at 12:30:11AM +0200, Daniel Vetter wrote: On Mon, Oct 21, 2013 at 7:35 PM, Ben Widawsky benjamin.widaw...@intel.com wrote: Many GENs generally perform the same actions just on different registers. This is true going forward as well. To ease the transition a bit, extract the common code where possible. Signed-off-by: Ben Widawsky b...@bwidawsk.net Imo we should just switch to vtables or something like that, since it's not just the register that changes, but also the meaning of the different bits in the registers themselves and the logic to drive stuff. We've often had regression-galore in this code and strictly separating different platforms should help. I hope. -Daniel I do not disagree. I have neither the skill, time, not inclination to do that properly, and I really only care about patch 2. The cleanup here makes the next patch slightly nicer, but I can live with whatever. -- Ben Widawsky, 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 1/2] drm/i915: Abstract backlight registers a bit
On Tue, Oct 22, 2013 at 12:48 AM, Ben Widawsky b...@bwidawsk.net wrote: On Tue, Oct 22, 2013 at 12:30:11AM +0200, Daniel Vetter wrote: On Mon, Oct 21, 2013 at 7:35 PM, Ben Widawsky benjamin.widaw...@intel.com wrote: Many GENs generally perform the same actions just on different registers. This is true going forward as well. To ease the transition a bit, extract the common code where possible. Signed-off-by: Ben Widawsky b...@bwidawsk.net Imo we should just switch to vtables or something like that, since it's not just the register that changes, but also the meaning of the different bits in the registers themselves and the logic to drive stuff. We've often had regression-galore in this code and strictly separating different platforms should help. I hope. -Daniel I do not disagree. I have neither the skill, time, not inclination to do that properly, and I really only care about patch 2. The cleanup here makes the next patch slightly nicer, but I can live with whatever. Personally I vote to keep the ugliness here until someone is fed up and cleans it up for good. Jesse's looking ripe for it, especially since vlv has this new need for a pipe parameter added to the backlight code. So for now I'd just add another if clause all over and copy-paste the existing code for the 2nd patch for -internal. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
