Re: [Intel-gfx] Pointers on debugging my machine not booting: i915 GPU lockup
Hey Gideon, [CCing intel-gfx mailing list] On Wed, 4 Jun 2014 20:22:13 +0530 Gideon D'souza wrote: Thank you so much for your reply. I did manage to move a bit forward with my issue since my email here. When the system kinda stuck, I realized I could press Ctrl + Alt + F2 and I had access to the system via a virtual terminal. I could connect to the internet and everything so it seems like the window manager is dead somehow, I wish I new how. It's such a beautifully customized system I don't want to lose it. (And I barely have time to get it up) It seems to be just a bug somewhere in the 3D driver stack, not a hardware issue. If you can disable 3D and/or compositing effects you might get to your desktop environment. What kind of box is it? Dell Laptop, x86_64 AMD. If you can hook up a serial console to your box that would maybe help, at least getting access to what has been shown prior to screen going blank. I've never fully understood what this means? Does this mean that if I set up the right baud rate I can then get a log/output of some sort on a serial cable somewhere? (1) I don't have a serial out on my laptop. I only have hdmi, lan and usb (2) If I did have a serial out, then what would I do next? Hook up a serial cable, connect it to another computer and then what? What would I install on the other end to read the input? If you had a serial port on the laptop you could connect a second computer to it with a null-modem cable (if needed via USB-Serial converter) and see what output kernel generates using e.g. minicom. Hooking up a USB-Serial converter on your laptop to get serial port would probably not work. This is what the log looks like just before it hangs up: https://www.dropbox.com/s/gyz1sbllyqhuz10/Photo%2031-05-14%2012%2056%2038%20am.jpg I've put up much more detail here: https://ask.fedoraproject.org/en/question/47850/fedora-is-busted-and-hangs-on-boot/ But no real answers yet. Looking at your report on fedoraproject you seem to have: - Intel GPU (which one?) - System is booting fine, GPU is just locking up when X starts (what are versions of X drivers and mesa?) Make sure to collect the error state (after GPU locked up/screen went black, but before rebooting) as reported in your journald log cat /sys/class/drm/card0/error | gzip -9 /tmp/i915-error-state.gz and attach the resulting file /tmp/i915-error-state.gz to a bug report on https://bugs.freedesktop.org. Also follow the guidelines listed at https://01.org/linuxgraphics/documentation/how-report-bugs when you report the bug so all important information is included. If you can do so from console, check for possible MESA or xf86-video-intel updates. If there are none (that help), manually compiling more recent releases or -git versions of xf86-video-intel, libdrm and mesa might get asked. Bruno On Wed, Jun 4, 2014 at 2:27 AM, Bruno Prémont wrote: On Thu, 29 May 2014 Gideon D'souza wrote: So I usually have the latest mainline kernel (on my fedora box) I've recently sent it tiny refactoring patches. What kind of box is it? Today, I start my machine and it just doesn't start. I had 3.11, 3.12, and a few 3.14 rcs. All show up booting, a few lines print on the screen about various things it does. At some random point the screen is just black and backlit and nothing happens. I tried all kernels, 3.11 and 3.12 and official fedora supported kernels. The rest I installed. Even the fedora rescue system doesn't work. I tried looking into remote debugging linux and keep just getting hits on virtual machine options. It's time I left my training wheels and I want to debug my actual machine and see what's going on. Several of those kernels have debugging support on. I just don't get what wire I need to buy, what really is a JTAG and I just need a pointer on how to set it up. I have another windows machine and an OSX machine around. JTAG is a debugging interface mostly present on ARM system (develoment boards, production boards often have no corresponding pin headers). x86/x86_64 system usually don't have JTAG and serial connectors are getting less common... Then there exists some EHCI (yes USB) based debugging interface but that's all I know about it. Any pointers (pun intended) will be greatly appreciated. If you can hook up a serial console to your box that would maybe help, at least getting access to what has been shown prior to screen going blank. For your kernel you would need to add console=ttyS0 possibly with a few details on baud-rate (see Documentation/kernel-parameters.txt). Depending on your GPU and corresponding drivers, adding nouveau.modeset=0 or radeon.modeset=0 or i915.modeset=0 could get your further in case it's a GPU issue. Also of interest would be whether your system is still alive or not (might react to caps-lock, at least for PS2-conected keyboards), how network interface behaves.
Re: [Intel-gfx] [PATCH v2 2/4] drm/edid: Check for user aspect ratio input
On Mon, May 26, 2014 at 03:37:42PM +0530, Vandana Kannan wrote: In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. v2: Thierry's review comments. - Modified the comment Populate... as per review comments Signed-off-by: Vandana Kannan vandana.kan...@intel.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a4fd2e..2628dd1 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3657,8 +3657,13 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, frame-picture_aspect = HDMI_PICTURE_ASPECT_NONE; - /* Populate picture aspect ratio from CEA mode list */ - if (frame-video_code 0) + /* Populate picture aspect ratio from either user input (if specified) + * or from the CEA mode list + */ Block comments should be of this form: /* * Populate ... * ... mode list. */ + if (mode-picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || + mode-picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) + frame-picture_aspect = mode-picture_aspect_ratio; + else if (frame-video_code 0) frame-picture_aspect = drm_get_cea_aspect_ratio( frame-video_code); With the above fixed, this is: Reviewed-by: Thierry Reding tred...@nvidia.com pgp1AOCOWQPTs.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/crtc: Add property for aspect ratio
On Mon, May 26, 2014 at 03:34:43PM +0530, Vandana Kannan wrote:
[...]
@@ -1344,6 +1350,27 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
+ * drm_mode_create_aspect_ratio_property - create aspect ratio property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
+{
+ if (dev-mode_config.aspect_ratio_property)
+ return 0;
+
+ dev-mode_config.aspect_ratio_property =
+ drm_property_create_enum(dev, 0, aspect ratio,
+ drm_aspect_ratio_enum_list,
+ ARRAY_SIZE(drm_aspect_ratio_enum_list));
Indentation here is funny. Given the long names involved here it's
difficult to make this look good, but at least the last parameter here
could be aligned with the second to last.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31c..1149617 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -801,6 +801,7 @@ struct drm_mode_config {
/* Optional properties */
struct drm_property *scaling_mode_property;
+ struct drm_property *aspect_ratio_property;
struct drm_property *dirty_info_property;
This seems rather randomly inserted into the list. I think either the
list should be sorted alphabetically or you should append new entries.
But that's somewhat bikesheddy, so feel free to ignore.
With my first comment addressed:
Reviewed-by: Thierry Reding tred...@nvidia.com
pgpW84RKLVodb.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add #defines for short/long pulse on gmch platforms
For no reason at all the public docs lack them, and Dave needs them
for his hpd interrupt rework.
Cc: Dave Airlie airl...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 247be2af8097..286f05c63047 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2566,8 +2566,14 @@ enum punit_power_well {
#define PORTC_HOTPLUG_LIVE_STATUS_VLV(1 28)
#define PORTB_HOTPLUG_LIVE_STATUS_VLV(1 29)
#define PORTD_HOTPLUG_INT_STATUS (3 21)
+#define PORTD_HOTPLUG_INT_LONG_PULSE (2 21)
+#define PORTD_HOTPLUG_INT_SHORT_PULSE(1 21)
#define PORTC_HOTPLUG_INT_STATUS (3 19)
+#define PORTC_HOTPLUG_INT_LONG_PULSE (2 19)
+#define PORTC_HOTPLUG_INT_SHORT_PULSE(1 19)
#define PORTB_HOTPLUG_INT_STATUS (3 17)
+#define PORTB_HOTPLUG_INT_LONG_PULSE (2 17)
+#define PORTB_HOTPLUG_INT_SHORT_PLUSE(1 17)
/* CRT/TV common between gen3+ */
#define CRT_HOTPLUG_INT_STATUS (1 11)
#define TV_HOTPLUG_INT_STATUS(1 10)
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/4] drm/crtc: Add property for aspect ratio
Added a property to enable user space to set aspect ratio.
This patch contains declaration of the property and code to create the
property.
v2: Thierry's review comments.
- Made aspect ratio enum generic instead of HDMI/CEA specfic
- Removed usage of temporary aspect_ratio variable
v3: Thierry's review comments.
- Fixed indentation drm_mode_create_aspect_ratio_property()
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Thierry Reding thierry.red...@gmail.com
---
drivers/gpu/drm/drm_crtc.c | 27 +++
include/drm/drm_crtc.h | 2 ++
include/uapi/drm/drm_mode.h | 5 +
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 37a3e07..dcbc033 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -139,6 +139,12 @@ static const struct drm_prop_enum_list
drm_scaling_mode_enum_list[] =
{ DRM_MODE_SCALE_ASPECT, Full aspect },
};
+static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
+ { DRM_MODE_PICTURE_ASPECT_NONE, Automatic },
+ { DRM_MODE_PICTURE_ASPECT_4_3, 4:3 },
+ { DRM_MODE_PICTURE_ASPECT_16_9, 16:9 },
+};
+
/*
* Non-global properties, but required for certain connectors.
*/
@@ -1344,6 +1350,27 @@ int drm_mode_create_scaling_mode_property(struct
drm_device *dev)
EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
/**
+ * drm_mode_create_aspect_ratio_property - create aspect ratio property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
+{
+ if (dev-mode_config.aspect_ratio_property)
+ return 0;
+
+ dev-mode_config.aspect_ratio_property =
+ drm_property_create_enum(dev, 0, aspect ratio,
+ drm_aspect_ratio_enum_list,
+ ARRAY_SIZE(drm_aspect_ratio_enum_list));
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
+
+/**
* drm_mode_create_dirty_property - create dirty property
* @dev: DRM device
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c1c31c..1149617 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -801,6 +801,7 @@ struct drm_mode_config {
/* Optional properties */
struct drm_property *scaling_mode_property;
+ struct drm_property *aspect_ratio_property;
struct drm_property *dirty_info_property;
/* dumb ioctl parameters */
@@ -971,6 +972,7 @@ extern int drm_mode_create_dvi_i_properties(struct
drm_device *dev);
extern int drm_mode_create_tv_properties(struct drm_device *dev, int
num_formats,
char *formats[]);
extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
+extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index f104c26..943b377 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -88,6 +88,11 @@
#define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */
#define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE 0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9 2
+
/* Dithering mode options */
#define DRM_MODE_DITHERING_OFF 0
#define DRM_MODE_DITHERING_ON 1
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/4] drm/edid: Check for user aspect ratio input
In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. v2: Thierry's review comments. - Modified the comment Populate... as per review comments v3: Thierry's review comments. - Modified the comment to block comment format. Signed-off-by: Vandana Kannan vandana.kan...@intel.com Cc: Thierry Reding thierry.red...@gmail.com --- drivers/gpu/drm/drm_edid.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a4fd2e..e76c58c 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3657,8 +3657,14 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, frame-picture_aspect = HDMI_PICTURE_ASPECT_NONE; - /* Populate picture aspect ratio from CEA mode list */ - if (frame-video_code 0) + /* +* Populate picture aspect ratio from either +* user input (if specified) or from the CEA mode list. +*/ + if (mode-picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || + mode-picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) + frame-picture_aspect = mode-picture_aspect_ratio; + else if (frame-video_code 0) frame-picture_aspect = drm_get_cea_aspect_ratio( frame-video_code); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest
On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote:
Move rc6_residency_check to subtest, add new rc6_residency_counter subtest
for pm_rc6_residency IGT case.
I don't really understand what you're trying to do here really. Please
explain better in the commit message not just what the patch does, but
_why_ we need this new subtest.
Also the conversion to tests with subtests has a few issues:
- Everything outside of subtests that touches hw state must be wrapped in
igt_fixture.
- You didn't move the test to the multi-test target in Makefile.sources.
- It looks like the 2nd subtest depends upon the first, they must be
independent.
- Your new tests uses igt_assert where it probably should use igt_skip or
something similar.
Please test that the subtest enumeration works correctly:
- With parameter --list all subtest should be enumareated, but nothing
else. This _must_ work as non-root on non-intel machines.
- Subtests must work individually, you can run them with --run-subtest
name
Cheers, Daniel
Test results run on platforms show as below:
On HSW
---
[root@x-hswu opt]# ./pm_rc6_residency
IGT-Version: 1.6-g35b31df (x86_64) (Linux:
3.15.0-rc3_drm-intel-nightly_0791a3_20140520+ x86_64)
Subtest rc6-residency-check: SUCCESS
This machine doesn't support rc6pp
This machine doesn't support rc6p
This machine entry rc6 status.
The residency counter : 0.999667
Subtest rc6-residency-counter: SUCCESS
On IVB
[root@IVB tests]# ./pm_rc6_residency
IGT-Version: 1.6-g35b31df (x86_64) (Linux: 3.13.6_20140318+ x86_64)
Subtest rc6-residency-check: SUCCESS
This machine entry rc6p status.
The residency counter : 0.997000
Subtest rc6-residency-counter: SUCCESS
On BYT
root@x-byt:/opt# ./pm_rc6_residency
IGT-Version: 1.6-g0d39021 (x86_64) (Linux: 3.14.0_kcloud_ceabbb_20140521+
x86_64)
Subtest rc6-residency-check: SUCCESS
This machine doesn't support rc6pp
This machine doesn't support rc6p
The residency counter : 1.144333
Test assertion failure function rc6_residency_counter, file
pm_rc6_residency.c:131:
Last errno: 0, Success
Failed assertion: counter_result =1
Debug files must be wrong,
Subtest rc6-residency-counter: FAIL
On BDW
---
[root@x-bdw01 opt]# ./pm_rc6_residency
IGT-Version: 1.6-g0d39021 (x86_64) (Linux:
3.15.0-rc5_drm-intel-nightly_367653_20140521+ x86_64)
Subtest rc6-residency-check: SUCCESS
This machine doesn't support rc6pp
This machine doesn't support rc6p
The residency counter : 0.994333
This machine entry rc6 state.
Subtest rc6-residency-counter: SUCCESS
Signed-off-by: Liu, Lei A lei.a@intel.com, Wendy Wang
wendy.w...@intel.com
Signed-off-by: Wendy Wang wendy.w...@intel.com
diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 197ab00..550e3ad 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -34,9 +34,11 @@
#include drmtest.h
+#define NUMBER_OF_RC6_RESIDENCY 3
#define SLEEP_DURATION 3000 // in milliseconds
#define RC6_FUDGE 900 // in milliseconds
+
static unsigned int readit(const char *path)
{
unsigned int ret;
@@ -44,8 +46,10 @@ static unsigned int readit(const char *path)
FILE *file;
file = fopen(path, r);
- igt_assert_f(file,
- Couldn't open %s (%d)\n, path, errno);
+ if (file == NULL) {
+ fprintf(stderr, Couldn't open %s (%d)\n, path, errno);
+ abort();
+ }
scanned = fscanf(file, %u, ret);
igt_assert(scanned == 1);
@@ -54,62 +58,112 @@ static unsigned int readit(const char *path)
return ret;
}
-igt_simple_main
+static void read_rc6_residency( int value[], const char
*name_of_rc6_residency[])
{
const int device = drm_get_card();
- char *path, *pathp, *pathpp;
- int fd, ret;
- unsigned int value1, value1p, value1pp, value2, value2p, value2pp;
+ char *path ;
+ int ret;
FILE *file;
- int diff;
-
- igt_skip_on_simulation();
-
- /* Use drm_open_any to verify device existence */
- fd = drm_open_any();
- close(fd);
-
- ret = asprintf(path, /sys/class/drm/card%d/power/rc6_enable, device);
- igt_assert(ret != -1);
/* For some reason my ivb isn't idle even after syncing up with the gpu.
* Let's add a sleept just to make it happy. */
sleep(5);
- file = fopen(path, r);
+ ret = asprintf(path, /sys/class/drm/card%d/power/rc6_enable, device);
+ igt_assert(ret != -1);
+
+ file = fopen(path, r);//open
igt_require(file);
/* claim success if no rc6 enabled. */
if (readit(path) == 0)
igt_success();
- ret = asprintf(path, /sys/class/drm/card%d/power/rc6_residency_ms,
device);
- igt_assert(ret != -1);
- ret = asprintf(pathp,
[Intel-gfx] [PATCH] drm: Fix getconnector connection_mutex locking
I've fumbled my own idea and enthusiastically wrapped all the
getconnector code with the connection_mutex. But we only need it to
chase the connector-encoder link. Even there it's not really needed
since races with userspace won't matter, but better paranoid and
consistent about this stuff.
If we grap it everywhere connector probe callbacks can't grab it
themselves, which means they'll deadlock. i915 does that for the load
detect pipe. Furthermore i915 needs to do a ww dance since we also
need to grab the mutex of the load detect crtc.
This is a regression from
commit 6e9f798d91c526982cca0026cd451e8fdbf18aaf
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu May 29 23:54:47 2014 +0200
drm: Split connection_mutex out of mode_config.mutex (v3)
Cc: Rob Clark robdcl...@gmail.com
Cc: Dave Airlie airl...@redhat.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b8cc4fe0a0f7..fe94cc10cd35 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1838,7 +1838,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
DRM_DEBUG_KMS([CONNECTOR:%d:?]\n, out_resp-connector_id);
mutex_lock(dev-mode_config.mutex);
- drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
connector = drm_connector_find(dev, out_resp-connector_id);
if (!connector) {
@@ -1872,10 +1871,12 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp-mm_height = connector-display_info.height_mm;
out_resp-subpixel = connector-display_info.subpixel_order;
out_resp-connection = connector-status;
+ drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
if (connector-encoder)
out_resp-encoder_id = connector-encoder-base.id;
else
out_resp-encoder_id = 0;
+ drm_modeset_unlock(dev-mode_config.connection_mutex);
/*
* This ioctl is called twice, once to determine how much space is
@@ -1937,7 +1938,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp-count_encoders = encoders_count;
out:
- drm_modeset_unlock(dev-mode_config.connection_mutex);
mutex_unlock(dev-mode_config.mutex);
return ret;
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace remaining drm_get_connector_name(c) by c-name.
On Wed, Jun 04, 2014 at 04:55:20PM -0300, Paulo Zanoni wrote:
2014-06-04 15:47 GMT-03:00 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Yeah, this seems to make -nightly compile.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Sorry my script for fixing up the -nightly build failed. I've spotted this
but then lost the manual fixup patch again :(
Should work now correctly and Dave is doing a backport of drm-fixes into
drm-next to resolve this. My apologies for the mess I've caused here.
-Daniel
---
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index e768207..b5448d8 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -390,7 +390,7 @@ static bool intel_fb_initial_config(struct
drm_fb_helper *fb_helper,
/* No preferred mode marked by the EDID? Are there any
modes? */
if (!modes[i] !list_empty(connector-modes)) {
DRM_DEBUG_KMS(using first mode listed on connector
%s\n,
- drm_get_connector_name(connector));
+ connector-name);
modes[i] = list_first_entry(connector-modes,
struct drm_display_mode,
head);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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: Update PSR on resume.
On Wed, Jun 04, 2014 at 12:17:14PM -0700, Rodrigo Vivi wrote: On Wed, May 28, 2014 at 5:57 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 27, 2014 at 04:50:14PM -0700, Rodrigo Vivi wrote: Some registers set during setup might not be persistent after suspend/resume. This was causing bugs for some people that was unable to get PSR entry state after resume cycle. v2: Adding some comments and better commit message explaining why this is needed. Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com --- drivers/gpu/drm/i915/i915_suspend.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c index 56785e8..1923708 100644 --- a/drivers/gpu/drm/i915/i915_suspend.c +++ b/drivers/gpu/drm/i915/i915_suspend.c @@ -288,6 +288,12 @@ static void i915_restore_display(struct drm_device *dev) I915_WRITE(PP_CONTROL, dev_priv-regfile.savePP_CONTROL); } + /* Forcing a full init sequence after resume to make sure all + * registers are properly set. Some might not be persistent after + * suspend/resume cycle. */ + dev_priv-psr.setup_done = false; + intel_edp_psr_update(dev); No, crtc_enable should take care of this. There's more places (like after runtime pm) where the hw has potentially lost all register contents, so crtc_enabl is the right place for this. -Daniel crtc_enable takes care of the update, but not the setup part that is done only once... I do believe that only the setup_done = false is really needed here, but doesn't heart to trigger the update right here and fixes the bug... restore_display hurts. If there's some setup we need to do, we _really_ need to do it in crtc_enable. Splattering setup code all over the code is one of the prime sources of bugs we have wrt rpm, s/r and driver load. -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: leave rc6 enabled at suspend time v4
On Wed, Jun 04, 2014 at 01:45:22PM -0700, Jesse Barnes wrote:
This allows the system to enter the lowest power mode during system freeze.
v2: delete force wake timer at suspend (Imre)
v3: add GT work suspend function (Imre)
v4: use uncore forcewake reset (Daniel)
Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Someone please look at
https://bugs.freedesktop.org/show_bug.cgi?id=78059
Yes, I'm starting to block semi-related feature work on regressions
because we suck that much.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_pm.c | 20
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 66c6ffb..7148eac 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,7 +521,7 @@ static int i915_drm_freeze(struct drm_device *dev)
drm_irq_uninstall(dev);
dev_priv-enable_hotplug_processing = false;
- intel_disable_gt_powersave(dev);
+ intel_suspend_gt_powersave(dev);
/*
* Disable CRTCs directly since we want to preserve sw state
@@ -542,8 +542,8 @@ static int i915_drm_freeze(struct drm_device *dev)
i915_save_state(dev);
+ intel_uncore_forcewake_reset(dev, false);
intel_opregion_fini(dev);
- intel_uncore_fini(dev);
console_lock();
intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bea9ab40..89d6b47 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2084,6 +2084,7 @@ extern void intel_uncore_early_sanitize(struct
drm_device *dev);
extern void intel_uncore_init(struct drm_device *dev);
extern void intel_uncore_check_errors(struct drm_device *dev);
extern void intel_uncore_fini(struct drm_device *dev);
+extern void intel_uncore_forcewake_reset(struct drm_device *dev, bool
restore);
void
i915_enable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe,
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index c597b0d..74fbe4d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -957,6 +957,7 @@ void intel_init_gt_powersave(struct drm_device *dev);
void intel_cleanup_gt_powersave(struct drm_device *dev);
void intel_enable_gt_powersave(struct drm_device *dev);
void intel_disable_gt_powersave(struct drm_device *dev);
+void intel_suspend_gt_powersave(struct drm_device *dev);
void intel_reset_gt_powersave(struct drm_device *dev);
void ironlake_teardown_rc6(struct drm_device *dev);
void gen6_update_ring_freq(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1840d15..139eebe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4864,6 +4864,26 @@ void intel_cleanup_gt_powersave(struct drm_device *dev)
valleyview_cleanup_gt_powersave(dev);
}
+/**
+ * intel_suspend_gt_powersave - suspend PM work and helper threads
+ * @dev: drm device
+ *
+ * We don't want to disable RC6 or other features here, we just want
+ * to make sure any work we've queued has finished and won't bother
+ * us while we're suspended.
+ */
+void intel_suspend_gt_powersave(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /* Interrupts should be disabled already to avoid re-arming. */
+ WARN_ON(dev-irq_enabled);
+
+ flush_delayed_work(dev_priv-rps.delayed_resume_work);
+
+ cancel_work_sync(dev_priv-rps.work);
+}
+
void intel_disable_gt_powersave(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 871c284..741a4e3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -316,7 +316,7 @@ static void gen6_force_wake_timer(unsigned long arg)
intel_runtime_pm_put(dev_priv);
}
-static void intel_uncore_forcewake_reset(struct drm_device *dev, bool
restore)
+void intel_uncore_forcewake_reset(struct drm_device *dev, bool restore)
{
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long irqflags;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915: revert intel_dp_probe_oui call during HPD interrupt handler
On Wed, Jun 04, 2014 at 03:29:41PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
Remove OUI read function from the lower half interrupt handler. Upon
closing the eDP panel lid an HPD interrupt is generated. The lower half
handler calls intel_dp_probe_oui() as part of intel_dp_detect().
intel_dp_probe_oui() enables eDP VDD and subsequently disables eDP VDD
causing another HPD interrupt. This cycle repeats every 3.6 seconds with
VDD asserted for 3.5 of those seconds until the lid is opened again.
Revert of 0d198328538276c4459ef5de081e68ae60e6c4c2
Revert of 351cfc34db8decb0c5cc1aac7cf1780a0e45c8b1
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
Hm, this is funky ... we currently don't handle port A hotplug events, and
we filter hotplug events properly.
How does this exactly blow up for you? Or is this port D?
We might want to have some filtering here checking whether the edp panel
is on or off. Also the delayed work is _way_ too long.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a00cb8..246d2c1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2867,27 +2867,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
}
-static void
-intel_dp_probe_oui(struct intel_dp *intel_dp)
-{
- u8 buf[3];
-
- if (!(intel_dp-dpcd[DP_DOWN_STREAM_PORT_COUNT] DP_OUI_SUPPORT))
- return;
-
- intel_edp_panel_vdd_on(intel_dp);
-
- if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_OUI, buf, 3) == 3)
- DRM_DEBUG_KMS(Sink OUI: %02hx%02hx%02hx\n,
- buf[0], buf[1], buf[2]);
-
- if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_BRANCH_OUI, buf, 3) == 3)
- DRM_DEBUG_KMS(Branch OUI: %02hx%02hx%02hx\n,
- buf[0], buf[1], buf[2]);
-
- edp_panel_vdd_off(intel_dp, false);
-}
-
int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -3178,8 +3157,6 @@ intel_dp_detect(struct drm_connector *connector, bool
force)
if (status != connector_status_connected)
goto out;
- intel_dp_probe_oui(intel_dp);
-
if (intel_dp-force_audio != HDMI_AUDIO_AUTO) {
intel_dp-has_audio = (intel_dp-force_audio == HDMI_AUDIO_ON);
} else {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+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 v3 2/4] drm/edid: Check for user aspect ratio input
On Thu, Jun 05, 2014 at 02:45:29PM +0530, Vandana Kannan wrote: In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. v2: Thierry's review comments. - Modified the comment Populate... as per review comments v3: Thierry's review comments. - Modified the comment to block comment format. Signed-off-by: Vandana Kannan vandana.kan...@intel.com Cc: Thierry Reding thierry.red...@gmail.com --- drivers/gpu/drm/drm_edid.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7a4fd2e..e76c58c 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3657,8 +3657,14 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, frame-picture_aspect = HDMI_PICTURE_ASPECT_NONE; - /* Populate picture aspect ratio from CEA mode list */ - if (frame-video_code 0) + /* + * Populate picture aspect ratio from either + * user input (if specified) or from the CEA mode list. + */ This still looks slightly odd. Why not use the full available width on the first line of the comment? But either way: Reviewed-by: Thierry Reding tred...@nvidia.com pgpQok5Y4QLgn.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: BDW: Adding missing cursor offsets.
On Wed, Jun 04, 2014 at 05:16:25PM -0700, Ben Widawsky wrote: On Wed, Jun 04, 2014 at 05:09:30PM -0700, Rodrigo Vivi wrote: BDW uses IVB cursor offsets. Whithout this patch it is not possible to use multiple outputs with cursor on BDW. The cursor gets completely crazy because update position uses the wrong cursor register for the second pipe. Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com Reviewed-by: Ben Widawsky b...@bwidawsk.net Thanks. Should be cc: stable IMO [snip] Agreed. -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: Replace remaining drm_get_connector_name(c) by c-name.
On Thu, Jun 05, 2014 at 11:13:58AM +0200, Daniel Vetter wrote:
On Wed, Jun 04, 2014 at 04:55:20PM -0300, Paulo Zanoni wrote:
2014-06-04 15:47 GMT-03:00 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Yeah, this seems to make -nightly compile.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Sorry my script for fixing up the -nightly build failed. I've spotted this
but then lost the manual fixup patch again :(
Should work now correctly and Dave is doing a backport of drm-fixes into
drm-next to resolve this. My apologies for the mess I've caused here.
Forgotten to add Dave.
-Daniel
---
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index e768207..b5448d8 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -390,7 +390,7 @@ static bool intel_fb_initial_config(struct
drm_fb_helper *fb_helper,
/* No preferred mode marked by the EDID? Are there any
modes? */
if (!modes[i] !list_empty(connector-modes)) {
DRM_DEBUG_KMS(using first mode listed on
connector %s\n,
- drm_get_connector_name(connector));
+ connector-name);
modes[i] = list_first_entry(connector-modes,
struct
drm_display_mode,
head);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 v3 1/4] drm/crtc: Add property for aspect ratio
On Thu, Jun 05, 2014 at 02:40:08PM +0530, Vandana Kannan wrote:
[...]
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
[...]
/**
+ * drm_mode_create_aspect_ratio_property - create aspect ratio property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
+{
+ if (dev-mode_config.aspect_ratio_property)
+ return 0;
+
+ dev-mode_config.aspect_ratio_property =
+ drm_property_create_enum(dev, 0, aspect ratio,
+ drm_aspect_ratio_enum_list,
+ ARRAY_SIZE(drm_aspect_ratio_enum_list));
+
+ return 0;
Sorry for not noticing this before: what if drm_propert_create_enum()
fails? Should that return an error? This function will currently
silently ignore failure to create the property.
Thierry
pgpm_kPq56T0t.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reorder semaphore deadlock check
If a semaphore is waiting on another ring, which in turn happens to be waiting on the first ring, but that second semaphore has been signalled, we will be able to kick the second ring and so can treat the first ring as a valid WAIT and not as HUNG. References: https://bugs.freedesktop.org/show_bug.cgi?id=54226 References: https://bugs.freedesktop.org/show_bug.cgi?id=75502 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_irq.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index a702303eab08..41eeeb60c60f 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2834,7 +2834,7 @@ static int semaphore_passed(struct intel_engine_cs *ring) ring-hangcheck.deadlock = true; signaller = semaphore_waits_for(ring, seqno); - if (signaller == NULL || signaller-hangcheck.deadlock) + if (signaller == NULL) return -1; /* cursory check for an unkickable deadlock */ @@ -2842,7 +2842,13 @@ static int semaphore_passed(struct intel_engine_cs *ring) if (ctl RING_WAIT_SEMAPHORE semaphore_passed(signaller) 0) return -1; - return i915_seqno_passed(signaller-get_seqno(signaller, false), seqno); + if (i915_seqno_passed(signaller-get_seqno(signaller, false), seqno)) + return 1; + + if (signaller-hangcheck.deadlock) + return -1; + + return 0; } static void semaphore_clear_deadlocks(struct drm_i915_private *dev_priv) -- 2.0.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP
The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP detection works across platforms Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com --- drivers/gpu/drm/i915/intel_bios.h | 10 +- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.h b/drivers/gpu/drm/i915/intel_bios.h index b986677..30d02b7 100644 --- a/drivers/gpu/drm/i915/intel_bios.h +++ b/drivers/gpu/drm/i915/intel_bios.h @@ -710,16 +710,8 @@ int intel_parse_bios(struct drm_device *dev); */ #define DEVICE_TYPE_eDP_BITS \ (DEVICE_TYPE_INTERNAL_CONNECTOR | \ -DEVICE_TYPE_NOT_HDMI_OUTPUT | \ -DEVICE_TYPE_MIPI_OUTPUT | \ -DEVICE_TYPE_COMPOSITE_OUTPUT | \ -DEVICE_TYPE_DUAL_CHANNEL | \ -DEVICE_TYPE_LVDS_SINGALING | \ -DEVICE_TYPE_TMDS_DVI_SIGNALING | \ -DEVICE_TYPE_VIDEO_SIGNALING | \ DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ -DEVICE_TYPE_DIGITAL_OUTPUT | \ -DEVICE_TYPE_ANALOG_OUTPUT) +DEVICE_TYPE_DIGITAL_OUTPUT) /* define the DVO port for HDMI output type */ #defineDVO_B 1 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dad3780..68f7380 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3842,8 +3842,8 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port port) p_child = dev_priv-vbt.child_dev + i; if (p_child-common.dvo_port == port_mapping[port] - (p_child-common.device_type DEVICE_TYPE_eDP_BITS) == - (DEVICE_TYPE_eDP DEVICE_TYPE_eDP_BITS)) + ((p_child-common.device_type DEVICE_TYPE_eDP_BITS) == +DEVICE_TYPE_eDP_BITS)) return true; } return false; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP
On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP detection works across platforms The current bits will match correctly for 0x1806. I don't have a problem with the patch per-say but would be nice to know what the troublesome device type really was, if indeed there was one. I'm just slightly worried that we might start to get false positives on some platforms if we make it too relaxed. Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com --- drivers/gpu/drm/i915/intel_bios.h | 10 +- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 2 files changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_bios.h b/drivers/gpu/drm/i915/intel_bios.h index b986677..30d02b7 100644 --- a/drivers/gpu/drm/i915/intel_bios.h +++ b/drivers/gpu/drm/i915/intel_bios.h @@ -710,16 +710,8 @@ int intel_parse_bios(struct drm_device *dev); */ #define DEVICE_TYPE_eDP_BITS \ (DEVICE_TYPE_INTERNAL_CONNECTOR | \ - DEVICE_TYPE_NOT_HDMI_OUTPUT | \ - DEVICE_TYPE_MIPI_OUTPUT | \ - DEVICE_TYPE_COMPOSITE_OUTPUT | \ - DEVICE_TYPE_DUAL_CHANNEL | \ - DEVICE_TYPE_LVDS_SINGALING | \ - DEVICE_TYPE_TMDS_DVI_SIGNALING | \ - DEVICE_TYPE_VIDEO_SIGNALING | \ DEVICE_TYPE_DISPLAYPORT_OUTPUT | \ - DEVICE_TYPE_DIGITAL_OUTPUT | \ - DEVICE_TYPE_ANALOG_OUTPUT) + DEVICE_TYPE_DIGITAL_OUTPUT) /* define the DVO port for HDMI output type */ #define DVO_B 1 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dad3780..68f7380 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3842,8 +3842,8 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port port) p_child = dev_priv-vbt.child_dev + i; if (p_child-common.dvo_port == port_mapping[port] - (p_child-common.device_type DEVICE_TYPE_eDP_BITS) == - (DEVICE_TYPE_eDP DEVICE_TYPE_eDP_BITS)) + ((p_child-common.device_type DEVICE_TYPE_eDP_BITS) == + DEVICE_TYPE_eDP_BITS)) return true; } return false; -- 1.9.1 ___ 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] backlight: Don't read back backlight setting from kernel on DPMS off
We've several reports from users where the backlight comes up turned off
on starting X, when using video.use_native_backlight=1 (true dmi quirks, will
be the default for 3.16), in combination with having an external display
plugged in:
https://bugzilla.redhat.com/show_bug.cgi?id=1032978
https://bugzilla.redhat.com/show_bug.cgi?id=1103806
This seems to be caused by /sys/class/backlight/intel_backlight/brightness
reading back 0 when re-initializing the outputs. Unlike
/sys/class/backlight/acpi_video0/brightness which is used without the
video.use_native_backlight=1 param, which keeps returning the value from before
Here is an excerpt from Xorg.log when this happens:
[28225]: (II) intel(0): resizing framebuffer to 3286x1080
[28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 0 using LVDS1,
position (0, 0), rotation normal
[28225]: (II) intel(0): switch to mode 1920x1080@60.0 on pipe 0 using HDMI2,
position (1366, 0), rotation normal
[28225]: (II) intel(0): DPMS off mode 3, saved backlight level 0
^^^ This is an extra debug line I added, mode == the mode parameter to
xxx_output_dpms_backlight, saved backlight level is the value of
backlight_active_level after the xxx_output_backlight_get call.
Note how backlight_active_level becomes 0 here.
[28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 1 using LVDS1,
position (0, 0), rotation normal
[28225]: (II) intel(0): DPMS on mode 0, setting backlight to 0
And here we restore the backlight to backlight_active_level which now is 0.
This commit fixes this by not reading back the backlight setting from the
kernel on DPMS off.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/sna/sna_display.c | 3 ---
src/uxa/intel_display.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 13dbf64..c9d4b08 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -2323,9 +2323,6 @@ sna_output_dpms_backlight(xf86OutputPtr output, int
oldmode, int mode)
sna_output_backlight_set(output,
sna_output-backlight_active_level);
} else {
- /* Only save the current backlight value if we're going from on
to off. */
- if (oldmode == DPMSModeOn)
- sna_output-backlight_active_level =
sna_output_backlight_get(output);
sna_output_backlight_set(output, 0);
}
}
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 95ddcc8..62902f4 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -963,9 +963,6 @@ intel_output_dpms_backlight(xf86OutputPtr output, int
oldmode, int mode)
intel_output_backlight_set(output,
intel_output-backlight_active_level);
} else {
- /* Only save the current backlight value if we're going from on
to off. */
- if (oldmode == DPMSModeOn)
- intel_output-backlight_active_level =
intel_output_backlight_get(output);
intel_output_backlight_set(output, 0);
}
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off
On Thu, 05 Jun 2014, Hans de Goede hdego...@redhat.com wrote:
We've several reports from users where the backlight comes up turned off
on starting X, when using video.use_native_backlight=1 (true dmi quirks, will
be the default for 3.16), in combination with having an external display
plugged in:
https://bugzilla.redhat.com/show_bug.cgi?id=1032978
https://bugzilla.redhat.com/show_bug.cgi?id=1103806
This seems to be caused by /sys/class/backlight/intel_backlight/brightness
reading back 0 when re-initializing the outputs. Unlike
/sys/class/backlight/acpi_video0/brightness which is used without the
video.use_native_backlight=1 param, which keeps returning the value from
before
Here is an excerpt from Xorg.log when this happens:
[28225]: (II) intel(0): resizing framebuffer to 3286x1080
[28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 0 using LVDS1,
position (0, 0), rotation normal
[28225]: (II) intel(0): switch to mode 1920x1080@60.0 on pipe 0 using HDMI2,
position (1366, 0), rotation normal
[28225]: (II) intel(0): DPMS off mode 3, saved backlight level 0
^^^ This is an extra debug line I added, mode == the mode parameter to
xxx_output_dpms_backlight, saved backlight level is the value of
backlight_active_level after the xxx_output_backlight_get call.
Note how backlight_active_level becomes 0 here.
[28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 1 using LVDS1,
position (0, 0), rotation normal
[28225]: (II) intel(0): DPMS on mode 0, setting backlight to 0
And here we restore the backlight to backlight_active_level which now is 0.
This commit fixes this by not reading back the backlight setting from the
kernel on DPMS off.
I'm not at all familiar with the code base you're changing, and I'm just
speculating here, but this seems a little odd.
My guess is that the sna_output_backlight_get and/or
intel_output_backlight_get functions read the actual_brightness sysfs
file, which reads back the value from hardware. This is the contract for
backlight class device. The acpi video implementation returns the cached
value if there's no BQC or BCQ method.
I think perhaps either the current brightness should be read before
switching off the output, or the brightness sysfs file should be used
(which returns the cached current value). Or, perhaps, your patch is the
right answer, as I think we should save the value across disable/enable
anyway.
Chris?
BR,
Jani.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/sna/sna_display.c | 3 ---
src/uxa/intel_display.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 13dbf64..c9d4b08 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -2323,9 +2323,6 @@ sna_output_dpms_backlight(xf86OutputPtr output, int
oldmode, int mode)
sna_output_backlight_set(output,
sna_output-backlight_active_level);
} else {
- /* Only save the current backlight value if we're going from on
to off. */
- if (oldmode == DPMSModeOn)
- sna_output-backlight_active_level =
sna_output_backlight_get(output);
sna_output_backlight_set(output, 0);
}
}
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 95ddcc8..62902f4 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -963,9 +963,6 @@ intel_output_dpms_backlight(xf86OutputPtr output, int
oldmode, int mode)
intel_output_backlight_set(output,
intel_output-backlight_active_level);
} else {
- /* Only save the current backlight value if we're going from on
to off. */
- if (oldmode == DPMSModeOn)
- intel_output-backlight_active_level =
intel_output_backlight_get(output);
intel_output_backlight_set(output, 0);
}
}
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix getconnector connection_mutex locking
On Thu, Jun 5, 2014 at 5:12 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
I've fumbled my own idea and enthusiastically wrapped all the
getconnector code with the connection_mutex. But we only need it to
chase the connector-encoder link. Even there it's not really needed
since races with userspace won't matter, but better paranoid and
consistent about this stuff.
If we grap it everywhere connector probe callbacks can't grab it
themselves, which means they'll deadlock. i915 does that for the load
detect pipe. Furthermore i915 needs to do a ww dance since we also
need to grab the mutex of the load detect crtc.
This is a regression from
commit 6e9f798d91c526982cca0026cd451e8fdbf18aaf
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu May 29 23:54:47 2014 +0200
drm: Split connection_mutex out of mode_config.mutex (v3)
Cc: Rob Clark robdcl...@gmail.com
Cc: Dave Airlie airl...@redhat.com
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/drm_crtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b8cc4fe0a0f7..fe94cc10cd35 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1838,7 +1838,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
DRM_DEBUG_KMS([CONNECTOR:%d:?]\n, out_resp-connector_id);
mutex_lock(dev-mode_config.mutex);
- drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
connector = drm_connector_find(dev, out_resp-connector_id);
if (!connector) {
@@ -1872,10 +1871,12 @@ int drm_mode_getconnector(struct drm_device *dev,
void *data,
out_resp-mm_height = connector-display_info.height_mm;
out_resp-subpixel = connector-display_info.subpixel_order;
out_resp-connection = connector-status;
+ drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
if (connector-encoder)
out_resp-encoder_id = connector-encoder-base.id;
else
out_resp-encoder_id = 0;
+ drm_modeset_unlock(dev-mode_config.connection_mutex);
/*
* This ioctl is called twice, once to determine how much space is
@@ -1937,7 +1938,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp-count_encoders = encoders_count;
out:
- drm_modeset_unlock(dev-mode_config.connection_mutex);
mutex_unlock(dev-mode_config.mutex);
return ret;
--
2.0.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off
On Thu, Jun 05, 2014 at 05:01:23PM +0300, Jani Nikula wrote: On Thu, 05 Jun 2014, Hans de Goede hdego...@redhat.com wrote: We've several reports from users where the backlight comes up turned off on starting X, when using video.use_native_backlight=1 (true dmi quirks, will be the default for 3.16), in combination with having an external display plugged in: https://bugzilla.redhat.com/show_bug.cgi?id=1032978 https://bugzilla.redhat.com/show_bug.cgi?id=1103806 This seems to be caused by /sys/class/backlight/intel_backlight/brightness reading back 0 when re-initializing the outputs. Unlike /sys/class/backlight/acpi_video0/brightness which is used without the video.use_native_backlight=1 param, which keeps returning the value from before Here is an excerpt from Xorg.log when this happens: [28225]: (II) intel(0): resizing framebuffer to 3286x1080 [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 0 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): switch to mode 1920x1080@60.0 on pipe 0 using HDMI2, position (1366, 0), rotation normal [28225]: (II) intel(0): DPMS off mode 3, saved backlight level 0 ^^^ This is an extra debug line I added, mode == the mode parameter to xxx_output_dpms_backlight, saved backlight level is the value of backlight_active_level after the xxx_output_backlight_get call. Note how backlight_active_level becomes 0 here. [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 1 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): DPMS on mode 0, setting backlight to 0 And here we restore the backlight to backlight_active_level which now is 0. This commit fixes this by not reading back the backlight setting from the kernel on DPMS off. I'm not at all familiar with the code base you're changing, and I'm just speculating here, but this seems a little odd. My guess is that the sna_output_backlight_get and/or intel_output_backlight_get functions read the actual_brightness sysfs file, which reads back the value from hardware. This is the contract for backlight class device. The acpi video implementation returns the cached value if there's no BQC or BCQ method. I think perhaps either the current brightness should be read before switching off the output. It is read before we switch off the CRTC (and thus the output). So where it is getting the zero from is a puzzle - it should be the current state of the hardware, ergo what the user set by some other path. -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 4/5] drm/i915: Fixup global gtt cleanup
The global gtt is setup up in 2 parts, so we need to be careful
with the cleanup. For consistency shovel it all into the -cleanup
callback, like with ppgtt.
Noticed because it blew up in the out_gtt: cleanup code while
fiddling with the vgacon code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 4
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 -
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b9159ade5e85..27fe65ac5940 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1386,7 +1386,6 @@ cleanup_gem:
i915_gem_context_fini(dev);
mutex_unlock(dev-struct_mutex);
WARN_ON(dev_priv-mm.aliasing_ppgtt);
- drm_mm_takedown(dev_priv-gtt.base.mm);
cleanup_irq:
drm_irq_uninstall(dev);
cleanup_gem_stolen:
@@ -1756,8 +1755,6 @@ out_mtrrfree:
arch_phys_wc_del(dev_priv-gtt.mtrr);
io_mapping_free(dev_priv-gtt.mappable);
out_gtt:
- list_del(dev_priv-gtt.base.global_link);
- drm_mm_takedown(dev_priv-gtt.base.mm);
dev_priv-gtt.base.cleanup(dev_priv-gtt.base);
out_regs:
intel_uncore_fini(dev);
@@ -1846,7 +1843,6 @@ int i915_driver_unload(struct drm_device *dev)
i915_free_hws(dev);
}
- list_del(dev_priv-gtt.base.global_link);
WARN_ON(!list_empty(dev_priv-vm_list));
drm_vblank_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 931b906f292a..41e864ec5632 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1985,7 +1985,10 @@ static void gen6_gmch_remove(struct i915_address_space
*vm)
struct i915_gtt *gtt = container_of(vm, struct i915_gtt, base);
- drm_mm_takedown(vm-mm);
+ if (drm_mm_initialized(vm-mm)) {
+ drm_mm_takedown(vm-mm);
+ list_del(vm-global_link);
+ }
iounmap(gtt-gsm);
teardown_scratch_page(vm-dev);
}
@@ -2018,6 +2021,10 @@ static int i915_gmch_probe(struct drm_device *dev,
static void i915_gmch_remove(struct i915_address_space *vm)
{
+ if (drm_mm_initialized(vm-mm)) {
+ drm_mm_takedown(vm-mm);
+ list_del(vm-global_link);
+ }
intel_gmch_remove();
}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] vt: Fix replacement console check when unbinding
I don't fully understand the magic of the vt register/unregister
logic, but apparently everything but the inital console (as set
in the conswitchp pointer) is marked with FLAG_MODULE. Which means
if something unregistered the boot vt driver (e.g. i915.ko kicking
out vga_con) there's nothing left when trying to unbind e.g. fbcon
through sysfs.
But we always have the dummy console hanging around, so this test
is fairly dubious. What we actually want is simply a different console
than the one we want to unbind.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/tty/vt/vt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 3ad0b61e35b4..ea600f482eeb 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3155,8 +3155,7 @@ int do_unbind_con_driver(const struct consw *csw, int
first, int last, int deflt
for (i = 0; i MAX_NR_CON_DRIVER; i++) {
con_back = registered_con_driver[i];
- if (con_back-con
- !(con_back-flag CON_DRIVER_FLAG_MODULE)) {
+ if (con_back-con con_back-con != csw) {
defcsw = con_back-con;
retval = 0;
break;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Apparently this also prevents unclaimed register errors on hsw and
hard machine hangs on my i855gm when trying to unbind fbcon.
Also, we want this to make I915_FBDEV=n safe.
v2: Rebase and pimp commit message.
v3: We also need to unregister the vga console, otherwise the unbind
of the fb console before module unload might resurrect it again.
v4: Ignore errors when the vga console is already unregistered - this
can happen when e.g. reloading i915.ko.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813
Cc: David Herrmann dh.herrm...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-fb...@vger.kernel.org
Cc: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk (v1)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 43 +++-
drivers/video/console/dummycon.c | 1 +
drivers/video/console/vgacon.c | 1 +
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 27fe65ac5940..bcb66ddd649e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -36,6 +36,8 @@
#include i915_drv.h
#include i915_trace.h
#include linux/pci.h
+#include linux/console.h
+#include linux/vt.h
#include linux/vgaarb.h
#include linux/acpi.h
#include linux/pnp.h
@@ -1449,6 +1451,38 @@ static void i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
}
#endif
+#if !defined(CONFIG_VGA_CONSOLE)
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+ return 0;
+}
+#elif !defined(CONFIG_DUMMY_CONSOLE)
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+ return -ENODEV;
+}
+#else
+static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
+{
+ int ret;
+
+ DRM_INFO(Replacing VGA console driver\n);
+
+ console_lock();
+ ret = do_take_over_console(dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
+ if (ret == 0) {
+ ret = do_unregister_con_driver(vga_con);
+
+ /* Ignore already unregistered. */
+ if (ret == -ENODEV)
+ ret = 0;
+ }
+ console_unlock();
+
+ return ret;
+}
+#endif
+
static void i915_dump_device_info(struct drm_i915_private *dev_priv)
{
const struct intel_device_info *info = dev_priv-info;
@@ -1622,8 +1656,15 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto out_regs;
- if (drm_core_check_feature(dev, DRIVER_MODESET))
+ if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ ret = i915_kick_out_vgacon(dev_priv);
+ if (ret) {
+ DRM_ERROR(failed to remove conflicting VGA console\n);
+ goto out_gtt;
+ }
+
i915_kick_out_firmware_fb(dev_priv);
+ }
pci_set_master(dev-pdev);
diff --git a/drivers/video/console/dummycon.c b/drivers/video/console/dummycon.c
index b63860f7beab..40bec8d64b0a 100644
--- a/drivers/video/console/dummycon.c
+++ b/drivers/video/console/dummycon.c
@@ -77,3 +77,4 @@ const struct consw dummy_con = {
.con_set_palette = DUMMY,
.con_scrolldelta = DUMMY,
};
+EXPORT_SYMBOL_GPL(dummy_con);
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 9d8feac67637..84acd6223dc5 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -1440,5 +1440,6 @@ const struct consw vga_con = {
.con_build_attr = vgacon_build_attr,
.con_invert_region = vgacon_invert_region,
};
+EXPORT_SYMBOL(vga_con);
MODULE_LICENSE(GPL);
--
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/5] vt: Fix up unregistration of vt drivers
A bunch of issues:
- We should not kick out the default console (which is tracked in
conswitchp), so check for that.
- Add better error codes so callers can differentiate between something
went wrong and your driver isn't registered already. i915 needs
that so it doesn't fall over when reloading the driver and hence
vga_con is already unregistered.
- There's a mess with the driver flags: What we need to check for is
that the driver isn't used any more, i.e. unbound completely (FLAG_INIT).
And not whether it's the boot console or not (which is the only one
which doesn't have FLAG_MODULE). Otherwise there's no way to kick
out the boot console, which i915 wants to do to prevent havoc with
vga_con interferring (which tends to hang machines).
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/tty/vt/vt.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index ea600f482eeb..5077fe87324d 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3573,17 +3573,20 @@ err:
*/
int do_unregister_con_driver(const struct consw *csw)
{
- int i, retval = -ENODEV;
+ int i;
/* cannot unregister a bound driver */
if (con_is_bound(csw))
- goto err;
+ return -EBUSY;
+
+ if (csw == conswitchp)
+ return -EINVAL;
for (i = 0; i MAX_NR_CON_DRIVER; i++) {
struct con_driver *con_driver = registered_con_driver[i];
if (con_driver-con == csw
- con_driver-flag CON_DRIVER_FLAG_MODULE) {
+ con_driver-flag CON_DRIVER_FLAG_INIT) {
vtconsole_deinit_device(con_driver);
device_destroy(vtconsole_class,
MKDEV(0, con_driver-node));
@@ -3594,12 +3597,11 @@ int do_unregister_con_driver(const struct consw *csw)
con_driver-flag = 0;
con_driver-first = 0;
con_driver-last = 0;
- retval = 0;
- break;
+ return 0;
}
}
-err:
- return retval;
+
+ return -ENODEV;
}
EXPORT_SYMBOL_GPL(do_unregister_con_driver);
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Make the physical object coherent with GTT
Currently objects for which the hardware needs a contiguous physical
address are allocated a shadow backing storage to satisfy the contraint.
This shadow buffer is not wired into the normal obj-pages and so the
physical object is incoherent with accesses via the GPU, GTT and CPU. By
setting up the appropriate scatter-gather table, we can allow userspace
to access the physical object via either a GTT mmaping of or by rendering
into the GEM bo. However, keeping the CPU mmap of the shmemfs backing
storage coherent with the contiguous shadow is not yet possible.
Fortuituously, CPU mmaps of objects requiring physical addresses are not
expected to be coherent anyway.
This allows the physical constraint of the GEM object to be transparent
to userspace and allow it to efficiently render into or update them via
the GTT and GPU.
v2: Fix leak of pci handle spotted by Ville
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gem.c | 197 +++-
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 142 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4a0b4d22faff..4811c635ab12 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1025,6 +1025,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version();
break;
+ case I915_PARAM_HAS_COHERENT_PHYS_GTT:
+ value = 1;
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8da2de4c997b..b39f1782ded7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1715,10 +1715,10 @@ struct drm_i915_gem_object {
unsigned long user_pin_count;
struct drm_file *pin_filp;
- /** for phy allocated objects */
- drm_dma_handle_t *phys_handle;
-
union {
+ /** for phy allocated objects */
+ drm_dma_handle_t *phys_handle;
+
struct i915_gem_userptr {
uintptr_t ptr;
unsigned read_only :1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 71d77c8fc77b..5f44524369ff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -210,40 +210,137 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-static void i915_gem_object_detach_phys(struct drm_i915_gem_object *obj)
+static int
+i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj)
{
- drm_dma_handle_t *phys = obj-phys_handle;
+ struct address_space *mapping = file_inode(obj-base.filp)-i_mapping;
+ char *vaddr = obj-phys_handle-vaddr;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int i;
- if (!phys)
- return;
+ if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
+ return -EINVAL;
+
+ for (i = 0; i obj-base.size / PAGE_SIZE; i++) {
+ struct page *page;
+ char *src;
+
+ page = shmem_read_mapping_page(mapping, i);
+ if (IS_ERR(page))
+ return PTR_ERR(page);
+
+ src = kmap_atomic(page);
+ memcpy(vaddr, src, PAGE_SIZE);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
+ kunmap_atomic(src);
+
+ page_cache_release(page);
+ vaddr += PAGE_SIZE;
+ }
+
+ i915_gem_chipset_flush(obj-base.dev);
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (st == NULL)
+ return -ENOMEM;
+
+ if (sg_alloc_table(st, 1, GFP_KERNEL)) {
+ kfree(st);
+ return -ENOMEM;
+ }
- if (obj-madv == I915_MADV_WILLNEED) {
+ sg = st-sgl;
+ sg-offset = 0;
+ sg-length = obj-base.size;
+
+ sg_dma_address(sg) = obj-phys_handle-busaddr;
+ sg_dma_len(sg) = obj-base.size;
+
+ obj-pages = st;
+ obj-has_dma_mapping = true;
+ return 0;
+}
+
+static void
+i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj)
+{
+ int ret;
+
+ BUG_ON(obj-madv == __I915_MADV_PURGED);
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret) {
+ /* In the event of a disaster, abandon all caches and
+* hope for the best.
+*/
+ WARN_ON(ret != -EIO);
+ obj-base.read_domains = obj-base.write_domain =
I915_GEM_DOMAIN_CPU;
+ }
+
+ if (obj-madv ==
[Intel-gfx] [PATCH] resume timings
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/intel_display.c | 9 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0f9e836..a2036b2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -625,6 +625,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ DRM_ERROR(start thaw\n);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)
restore_gtt_mappings) {
mutex_lock(dev-struct_mutex);
@@ -652,7 +654,9 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
intel_modeset_init_hw(dev);
+ DRM_ERROR(hw state start\n);
schedule_work(dev_priv-hw_restore_work);
+ DRM_ERROR(hw state end\n);
/*
* ... but also need to make sure that hotplug processing
@@ -685,6 +689,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool
restore_gtt_mappings)
mutex_unlock(dev_priv-modeset_restore_lock);
intel_runtime_pm_put(dev_priv);
+
+ DRM_ERROR(end thaw\n);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6d6b0f2..472b7f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12175,7 +12175,9 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
struct intel_encoder *encoder;
int i;
+ DRM_ERROR(\n);
intel_modeset_readout_hw_state(dev);
+ DRM_ERROR(readout complete\n);
/*
* Now that we have the config, copy it to each CRTC struct
@@ -12197,12 +12199,16 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
intel_sanitize_encoder(encoder);
}
+ DRM_ERROR(done with encoder sanitize\n);
+
for_each_pipe(pipe) {
crtc = to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
intel_sanitize_crtc(crtc);
intel_dump_pipe_config(crtc, crtc-config, [setup_hw_state]);
}
+ DRM_ERROR(done with crtc sanitize\n);
+
for (i = 0; i dev_priv-num_shared_dpll; i++) {
struct intel_shared_dpll *pll = dev_priv-shared_dplls[i];
@@ -12215,6 +12221,8 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
pll-on = false;
}
+ DRM_ERROR(done with pll enable\n);
+
if (HAS_PCH_SPLIT(dev))
ilk_wm_get_hw_state(dev);
@@ -12231,6 +12239,7 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
__intel_set_mode(crtc, crtc-mode, crtc-x, crtc-y,
crtc-primary-fb);
+ DRM_ERROR(done with modeset on %d\n, pipe);
}
} else {
intel_modeset_update_staged_output_state(dev);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: leave rc6 enabled at suspend time v4
On Thu, 5 Jun 2014 11:21:02 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jun 04, 2014 at 01:45:22PM -0700, Jesse Barnes wrote: This allows the system to enter the lowest power mode during system freeze. v2: delete force wake timer at suspend (Imre) v3: add GT work suspend function (Imre) v4: use uncore forcewake reset (Daniel) Signed-off-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Someone please look at https://bugs.freedesktop.org/show_bug.cgi?id=78059 Yes, I'm starting to block semi-related feature work on regressions because we suck that much. Chris said a fix was already available... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP
On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP detection works across platforms The current bits will match correctly for 0x1806. I don't have a problem with the patch per-say but would be nice to know what the troublesome device type really was, if indeed there was one. I'm just slightly worried that we might start to get false positives on some platforms if we make it too relaxed. Still waiting for results, but https://bugs.freedesktop.org/show_bug.cgi?id=78795 was what motivated this. Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] New async patch for resume
In digging into the async crtc stuff, I found it was going to be really difficult to prevent other functions from getting clobbered by a delayed crtc enable or disable. Daniel's work to remove a bunch of the -mode_set callbacks is a good start, but we still end up doing some reg reads and writes in the mode set path today. Until those are cleared up and we somehow enforce a rule that all hw changes go through the crtc enable/disable paths with everything else staged in multithread safe structs, I don't think the async crtc approach will be solid. So, since resume is the biggest issue here anyway, I've tried making just the resume mode set asynchronous. Even this is a bit tricky, since we need to apply any pending mode set at certain points, then check whether the crtc we're operating on in any given path is still active. I think I've caught those cases here, but if we have more we can use the intel_sync_mode_set() call with appropriate post-call checks (after we re-acquire the corresponding crtc mutex). Feedback welcome. This has seen light testing on my BYT and really reduces the time spend in the i915 _thaw function, letting userspace start running much sooner than before. Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] drm/i915: Fix 830M/ns2501 for real, well almost
From: Ville Syrjälä ville.syrj...@linux.intel.com
Since the 830M dragon popped up again, I figured I'd dig out my old patches
that try to fix it.
I ended up reworking the primary plane code a bit also to eliminate the
DSPCNTR/DSPADDR RMW accesses since those are dangerous on 830M. But I think
the end result is more in line where we want to go anyway with the primary
planes anyway.
This has been tested on my Lifebook S6010 and this is the first time two
displays work reliably on this thing. Additionally we still need the minimum
watermark fix, for now I just used a hack (didn't include it here).
The only thing that doesn't work is suspend to ram. It suspends but won't
wake up, but that happens w/o i915 also so I can't take the blame for that.
I pushed the lot to [1] and the watermark hack is included there as well.
[1] git://gitorious.org/vsyrjala/linux.git alm_fixes4
Ville Syrjälä (15):
drm/i915: Use named initializers for gmch wm params
drm/i915: Fix gen2 planes B and C max watermark value
drm/i915: Don't get hw state from DVO chip unless DVO is enabled
drm/i915: ns2501 is on DVOB
drm/i915: Enable DVO between mode_set and dpms hooks
drm/i915: Don't call DVO mode_set hook on DPMS changes
drm/i915: Kill useless ns2501_dump_regs
drm/i915: Rewrite ns2501 driver a bit
drm/i915: Ignore VBT int_crt_support on 830M
drm/i915: Fix DVO 2x clock enable on 830M
Revert drm/i915: Nuke pipe A quirk on i830M
drm/i915: Add pipe B force quirk for 830M
drm/i915: Eliminate rmw from .update_primary_plane()
drm/i915: Call .update_primary_plane in
intel_{enable,disable}_primary_hw_plane()
drm/i915: Check pixel clock in ns2501 mode_valid hook
drivers/gpu/drm/i915/dvo_ns2501.c| 552 +--
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/intel_display.c | 310 ++--
drivers/gpu/drm/i915/intel_dvo.c | 19 +-
drivers/gpu/drm/i915/intel_pm.c | 154 +-
5 files changed, 580 insertions(+), 459 deletions(-)
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: Use named initializers for gmch wm params
From: Ville Syrjälä ville.syrj...@linux.intel.com
Using names initializers when filling out the watermark structs
saves you from having go look up the struct definition every
single time.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 130
1 file changed, 65 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..f83d1ff 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -865,95 +865,95 @@ static int i845_get_fifo_size(struct drm_device *dev, int
plane)
/* Pineview has different values for various configs */
static const struct intel_watermark_params pineview_display_wm = {
- PINEVIEW_DISPLAY_FIFO,
- PINEVIEW_MAX_WM,
- PINEVIEW_DFT_WM,
- PINEVIEW_GUARD_WM,
- PINEVIEW_FIFO_LINE_SIZE
+ .fifo_size = PINEVIEW_DISPLAY_FIFO,
+ .max_wm = PINEVIEW_MAX_WM,
+ .default_wm = PINEVIEW_DFT_WM,
+ .guard_size = PINEVIEW_GUARD_WM,
+ .cacheline_size = PINEVIEW_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params pineview_display_hplloff_wm = {
- PINEVIEW_DISPLAY_FIFO,
- PINEVIEW_MAX_WM,
- PINEVIEW_DFT_HPLLOFF_WM,
- PINEVIEW_GUARD_WM,
- PINEVIEW_FIFO_LINE_SIZE
+ .fifo_size = PINEVIEW_DISPLAY_FIFO,
+ .max_wm = PINEVIEW_MAX_WM,
+ .default_wm = PINEVIEW_DFT_HPLLOFF_WM,
+ .guard_size = PINEVIEW_GUARD_WM,
+ .cacheline_size = PINEVIEW_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params pineview_cursor_wm = {
- PINEVIEW_CURSOR_FIFO,
- PINEVIEW_CURSOR_MAX_WM,
- PINEVIEW_CURSOR_DFT_WM,
- PINEVIEW_CURSOR_GUARD_WM,
- PINEVIEW_FIFO_LINE_SIZE,
+ .fifo_size = PINEVIEW_CURSOR_FIFO,
+ .max_wm = PINEVIEW_CURSOR_MAX_WM,
+ .default_wm = PINEVIEW_CURSOR_DFT_WM,
+ .guard_size = PINEVIEW_CURSOR_GUARD_WM,
+ .cacheline_size = PINEVIEW_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params pineview_cursor_hplloff_wm = {
- PINEVIEW_CURSOR_FIFO,
- PINEVIEW_CURSOR_MAX_WM,
- PINEVIEW_CURSOR_DFT_WM,
- PINEVIEW_CURSOR_GUARD_WM,
- PINEVIEW_FIFO_LINE_SIZE
+ .fifo_size = PINEVIEW_CURSOR_FIFO,
+ .max_wm = PINEVIEW_CURSOR_MAX_WM,
+ .default_wm = PINEVIEW_CURSOR_DFT_WM,
+ .guard_size = PINEVIEW_CURSOR_GUARD_WM,
+ .cacheline_size = PINEVIEW_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params g4x_wm_info = {
- G4X_FIFO_SIZE,
- G4X_MAX_WM,
- G4X_MAX_WM,
- 2,
- G4X_FIFO_LINE_SIZE,
+ .fifo_size = G4X_FIFO_SIZE,
+ .max_wm = G4X_MAX_WM,
+ .default_wm = G4X_MAX_WM,
+ .guard_size = 2,
+ .cacheline_size = G4X_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params g4x_cursor_wm_info = {
- I965_CURSOR_FIFO,
- I965_CURSOR_MAX_WM,
- I965_CURSOR_DFT_WM,
- 2,
- G4X_FIFO_LINE_SIZE,
+ .fifo_size = I965_CURSOR_FIFO,
+ .max_wm = I965_CURSOR_MAX_WM,
+ .default_wm = I965_CURSOR_DFT_WM,
+ .guard_size = 2,
+ .cacheline_size = G4X_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params valleyview_wm_info = {
- VALLEYVIEW_FIFO_SIZE,
- VALLEYVIEW_MAX_WM,
- VALLEYVIEW_MAX_WM,
- 2,
- G4X_FIFO_LINE_SIZE,
+ .fifo_size = VALLEYVIEW_FIFO_SIZE,
+ .max_wm = VALLEYVIEW_MAX_WM,
+ .default_wm = VALLEYVIEW_MAX_WM,
+ .guard_size = 2,
+ .cacheline_size = G4X_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params valleyview_cursor_wm_info = {
- I965_CURSOR_FIFO,
- VALLEYVIEW_CURSOR_MAX_WM,
- I965_CURSOR_DFT_WM,
- 2,
- G4X_FIFO_LINE_SIZE,
+ .fifo_size = I965_CURSOR_FIFO,
+ .max_wm = VALLEYVIEW_CURSOR_MAX_WM,
+ .default_wm = I965_CURSOR_DFT_WM,
+ .guard_size = 2,
+ .cacheline_size = G4X_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params i965_cursor_wm_info = {
- I965_CURSOR_FIFO,
- I965_CURSOR_MAX_WM,
- I965_CURSOR_DFT_WM,
- 2,
- I915_FIFO_LINE_SIZE,
+ .fifo_size = I965_CURSOR_FIFO,
+ .max_wm = I965_CURSOR_MAX_WM,
+ .default_wm = I965_CURSOR_DFT_WM,
+ .guard_size = 2,
+ .cacheline_size = I915_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params i945_wm_info = {
- I945_FIFO_SIZE,
- I915_MAX_WM,
- 1,
- 2,
- I915_FIFO_LINE_SIZE
+ .fifo_size = I945_FIFO_SIZE,
+ .max_wm = I915_MAX_WM,
+ .default_wm = 1,
+ .guard_size = 2,
+ .cacheline_size = I915_FIFO_LINE_SIZE,
};
static const struct intel_watermark_params i915_wm_info = {
- I915_FIFO_SIZE,
- I915_MAX_WM,
- 1,
- 2,
- I915_FIFO_LINE_SIZE
+ .fifo_size = I915_FIFO_SIZE,
+ .max_wm = I915_MAX_WM,
+ .default_wm = 1,
+
[Intel-gfx] [PATCH 06/15] drm/i915: Don't call DVO mode_set hook on DPMS changes
From: Ville Syrjälä ville.syrj...@linux.intel.com
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dvo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 463cd40..ad01c3f 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -227,10 +227,6 @@ static void intel_dvo_dpms(struct drm_connector
*connector, int mode)
intel_crtc_update_dpms(crtc);
- intel_dvo-dev.dev_ops-mode_set(intel_dvo-dev,
-config-requested_mode,
-config-adjusted_mode);
-
intel_dvo-dev.dev_ops-dpms(intel_dvo-dev, true);
} else {
intel_dvo-dev.dev_ops-dpms(intel_dvo-dev, false);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915: Fix gen2 planes B and C max watermark value
From: Ville Syrjälä ville.syrj...@linux.intel.com
The max watermark value for gen2 planes B and C is 0x1f, instead of
the 0x3f that plane A uses.
Also check against the max even if the pipe is disabled since the
FIFO size exceeds the plane B and C max watermark value.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f83d1ff..03904de 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -941,13 +941,20 @@ static const struct intel_watermark_params i915_wm_info =
{
.guard_size = 2,
.cacheline_size = I915_FIFO_LINE_SIZE,
};
-static const struct intel_watermark_params i830_wm_info = {
+static const struct intel_watermark_params i830_a_wm_info = {
.fifo_size = I855GM_FIFO_SIZE,
.max_wm = I915_MAX_WM,
.default_wm = 1,
.guard_size = 2,
.cacheline_size = I830_FIFO_LINE_SIZE,
};
+static const struct intel_watermark_params i830_bc_wm_info = {
+ .fifo_size = I855GM_FIFO_SIZE,
+ .max_wm = I915_MAX_WM/2,
+ .default_wm = 1,
+ .guard_size = 2,
+ .cacheline_size = I830_FIFO_LINE_SIZE,
+};
static const struct intel_watermark_params i845_wm_info = {
.fifo_size = I830_FIFO_SIZE,
.max_wm = I915_MAX_WM,
@@ -1506,7 +1513,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
else if (!IS_GEN2(dev))
wm_info = i915_wm_info;
else
- wm_info = i830_wm_info;
+ wm_info = i830_a_wm_info;
fifo_size = dev_priv-display.get_fifo_size(dev, 0);
crtc = intel_get_crtc_for_plane(dev, 0);
@@ -1521,8 +1528,14 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
wm_info, fifo_size, cpp,
latency_ns);
enabled = crtc;
- } else
+ } else {
planea_wm = fifo_size - wm_info-guard_size;
+ if (planea_wm (long)wm_info-max_wm)
+ planea_wm = wm_info-max_wm;
+ }
+
+ if (IS_GEN2(dev))
+ wm_info = i830_bc_wm_info;
fifo_size = dev_priv-display.get_fifo_size(dev, 1);
crtc = intel_get_crtc_for_plane(dev, 1);
@@ -1540,8 +1553,11 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
enabled = crtc;
else
enabled = NULL;
- } else
+ } else {
planeb_wm = fifo_size - wm_info-guard_size;
+ if (planeb_wm (long)wm_info-max_wm)
+ planeb_wm = wm_info-max_wm;
+ }
DRM_DEBUG_KMS(FIFO watermarks - A: %d, B: %d\n, planea_wm, planeb_wm);
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915: Ignore VBT int_crt_support on 830M
From: Ville Syrjälä ville.syrj...@linux.intel.com
My Fujitsu-Siemens Lifebook S6010 definitely has a VGA connector, but
the VBT says different. Ignore the VBT for 830M since it seems such
old machines would generally have a VGA connector.
This is a regression caused by:
commit 9c2a03c2a194c086949f25d332937ac8dc4d9f7e
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri Apr 4 16:12:07 2014 -0700
drm/i915: use VBT to determine whether to enumerate the VGA port
While at it refactor the code a bit to be more pleasing to the eye.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..3d51ceb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11368,6 +11368,21 @@ const char *intel_output_name(int output)
return names[output];
}
+static bool intel_crt_support(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ /* no hardware support whatsoever */
+ if (IS_ULT(dev) || IS_CHERRYVIEW(dev))
+ return false;
+
+ /* Fujitsu-Siemens Lifebook S6010 VBT lies */
+ if (IS_I830(dev))
+ return true;
+
+ return dev_priv-vbt.int_crt_support;
+}
+
static void intel_setup_outputs(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -11376,7 +11391,7 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_lvds_init(dev);
- if (!IS_ULT(dev) !IS_CHERRYVIEW(dev)
dev_priv-vbt.int_crt_support)
+ if (intel_crt_support(dev))
intel_crt_init(dev);
if (HAS_DDI(dev)) {
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] Revert drm/i915: Nuke pipe A quirk on i830M
From: Ville Syrjälä ville.syrj...@linux.intel.com
This reverts commit ac6696d3236bd61503f89a1a99680fd7894d5d53.
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af944be..3b6eccd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11934,6 +11934,9 @@ static struct intel_quirk intel_quirks[] = {
/* ThinkPad T60 needs pipe A force quirk (bug #16494) */
{ 0x2782, 0x17aa, 0x201a, quirk_pipea_force },
+ /* 830 needs to leave pipe A dpll A up */
+ { 0x3577, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+
/* Lenovo U160 cannot use SSC on LVDS */
{ 0x0046, 0x17aa, 0x3920, quirk_ssc_force_disable },
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915: Add pipe B force quirk for 830M
From: Ville Syrjälä ville.syrj...@linux.intel.com
830M has problems when some of the pipes are disabled. Namely if a
plane, DVO port etc. is currently assigned to a disabled pipe, it
can't moved to the other pipe until the current pipe is also enabled.
To keep things simple just leave both pipes running all the time.
Ideally I think should turn the pipes off if neither is active, and
when either becomes active we enable both. But that would reuquire
proper atomic modeset support, and probably a bit of extra care in
the order things get enabled.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 41
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 559f098..10e9f68 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ enum intel_sbi_destination {
#define QUIRK_PIPEA_FORCE (10)
#define QUIRK_LVDS_SSC_DISABLE (11)
#define QUIRK_INVERT_BRIGHTNESS (12)
+#define QUIRK_PIPEB_FORCE (13)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3b6eccd..4f02464 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1236,8 +1236,9 @@ void assert_pipe(struct drm_i915_private *dev_priv,
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
pipe);
- /* if we need the pipe A quirk it must be always on */
- if (pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE)
+ /* if we need the pipe quirk it must be always on */
+ if ((pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE) ||
+ (pipe == PIPE_B dev_priv-quirks QUIRK_PIPEB_FORCE))
state = true;
if (!intel_display_power_enabled(dev_priv,
@@ -1713,8 +1714,9 @@ static void i9xx_disable_pll(struct intel_crtc *crtc)
}
}
- /* Don't disable pipe A or pipe A PLLs if needed */
- if (pipe == PIPE_A (dev_priv-quirks QUIRK_PIPEA_FORCE))
+ /* Don't disable pipe or pipe PLLs if needed */
+ if ((pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE) ||
+ (pipe == PIPE_B dev_priv-quirks QUIRK_PIPEB_FORCE))
return;
/* Make sure the pipe isn't still relying on us */
@@ -2078,8 +2080,8 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
reg = PIPECONF(cpu_transcoder);
val = I915_READ(reg);
if (val PIPECONF_ENABLE) {
- WARN_ON(!(pipe == PIPE_A
- dev_priv-quirks QUIRK_PIPEA_FORCE));
+ WARN_ON(!((pipe == PIPE_A dev_priv-quirks
QUIRK_PIPEA_FORCE) ||
+ (pipe == PIPE_B dev_priv-quirks
QUIRK_PIPEB_FORCE)));
return;
}
@@ -2115,8 +2117,9 @@ static void intel_disable_pipe(struct drm_i915_private
*dev_priv,
assert_cursor_disabled(dev_priv, pipe);
assert_sprites_disabled(dev_priv, pipe);
- /* Don't disable pipe A or pipe A PLLs if needed */
- if (pipe == PIPE_A (dev_priv-quirks QUIRK_PIPEA_FORCE))
+ /* Don't disable pipe or pipe PLLs if needed */
+ if ((pipe == PIPE_A dev_priv-quirks QUIRK_PIPEA_FORCE) ||
+ (pipe == PIPE_B dev_priv-quirks QUIRK_PIPEB_FORCE))
return;
reg = PIPECONF(cpu_transcoder);
@@ -5957,9 +5960,9 @@ static void i9xx_set_pipeconf(struct intel_crtc
*intel_crtc)
pipeconf = 0;
- if (dev_priv-quirks QUIRK_PIPEA_FORCE
- I915_READ(PIPECONF(intel_crtc-pipe)) PIPECONF_ENABLE)
- pipeconf |= PIPECONF_ENABLE;
+ if ((intel_crtc-pipe == PIPE_A dev_priv-quirks
QUIRK_PIPEA_FORCE) ||
+ (intel_crtc-pipe == PIPE_B dev_priv-quirks
QUIRK_PIPEB_FORCE))
+ pipeconf |= I915_READ(PIPECONF(intel_crtc-pipe))
PIPECONF_ENABLE;
if (intel_crtc-config.double_wide)
pipeconf |= PIPECONF_DOUBLE_WIDE;
@@ -10232,8 +10235,9 @@ check_crtc_state(struct drm_device *dev)
active = dev_priv-display.get_pipe_config(crtc,
pipe_config);
- /* hw state is inconsistent with the pipe A quirk */
- if (crtc-pipe == PIPE_A dev_priv-quirks
QUIRK_PIPEA_FORCE)
+ /* hw state is inconsistent with the pipe quirk */
+ if ((crtc-pipe == PIPE_A dev_priv-quirks
QUIRK_PIPEA_FORCE) ||
+ (crtc-pipe == PIPE_B dev_priv-quirks
QUIRK_PIPEB_FORCE))
active = crtc-active;
list_for_each_entry(encoder, dev-mode_config.encoder_list,
@@ -11868,6 +11872,14 @@ static void quirk_pipea_force(struct
[Intel-gfx] [PATCH 05/15] drm/i915: Enable DVO between mode_set and dpms hooks
From: Ville Syrjälä ville.syrj...@linux.intel.com To more closely match the IEGD ns2501 driver behaviour, call the mode_set hook while the DVO port is still disabled, then enable the DVO port, and finally call the dpms hook. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_dvo.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c index be560bb..463cd40 100644 --- a/drivers/gpu/drm/i915/intel_dvo.c +++ b/drivers/gpu/drm/i915/intel_dvo.c @@ -185,12 +185,13 @@ static void intel_enable_dvo(struct intel_encoder *encoder) u32 dvo_reg = intel_dvo-dev.dvo_reg; u32 temp = I915_READ(dvo_reg); - I915_WRITE(dvo_reg, temp | DVO_ENABLE); - I915_READ(dvo_reg); intel_dvo-dev.dev_ops-mode_set(intel_dvo-dev, crtc-config.requested_mode, crtc-config.adjusted_mode); + I915_WRITE(dvo_reg, temp | DVO_ENABLE); + I915_READ(dvo_reg); + intel_dvo-dev.dev_ops-dpms(intel_dvo-dev, true); } -- 1.8.5.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/i915: Kill useless ns2501_dump_regs
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 74f2af7..85030d4 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -479,22 +479,6 @@ static void ns2501_dpms(struct intel_dvo_device *dvo, bool
enable)
}
}
-static void ns2501_dump_regs(struct intel_dvo_device *dvo)
-{
- uint8_t val;
-
- ns2501_readb(dvo, NS2501_FREQ_LO, val);
- DRM_DEBUG_KMS(NS2501_FREQ_LO: 0x%02x\n, val);
- ns2501_readb(dvo, NS2501_FREQ_HI, val);
- DRM_DEBUG_KMS(NS2501_FREQ_HI: 0x%02x\n, val);
- ns2501_readb(dvo, NS2501_REG8, val);
- DRM_DEBUG_KMS(NS2501_REG8: 0x%02x\n, val);
- ns2501_readb(dvo, NS2501_REG9, val);
- DRM_DEBUG_KMS(NS2501_REG9: 0x%02x\n, val);
- ns2501_readb(dvo, NS2501_REGC, val);
- DRM_DEBUG_KMS(NS2501_REGC: 0x%02x\n, val);
-}
-
static void ns2501_destroy(struct intel_dvo_device *dvo)
{
struct ns2501_priv *ns = dvo-dev_priv;
@@ -512,6 +496,5 @@ struct intel_dvo_dev_ops ns2501_ops = {
.mode_set = ns2501_mode_set,
.dpms = ns2501_dpms,
.get_hw_state = ns2501_get_hw_state,
- .dump_regs = ns2501_dump_regs,
.destroy = ns2501_destroy,
};
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915: Rewrite ns2501 driver a bit
From: Ville Syrjälä ville.syrj...@linux.intel.com
Try to use the same programming sequence as used by the IEGD driver.
Also shovel the magic register values into a big static const array.
The register values are actually the based on what the BIOS programs
on the Fujitsu-Siemens Lifebook S6010. IEGD seemed to have hardcoded
register values (which also enabled the scaler for 1024x768 mode).
However those didn't actually work so well on the S6010. Possibly the
pipe timings that got used didn't match the ns2501 configuration.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 529 +++---
1 file changed, 325 insertions(+), 204 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 85030d4..b278571 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -60,16 +60,291 @@
#define NS2501_REGC 0x0c
+enum {
+ MODE_640x480,
+ MODE_800x600,
+ MODE_1024x768,
+};
+
+struct ns2501_reg {
+uint8_t offset;
+uint8_t value;
+};
+
+/*
+ * Magic values based on what the BIOS on
+ * Fujitsu-Siemens Lifebook S6010 programs (1024x768 panel).
+ */
+static const struct ns2501_reg regs_1024x768[][86] = {
+ [MODE_640x480] = {
+ [0] = { .offset = 0x0a, .value = 0x81, },
+ [1] = { .offset = 0x18, .value = 0x07, },
+ [2] = { .offset = 0x19, .value = 0x00, },
+ [3] = { .offset = 0x1a, .value = 0x00, },
+ [4] = { .offset = 0x1b, .value = 0x11, },
+ [5] = { .offset = 0x1c, .value = 0x54, },
+ [6] = { .offset = 0x1d, .value = 0x03, },
+ [7] = { .offset = 0x1e, .value = 0x02, },
+ [8] = { .offset = 0xf3, .value = 0x90, },
+ [9] = { .offset = 0xf9, .value = 0x00, },
+ [10] = { .offset = 0xc1, .value = 0x90, },
+ [11] = { .offset = 0xc2, .value = 0x00, },
+ [12] = { .offset = 0xc3, .value = 0x0f, },
+ [13] = { .offset = 0xc4, .value = 0x03, },
+ [14] = { .offset = 0xc5, .value = 0x16, },
+ [15] = { .offset = 0xc6, .value = 0x00, },
+ [16] = { .offset = 0xc7, .value = 0x02, },
+ [17] = { .offset = 0xc8, .value = 0x02, },
+ [18] = { .offset = 0xf4, .value = 0x00, },
+ [19] = { .offset = 0x80, .value = 0xff, },
+ [20] = { .offset = 0x81, .value = 0x07, },
+ [21] = { .offset = 0x82, .value = 0x3d, },
+ [22] = { .offset = 0x83, .value = 0x05, },
+ [23] = { .offset = 0x94, .value = 0x00, },
+ [24] = { .offset = 0x95, .value = 0x00, },
+ [25] = { .offset = 0x96, .value = 0x05, },
+ [26] = { .offset = 0x97, .value = 0x00, },
+ [27] = { .offset = 0x9a, .value = 0x88, },
+ [28] = { .offset = 0x9b, .value = 0x00, },
+ [29] = { .offset = 0x98, .value = 0x00, },
+ [30] = { .offset = 0x99, .value = 0x00, },
+ [31] = { .offset = 0xf7, .value = 0x88, },
+ [32] = { .offset = 0xf8, .value = 0x0a, },
+ [33] = { .offset = 0x9c, .value = 0x24, },
+ [34] = { .offset = 0x9d, .value = 0x00, },
+ [35] = { .offset = 0x9e, .value = 0x25, },
+ [36] = { .offset = 0x9f, .value = 0x03, },
+ [37] = { .offset = 0xa0, .value = 0x28, },
+ [38] = { .offset = 0xa1, .value = 0x01, },
+ [39] = { .offset = 0xa2, .value = 0x28, },
+ [40] = { .offset = 0xa3, .value = 0x05, },
+ [41] = { .offset = 0xb6, .value = 0x09, },
+ [42] = { .offset = 0xb8, .value = 0x00, },
+ [43] = { .offset = 0xb9, .value = 0xa0, },
+ [44] = { .offset = 0xba, .value = 0x00, },
+ [45] = { .offset = 0xbb, .value = 0x20, },
+ [46] = { .offset = 0x10, .value = 0x00, },
+ [47] = { .offset = 0x11, .value = 0xa0, },
+ [48] = { .offset = 0x12, .value = 0x02, },
+ [49] = { .offset = 0x20, .value = 0x00, },
+ [50] = { .offset = 0x22, .value = 0x00, },
+ [51] = { .offset = 0x23, .value = 0x00, },
+ [52] = { .offset = 0x24, .value = 0x00, },
+ [53] = { .offset = 0x25, .value = 0x00, },
+ [54] = { .offset = 0x8c, .value = 0x10, },
+ [55] = { .offset = 0x8d, .value = 0x02, },
+ [56] = { .offset = 0x8e, .value = 0x10, },
+ [57] = { .offset = 0x8f, .value = 0x00, },
+ [58] = { .offset = 0x90, .value = 0xff, },
+ [59] = { .offset = 0x91, .value = 0x07, },
+ [60] = { .offset = 0x92, .value = 0xa0, },
+ [61] = { .offset = 0x93, .value = 0x02, },
+ [62]
[Intel-gfx] [PATCH 13/15] drm/i915: Eliminate rmw from .update_primary_plane()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the entire DSPCNTR register setup into the .update_primary_plane()
functions. That's where it belongs anyway and it'll also help 830M which
has the extra problem that plane registers reads will return the value
latched at the last vblank, not the value that was last written.
Also move DSPPOS and DSPSIZE setup there.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 110 +++
1 file changed, 34 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f02464..74bbab9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2431,20 +2431,31 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
- struct drm_i915_gem_object *obj;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
int plane = intel_crtc-plane;
unsigned long linear_offset;
u32 dspcntr;
- u32 reg;
+ u32 reg = DSPCNTR(plane);
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb-obj;
+ dspcntr = DISPPLANE_GAMMA_ENABLE;
+
+ if (intel_crtc-primary_enabled)
+ dspcntr |= DISPLAY_PLANE_ENABLE;
+
+ if (INTEL_INFO(dev)-gen 4) {
+ if (intel_crtc-pipe == PIPE_B)
+ dspcntr |= DISPPLANE_SEL_PIPE_B;
+
+ /* pipesrc and dspsize control the size that is scaled from,
+* which should always be the user's requested size.
+*/
+ I915_WRITE(DSPSIZE(plane),
+ ((intel_crtc-config.pipe_src_h - 1) 16) |
+ (intel_crtc-config.pipe_src_w - 1));
+ I915_WRITE(DSPPOS(plane), 0);
+ }
- reg = DSPCNTR(plane);
- dspcntr = I915_READ(reg);
- /* Mask out pixel format bits in case we change it */
- dspcntr = ~DISPPLANE_PIXFORMAT_MASK;
switch (fb-pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2476,12 +2487,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
BUG();
}
- if (INTEL_INFO(dev)-gen = 4) {
- if (obj-tiling_mode != I915_TILING_NONE)
- dspcntr |= DISPPLANE_TILED;
- else
- dspcntr = ~DISPPLANE_TILED;
- }
+ if (INTEL_INFO(dev)-gen = 4
+ obj-tiling_mode != I915_TILING_NONE)
+ dspcntr |= DISPPLANE_TILED;
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
@@ -2521,20 +2529,21 @@ static void ironlake_update_primary_plane(struct
drm_crtc *crtc,
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
- struct drm_i915_gem_object *obj;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
int plane = intel_crtc-plane;
unsigned long linear_offset;
u32 dspcntr;
- u32 reg;
+ u32 reg = DSPCNTR(plane);
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb-obj;
+ dspcntr = DISPPLANE_GAMMA_ENABLE;
+
+ if (intel_crtc-primary_enabled)
+ dspcntr |= DISPLAY_PLANE_ENABLE;
+
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ dspcntr |= DISPPLANE_PIPE_CSC_ENABLE;
- reg = DSPCNTR(plane);
- dspcntr = I915_READ(reg);
- /* Mask out pixel format bits in case we change it */
- dspcntr = ~DISPPLANE_PIXFORMAT_MASK;
switch (fb-pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2564,12 +2573,8 @@ static void ironlake_update_primary_plane(struct
drm_crtc *crtc,
if (obj-tiling_mode != I915_TILING_NONE)
dspcntr |= DISPPLANE_TILED;
- else
- dspcntr = ~DISPPLANE_TILED;
- if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- dspcntr = ~DISPPLANE_TRICKLE_FEED_DISABLE;
- else
+ if (!IS_HASWELL(dev) !IS_BROADWELL(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
I915_WRITE(reg, dspcntr);
@@ -4000,7 +4005,6 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *encoder;
int pipe = intel_crtc-pipe;
- enum plane plane = intel_crtc-plane;
WARN_ON(!crtc-enabled);
[Intel-gfx] [PATCH 14/15] drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make the intel_{enable,disable}_primary_hw_plane() simply call
.update_primary_plane(), thus eliminating the rmw from these functions
which should help the poor old 830M.
Now we can also remove the .update_primary_plane() from the
.crtc_enable() hooks.
This also has the nice benefit of making primary planes a bit closer to
the way we handle sprite planes during modesets.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 92 +++-
1 file changed, 27 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 74bbab9..098017a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2147,63 +2147,51 @@ void intel_flush_primary_plane(struct drm_i915_private
*dev_priv,
/**
* intel_enable_primary_hw_plane - enable the primary plane on a given pipe
- * @dev_priv: i915 private structure
- * @plane: plane to enable
- * @pipe: pipe being fed
+ * @plane: plane to be enabled
+ * @crtc: crtc for the plane
*
- * Enable @plane on @pipe, making sure that @pipe is running first.
+ * Enable @plane on @crtc, making sure that the pipe is running first.
*/
-static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_enable_primary_hw_plane(struct drm_plane *plane,
+ struct drm_crtc *crtc)
{
- struct intel_crtc *intel_crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
- int reg;
- u32 val;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
/* If the pipe isn't enabled, we can't pump pixels and may hang */
- assert_pipe_enabled(dev_priv, pipe);
+ assert_pipe_enabled(dev_priv, intel_crtc-pipe);
if (intel_crtc-primary_enabled)
return;
intel_crtc-primary_enabled = true;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- WARN_ON(val DISPLAY_PLANE_ENABLE);
-
- I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
- intel_flush_primary_plane(dev_priv, plane);
+ dev_priv-display.update_primary_plane(crtc, plane-fb,
+ crtc-x, crtc-y);
}
/**
* intel_disable_primary_hw_plane - disable the primary hardware plane
- * @dev_priv: i915 private structure
- * @plane: plane to disable
- * @pipe: pipe consuming the data
+ * @plane: plane to be disabled
+ * @crtc: crtc for the plane
*
- * Disable @plane; should be an independent operation.
+ * Disable @plane on @crtc, making sure that the pipe is running first.
*/
-static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_disable_primary_hw_plane(struct drm_plane *plane,
+ struct drm_crtc *crtc)
{
- struct intel_crtc *intel_crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
- int reg;
- u32 val;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ assert_pipe_enabled(dev_priv, intel_crtc-pipe);
if (!intel_crtc-primary_enabled)
return;
intel_crtc-primary_enabled = false;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- WARN_ON((val DISPLAY_PLANE_ENABLE) == 0);
-
- I915_WRITE(reg, val ~DISPLAY_PLANE_ENABLE);
- intel_flush_primary_plane(dev_priv, plane);
+ dev_priv-display.update_primary_plane(crtc, plane-fb,
+ crtc-x, crtc-y);
}
static bool need_vtd_wa(struct drm_device *dev)
@@ -3955,11 +3943,10 @@ static void intel_crtc_enable_planes(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int pipe = intel_crtc-pipe;
- int plane = intel_crtc-plane;
drm_vblank_on(dev, pipe);
- intel_enable_primary_hw_plane(dev_priv, plane, pipe);
+ intel_enable_primary_hw_plane(crtc-primary, crtc);
intel_enable_planes(crtc);
/* The fixup needs to happen before cursor is enabled */
if (IS_G4X(dev))
@@ -3993,7 +3980,7 @@ static void intel_crtc_disable_planes(struct drm_crtc
*crtc)
intel_crtc_dpms_overlay(intel_crtc, false);
intel_crtc_update_cursor(crtc, false);
intel_disable_planes(crtc);
- intel_disable_primary_hw_plane(dev_priv, plane, pipe);
+ intel_disable_primary_hw_plane(crtc-primary, crtc);
drm_vblank_off(dev, pipe);
}
@@ -4026,9 +4013,6 @@ static void
[Intel-gfx] [PATCH 15/15] drm/i915: Check pixel clock in ns2501 mode_valid hook
From: Ville Syrjälä ville.syrj...@linux.intel.com
The vbt on my Fujitsu-Siemens Lifebook S6010 provides two 800x600 modes,
60Hz and 56Hz. The magic register values we have correspond to the 60Hz
mode, and as I don't know how one would trick the VGA BIOS to set up
the 56Hz mode we can't get the magic values for the orther mode. So
when checking whether a mode is valid also check the pixel clock so that
we filter out the 56Hz variant.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b/drivers/gpu/drm/i915/dvo_ns2501.c
index b278571..64103cb 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -515,9 +515,9 @@ static enum drm_mode_status ns2501_mode_valid(struct
intel_dvo_device *dvo,
* of the panel in here so we could always accept it
* by disabling the scaler.
*/
- if ((mode-hdisplay == 800 mode-vdisplay == 600) ||
- (mode-hdisplay == 640 mode-vdisplay == 480) ||
- (mode-hdisplay == 1024 mode-vdisplay == 768)) {
+ if ((mode-hdisplay == 640 mode-vdisplay == 480 mode-clock ==
25175) ||
+ (mode-hdisplay == 800 mode-vdisplay == 600 mode-clock ==
4) ||
+ (mode-hdisplay == 1024 mode-vdisplay == 768 mode-clock ==
65000)) {
return MODE_OK;
} else {
return MODE_ONE_SIZE; /* Is this a reasonable error? */
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/i915: Fix DVO 2x clock enable on 830M
From: Ville Syrjälä ville.syrj...@linux.intel.com
The spec says:
For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register (06014h-06017h) and DPLL B Control
Register (06018h-0601Bh).
The pipe A and B force quirks take care of DPLL_VCO_ENABLE, so we
just need a bit of special care to handle DPLL_DVO_2X_MODE.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 47 +---
2 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..559f098 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1537,6 +1537,9 @@ struct drm_i915_private {
struct i915_runtime_pm pm;
+ /* used to control DVO 2x clock enable on 830M */
+ uint8_t dvo_pipes;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3d51ceb..af944be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1635,6 +1635,7 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ enum pipe pipe = crtc-pipe;
int reg = DPLL(crtc-pipe);
u32 dpll = crtc-config.dpll_hw_state.dpll;
@@ -1647,7 +1648,16 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
if (IS_MOBILE(dev) !IS_I830(dev))
assert_panel_unlocked(dev_priv, crtc-pipe);
- I915_WRITE(reg, dpll);
+ /* enable DVO 2x clock on both PLLs if necessary */
+ if (IS_I830(dev)) {
+ if (intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DVO))
+ dev_priv-dvo_pipes |= 1 pipe;
+
+ if (dev_priv-dvo_pipes) {
+ dpll |= DPLL_DVO_2X_MODE;
+ I915_WRITE(DPLL(!pipe), I915_READ(DPLL(!pipe)) |
DPLL_DVO_2X_MODE);
+ }
+ }
/* Wait for the clocks to stabilize. */
POSTING_READ(reg);
@@ -1686,8 +1696,23 @@ static void i9xx_enable_pll(struct intel_crtc *crtc)
*
* Note! This is for pre-ILK only.
*/
-static void i9xx_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+static void i9xx_disable_pll(struct intel_crtc *crtc)
{
+ struct drm_device *dev = crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum pipe pipe = crtc-pipe;
+
+ /* disable DVO 2x clock on both PLLs if necessary */
+ if (IS_I830(dev)) {
+ if (intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DVO))
+ dev_priv-dvo_pipes = ~(1 pipe);
+
+ if (!dev_priv-dvo_pipes) {
+ I915_WRITE(DPLL(pipe), I915_READ(DPLL(pipe))
~DPLL_DVO_2X_MODE);
+ I915_WRITE(DPLL(!pipe), I915_READ(DPLL(!pipe))
~DPLL_DVO_2X_MODE);
+ }
+ }
+
/* Don't disable pipe A or pipe A PLLs if needed */
if (pipe == PIPE_A (dev_priv-quirks QUIRK_PIPEA_FORCE))
return;
@@ -4820,7 +4845,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
else if (IS_VALLEYVIEW(dev))
vlv_disable_pll(dev_priv, pipe);
else
- i9xx_disable_pll(dev_priv, pipe);
+ i9xx_disable_pll(intel_crtc);
}
if (!IS_GEN2(dev))
@@ -5781,7 +5806,7 @@ static void i8xx_update_pll(struct intel_crtc *crtc,
dpll |= PLL_P2_DIVIDE_BY_4;
}
- if (intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DVO))
+ if (!IS_I830(dev) intel_pipe_has_type(crtc-base, INTEL_OUTPUT_DVO))
dpll |= DPLL_DVO_2X_MODE;
if (intel_pipe_has_type(crtc-base, INTEL_OUTPUT_LVDS)
@@ -6283,6 +6308,9 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
}
pipe_config-dpll_hw_state.dpll = I915_READ(DPLL(crtc-pipe));
if (!IS_VALLEYVIEW(dev)) {
+ if (IS_I830(dev))
+ pipe_config-dpll_hw_state.dpll = ~DPLL_DVO_2X_MODE;
+
pipe_config-dpll_hw_state.fp0 = I915_READ(FP0(crtc-pipe));
pipe_config-dpll_hw_state.fp1 = I915_READ(FP1(crtc-pipe));
} else {
@@ -12443,6 +12471,17 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
}
}
+ /* update dvo_pipes */
+ if (IS_I830(dev)) {
+ dev_priv-dvo_pipes = 0;
+
+ for_each_intel_crtc(dev, crtc) {
+ if
[Intel-gfx] [PATCH 04/15] drm/i915: ns2501 is on DVOB
From: Ville Syrjälä ville.syrj...@linux.intel.com
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead
of DVOC.
FIXME: Maybe need to dig out the correct DVO port from VBT
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 5d7d975..be560bb 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -85,7 +85,7 @@ static const struct intel_dvo_device intel_dvo_devices[] = {
{
.type = INTEL_DVO_CHIP_TMDS,
.name = ns2501,
- .dvo_reg = DVOC,
+ .dvo_reg = DVOB,
.slave_addr = NS2501_ADDR,
.dev_ops = ns2501_ops,
}
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Wed, 4 Jun 2014 08:04:53 -0700 Stéphane Marchesin marc...@chromium.org wrote: We could have dpms standby mean backlight off, everything else on, similarly to what you want by 0 backlight meaning off. So you could switch between dpms on/standby more quickly. The point in that is that it's the right API for doing panel power sequencing. You see, even with defining backlight 0 = off, we'd have to respect the panel sequencing and delays for backlight (admittedly we currently don't do that, which is why it's fast - and broken). There are multiple delays at play here, and typically the longest panel delays have nothing to do with the backlight but they are the delays for turning the panel on/off (usually the panel on/off delays are much bigger, up to 500ms on some panels). These are the delays I'm trying to avoid. Doing the panel sequencing properly from the backlight interface gets *much* harder because it's all backwards in the stack then. If you implement some interface which does set backlight to 0 on platforms which support it, and do panel off on other platforms, that's fine by me; however I don't want to regress all the other platforms just because BYT has issues. In the current state of things, the functionality set which is made available to user space happens to shrink with your patch. According to the LVDS and eDP timing specs, we *ought* to be able to disable the backlight and then the PWM source and leave everything else alone, as long as we apply the appropriate delays between backlight off and PWM off, and then again when we turn them back on (PWM first, delay, then backlight on). IIRC the issue on BYT was that we saw the panel power line go down when we disabled the backlight and PWM which would obviously cause all sorts of problems. But that could have been user error on the scope, so we should confirm that before baking a full DPMS cycle into the BYT implementation or the interface in general. -- Jesse Barnes, 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] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness
On Wed, 2014-06-04 at 08:04 -0700, Stéphane Marchesin wrote: Well, for example ACPI backlight isn't the default on intel, instead i915 implements its own backlight. ACPI backlight doesn't support as many backlight levels as the native backlight for example. So I do think that ACPI backlight is inferior. ACPI backlight is the default on most pre-Windows 8 i915 systems. Userspace which assumes that backlight value 0 has any specific meaning is broken userspace. Adding an additional interface that allows disabling the backlight without powering down the panel seems like a completely reasonable thing to do, though. -- Matthew Garrett matthew.garr...@nebula.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/6] drm/i915: Don't clobber the GTT when it's within stolen memory
From: Ville Syrjälä ville.syrj...@linux.intel.com
On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.
v2: Deal with gen4 36 bit physical address
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 44 ++
drivers/gpu/drm/i915/i915_reg.h| 3 +++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 62ef55b..7465ab0 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -74,6 +74,50 @@ static unsigned long i915_stolen_to_physical(struct
drm_device *dev)
if (base == 0)
return 0;
+ /* make sure we don't clobber the GTT if it's within stolen memory */
+ if (INTEL_INFO(dev)-gen = 4 !IS_G33(dev) !IS_G4X(dev)) {
+ struct {
+ u32 start, end;
+ } stolen[2] = {
+ { .start = base, .end = base +
dev_priv-gtt.stolen_size, },
+ { .start = base, .end = base +
dev_priv-gtt.stolen_size, },
+ };
+ u64 gtt_start, gtt_end;
+
+ gtt_start = I915_READ(PGTBL_CTL);
+ if (IS_GEN4(dev))
+ gtt_start = (gtt_start PGTBL_ADDRESS_LO_MASK) |
+ (gtt_start PGTBL_ADDRESS_HI_MASK) 28;
+ else
+ gtt_start = PGTBL_ADDRESS_LO_MASK;
+ gtt_end = gtt_start + gtt_total_entries(dev_priv-gtt) * 4;
+
+ if (gtt_start = stolen[0].start gtt_start stolen[0].end)
+ stolen[0].end = gtt_start;
+ if (gtt_end stolen[1].start gtt_end = stolen[1].end)
+ stolen[1].start = gtt_end;
+
+ /* pick the larger of the two chunks */
+ if (stolen[0].end - stolen[0].start
+ stolen[1].end - stolen[1].start) {
+ base = stolen[0].start;
+ dev_priv-gtt.stolen_size = stolen[0].end -
stolen[0].start;
+ } else {
+ base = stolen[1].start;
+ dev_priv-gtt.stolen_size = stolen[1].end -
stolen[1].start;
+ }
+
+ if (stolen[0].start != stolen[1].start ||
+ stolen[0].end != stolen[1].end) {
+ DRM_DEBUG_KMS(GTT within stolen memory at
0x%llx-0x%llx\n,
+ (unsigned long long) gtt_start,
+ (unsigned long long) gtt_end - 1);
+ DRM_DEBUG_KMS(Stolen memory adjusted to 0x%x-0x%x\n,
+ base, base + (u32)
dev_priv-gtt.stolen_size - 1);
+ }
+ }
+
+
/* Verify that nothing else uses this physical address. Stolen
* memory should be reserved by the BIOS and hidden from the
* kernel. So if the region is already marked as busy, something
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 247be2a..619924b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -978,6 +978,9 @@ enum punit_power_well {
/*
* Instruction and interrupt control regs
*/
+#define PGTBL_CTL 0x02020
+#define PGTBL_ADDRESS_LO_MASK0xf000 /* bits [31:12] */
+#define PGTBL_ADDRESS_HI_MASK0x00f0 /* bits [35:32] (gen4) */
#define PGTBL_ER 0x02024
#define RENDER_RING_BASE 0x02000
#define BSD_RING_BASE 0x04000
--
1.8.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest
On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote: Move rc6_residency_check to subtest, add new rc6_residency_counter subtest for pm_rc6_residency IGT case. Looks good to me. You have some formatting issues: for loops don't use the right coding style useless comment to fopen bad sign-off in mail added unnecessary whitespace replace assert with open coded abort So I've merged it with all those warts (except I fixed the signed-off-by). Please keep these things in mind next patch, and feel free to submit patches to fix these issues as well. [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
Reported-by: Jesse Barnes jesse.bar...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 37 +++-
4 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..000a6ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,8 @@ struct i915_power_well {
bool always_on;
/* power well enable/disable usage count */
int count;
+ /* cached hw enabled state */
+ bool hw_enabled;
unsigned long domains;
unsigned long data;
const struct i915_power_well_ops *ops;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..882d4f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12692,8 +12692,8 @@ intel_display_capture_error_state(struct drm_device
*dev)
for_each_pipe(i) {
error-pipe[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
- POWER_DOMAIN_PIPE(i));
+ intel_display_power_enabled_unlocked(dev_priv,
+
POWER_DOMAIN_PIPE(i));
if (!error-pipe[i].power_domain_on)
continue;
@@ -12728,7 +12728,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
enum transcoder cpu_transcoder = transcoders[i];
error-transcoder[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
+ intel_display_power_enabled_unlocked(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
if (!error-transcoder[i].power_domain_on)
continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 78d4124..1455ddb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,8 +948,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_remove(struct drm_i915_private *);
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain);
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..96a2d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5801,8 +5801,8 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
}
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain)
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain)
{
struct i915_power_domains *power_domains;
struct i915_power_well *power_well;
@@ -5813,16 +5813,19 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
return false;
power_domains = dev_priv-power_domains;
+
is_enabled = true;
+
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
if (power_well-always_on)
continue;
- if (!power_well-count) {
+ if (!power_well-hw_enabled) {
is_enabled = false;
break;
}
}
+
return is_enabled;
}
@@ -5830,30 +5833,15 @@ bool intel_display_power_enabled(struct
drm_i915_private *dev_priv,
Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
On Thu, 5 Jun 2014 20:31:47 +0300
Imre Deak imre.d...@intel.com wrote:
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
Reported-by: Jesse Barnes jesse.bar...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 37
+++-
4 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..000a6ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,8 @@ struct i915_power_well {
bool always_on;
/* power well enable/disable usage count */
int count;
+ /* cached hw enabled state */
+ bool hw_enabled;
unsigned long domains;
unsigned long data;
const struct i915_power_well_ops *ops;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..882d4f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12692,8 +12692,8 @@ intel_display_capture_error_state(struct drm_device
*dev)
for_each_pipe(i) {
error-pipe[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
-POWER_DOMAIN_PIPE(i));
+ intel_display_power_enabled_unlocked(dev_priv,
+
POWER_DOMAIN_PIPE(i));
if (!error-pipe[i].power_domain_on)
continue;
@@ -12728,7 +12728,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
enum transcoder cpu_transcoder = transcoders[i];
error-transcoder[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
+ intel_display_power_enabled_unlocked(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
if (!error-transcoder[i].power_domain_on)
continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 78d4124..1455ddb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,8 +948,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_remove(struct drm_i915_private *);
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain);
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..96a2d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5801,8 +5801,8 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
}
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain)
+bool intel_display_power_enabled_unlocked(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain
domain)
{
struct i915_power_domains *power_domains;
struct i915_power_well *power_well;
@@ -5813,16 +5813,19 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
return false;
power_domains = dev_priv-power_domains;
+
is_enabled = true;
+
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
if (power_well-always_on)
continue;
- if (!power_well-count) {
+ if (!power_well-hw_enabled) {
is_enabled = false;
break;
}
}
+
return is_enabled;
}
@@ -5830,30
Re: [Intel-gfx] [PATCH] drm/i915: cache hw power well enabled state
On Thu, 2014-06-05 at 10:35 -0700, Jesse Barnes wrote:
On Thu, 5 Jun 2014 20:31:47 +0300
Imre Deak imre.d...@intel.com wrote:
Jesse noticed that the punit communication needed to query the VLV power
well status can cause substantial delays. Since we can query the state
frequently, for example during I2C transfers, maintain a cached version
of the HW state to get rid of this delay.
This fixes at least one reported regression where boot time increased by
~4 seconds due to frequent power well state queries on VLV during eDP
EDID read.
Reported-by: Jesse Barnes jesse.bar...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 37
+++-
4 files changed, 22 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..000a6ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -976,6 +976,8 @@ struct i915_power_well {
bool always_on;
/* power well enable/disable usage count */
int count;
+ /* cached hw enabled state */
+ bool hw_enabled;
unsigned long domains;
unsigned long data;
const struct i915_power_well_ops *ops;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..882d4f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12692,8 +12692,8 @@ intel_display_capture_error_state(struct drm_device
*dev)
for_each_pipe(i) {
error-pipe[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
- POWER_DOMAIN_PIPE(i));
+ intel_display_power_enabled_unlocked(dev_priv,
+
POWER_DOMAIN_PIPE(i));
if (!error-pipe[i].power_domain_on)
continue;
@@ -12728,7 +12728,7 @@ intel_display_capture_error_state(struct drm_device
*dev)
enum transcoder cpu_transcoder = transcoders[i];
error-transcoder[i].power_domain_on =
- intel_display_power_enabled_sw(dev_priv,
+ intel_display_power_enabled_unlocked(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
if (!error-transcoder[i].power_domain_on)
continue;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 78d4124..1455ddb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -948,8 +948,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_remove(struct drm_i915_private *);
bool intel_display_power_enabled(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain);
+bool intel_display_power_enabled_unlocked(struct drm_i915_private
*dev_priv,
+ enum intel_display_power_domain
domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index ee27d74..96a2d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5801,8 +5801,8 @@ static bool hsw_power_well_enabled(struct
drm_i915_private *dev_priv,
(HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
}
-bool intel_display_power_enabled_sw(struct drm_i915_private *dev_priv,
- enum intel_display_power_domain domain)
+bool intel_display_power_enabled_unlocked(struct drm_i915_private
*dev_priv,
+ enum intel_display_power_domain
domain)
{
struct i915_power_domains *power_domains;
struct i915_power_well *power_well;
@@ -5813,16 +5813,19 @@ bool intel_display_power_enabled_sw(struct
drm_i915_private *dev_priv,
return false;
power_domains = dev_priv-power_domains;
+
is_enabled = true;
+
for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
if (power_well-always_on)
continue;
- if (!power_well-count) {
+ if (!power_well-hw_enabled) {
is_enabled = false;
[Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default
Let them eat mincemeat pie.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index d05a2af..081ab2f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
.preliminary_hw_support =
IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
.disable_power_well = 1,
.enable_ips = 1,
- .fastboot = 0,
+ .fastboot = 42,
.prefault_disable = 0,
.reset = true,
.invert_brightness = 0,
@@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, Enable IPS (default: true));
module_param_named(fastboot, i915.fastboot, bool, 0600);
MODULE_PARM_DESC(fastboot,
- Try to skip unnecessary mode sets at boot time (default: false));
+ Try to skip unnecessary mode sets at boot time (default: true));
module_param_named(prefault_disable, i915.prefault_disable, bool, 0600);
MODULE_PARM_DESC(prefault_disable,
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: preserve SSC if previously set v2
Some machines may have a broken VBT or no VBT at all, but we still want
to use SSC there. So check for it and keep it enabled if we see it
already on. Based on an earlier fix from Kristian.
v2: honor modparam if set too (Daniel)
read out at init time and store for panel_use_ssc() use (Jesse)
Reported-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8631fb3..f57b752 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1404,6 +1404,8 @@ struct drm_i915_private {
struct intel_opregion opregion;
struct intel_vbt_data vbt;
+ bool bios_ssc; /* BIOS had SSC enabled at boot? */
+
/* overlay */
struct intel_overlay *overlay;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b5cbb28..0e8c9bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5355,7 +5355,7 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
{
if (i915.panel_use_ssc = 0)
return i915.panel_use_ssc != 0;
- return dev_priv-vbt.lvds_use_ssc
+ return (dev_priv-vbt.lvds_use_ssc || dev_priv-bios_ssc)
!(dev_priv-quirks QUIRK_LVDS_SSC_DISABLE);
}
@@ -12478,6 +12478,7 @@ void intel_modeset_setup_hw_state(struct drm_device
*dev,
void intel_modeset_gem_init(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *c;
struct intel_framebuffer *fb;
@@ -12485,6 +12486,14 @@ void intel_modeset_gem_init(struct drm_device *dev)
intel_init_gt_powersave(dev);
mutex_unlock(dev-struct_mutex);
+ /*
+* There may be no VBT; and if the BIOS enabled SSC we can
+* just keep using it to avoid unnecessary flicker.
+*/
+ if ((HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
+ (I915_READ(PCH_DREF_CONTROL) DREF_SSC1_ENABLE))
+ dev_priv-bios_ssc = true;
+
intel_modeset_init_hw(dev);
intel_setup_overlay(dev);
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: use current mode if the size matches the preferred mode
From: Kristian Høgsberg hoegsb...@gmail.com
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_fbdev.c | 47 +++---
1 file changed, 18 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 088fe93..09819ae 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -379,42 +379,31 @@ static bool intel_fb_initial_config(struct drm_fb_helper
*fb_helper,
/* go for command line mode first */
modes[i] = drm_pick_cmdline_mode(fb_conn, width, height);
- /* try for preferred next */
+ /* try for preferred next or match current */
if (!modes[i]) {
- DRM_DEBUG_KMS(looking for preferred mode on connector
%s\n,
- connector-name);
- modes[i] = drm_has_preferred_mode(fb_conn, width,
- height);
- }
+ struct drm_display_mode *preferred;
- /* No preferred mode marked by the EDID? Are there any modes? */
- if (!modes[i] !list_empty(connector-modes)) {
- DRM_DEBUG_KMS(using first mode listed on connector
%s\n,
+ DRM_DEBUG_KMS(looking for preferred mode on connector
%s\n,
connector-name);
- modes[i] = list_first_entry(connector-modes,
- struct drm_display_mode,
- head);
- }
+ preferred = drm_has_preferred_mode(fb_conn, width,
+ height);
- /* last resort: use current mode */
- if (!modes[i]) {
- /*
-* IMPORTANT: We want to use the adjusted mode (i.e.
-* after the panel fitter upscaling) as the initial
-* config, not the input mode, which is what crtc-mode
-* usually contains. But since our current fastboot
-* code puts a mode derived from the post-pfit timings
-* into crtc-mode this works out correctly. We don't
-* use hwmode anywhere right now, so use it for this
-* since the fb helper layer wants a pointer to
-* something we own.
-*/
- DRM_DEBUG_KMS(looking for current mode on connector
%s\n,
- connector-name);
intel_mode_from_pipe_config(encoder-crtc-hwmode,
to_intel_crtc(encoder-crtc)-config);
- modes[i] = encoder-crtc-hwmode;
+ modes[i] = encoder-crtc-hwmode;
+
+ if (preferred
+ !drm_mode_same_size(preferred, modes[i])) {
+ DRM_DEBUG_KMS(using preferred mode %s
+ instead of current mode %s
+ on connector %d\n,
+ preferred-name,
+ modes[i]-name,
+ fb_conn-connector-base.id);
+ modes[i] = preferred;
+ }
}
+
crtcs[i] = new_crtc;
DRM_DEBUG_KMS(connector %s on pipe %d [CRTC:%d]: %dx%d%s\n,
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm: add drm_mode_same_size function
From: Kristian Høgsberg hoegsb...@gmail.com
Like mode_equal but w/o the clock checks. Useful for checking if modes
are close enough to re-use to avoid a boot time mode set for example.
Signed-off-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_modes.c | 8
include/drm/drm_modes.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index bedf189..92ae7f3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -905,6 +905,14 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct
drm_display_mode *mode1,
}
EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
+bool drm_mode_same_size(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+ return mode1-vdisplay == mode2-vdisplay
+ mode1-hdisplay == mode2-hdisplay;
+}
+EXPORT_SYMBOL(drm_mode_same_size);
+
/**
* drm_mode_validate_size - make sure modes adhere to size constraints
* @dev: DRM device
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..7272309 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -215,6 +215,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
const struct drm_display_mode *mode2);
bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
const struct drm_display_mode *mode2);
+bool drm_mode_same_size(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2);
/* for use by the crtc helper probe functions */
void drm_mode_validate_size(struct drm_device *dev,
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: preserve swizzle settings if necessary v3
Some machines (like MBAs) might use a tiled framebuffer but not enable
display swizzling at boot time. We want to preserve that configuration
if possible to prevent a boot time mode set. On IVB+ it shouldn't
affect performance anyway since the memory controller does internal
swizzling anyway.
For most other configs we'll be able to enable swizzling at boot time,
since the initial framebuffer won't be tiled, thus we won't see any
corruption when we enable it.
v2: preserve swizzling if BIOS had it set (Daniel)
v3: preserve swizzling only if we inherited a tiled framebuffer (Daniel)
check display swizzle setting in detect_bit_6_swizzle (Daniel)
use gen6 as cutoff point (Daniel)
Reported-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 3 +++
drivers/gpu/drm/i915/i915_gem_tiling.c | 38 +++---
drivers/gpu/drm/i915/intel_display.c | 3 +++
4 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f57b752..f49fdcb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1405,6 +1405,7 @@ struct drm_i915_private {
struct intel_vbt_data vbt;
bool bios_ssc; /* BIOS had SSC enabled at boot? */
+ bool preserve_bios_swizzle;
/* overlay */
struct intel_overlay *overlay;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bfc7af0..0b168fb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4580,6 +4580,9 @@ void i915_gem_init_swizzling(struct drm_device *dev)
dev_priv-mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
return;
+ if (INTEL_INFO(dev)-gen = 6 dev_priv-preserve_bios_swizzle)
+ return;
+
I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
DISP_TILE_SURFACE_SWIZZLING);
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index cb150e8..73005ad 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -91,26 +91,30 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
- if (IS_VALLEYVIEW(dev)) {
- swizzle_x = I915_BIT_6_SWIZZLE_NONE;
- swizzle_y = I915_BIT_6_SWIZZLE_NONE;
- } else if (INTEL_INFO(dev)-gen = 6) {
+ if (INTEL_INFO(dev)-gen = 6) {
uint32_t dimm_c0, dimm_c1;
- dimm_c0 = I915_READ(MAD_DIMM_C0);
- dimm_c1 = I915_READ(MAD_DIMM_C1);
- dimm_c0 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
- dimm_c1 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
- /* Enable swizzling when the channels are populated with
-* identically sized dimms. We don't need to check the 3rd
-* channel because no cpu with gpu attached ships in that
-* configuration. Also, swizzling only makes sense for 2
-* channels anyway. */
- if (dimm_c0 == dimm_c1) {
- swizzle_x = I915_BIT_6_SWIZZLE_9_10;
- swizzle_y = I915_BIT_6_SWIZZLE_9;
- } else {
+
+ /* Make sure to honor boot time display configuration */
+ if (!(I915_READ(DISP_ARB_CTL) DISP_TILE_SURFACE_SWIZZLING)) {
swizzle_x = I915_BIT_6_SWIZZLE_NONE;
swizzle_y = I915_BIT_6_SWIZZLE_NONE;
+ } else {
+ dimm_c0 = I915_READ(MAD_DIMM_C0);
+ dimm_c1 = I915_READ(MAD_DIMM_C1);
+ dimm_c0 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
+ dimm_c1 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
+ /* Enable swizzling when the channels are populated with
+* identically sized dimms. We don't need to check the
+* 3rd channel because no cpu with gpu attached ships
+* in that configuration. Also, swizzling only makes
+* sense for 2 channels anyway. */
+ if (dimm_c0 == dimm_c1) {
+ swizzle_x = I915_BIT_6_SWIZZLE_9_10;
+ swizzle_y = I915_BIT_6_SWIZZLE_9;
+ } else {
+ swizzle_x = I915_BIT_6_SWIZZLE_NONE;
+ swizzle_y = I915_BIT_6_SWIZZLE_NONE;
+ }
}
} else if (IS_GEN5(dev)) {
/* On Ironlake whatever DRAM config, GPU always do
diff --git
Re: [Intel-gfx] [PATCH] backlight: Don't read back backlight setting from kernel on DPMS off
Hi, On 06/05/2014 04:29 PM, Chris Wilson wrote: On Thu, Jun 05, 2014 at 05:01:23PM +0300, Jani Nikula wrote: On Thu, 05 Jun 2014, Hans de Goede hdego...@redhat.com wrote: We've several reports from users where the backlight comes up turned off on starting X, when using video.use_native_backlight=1 (true dmi quirks, will be the default for 3.16), in combination with having an external display plugged in: https://bugzilla.redhat.com/show_bug.cgi?id=1032978 https://bugzilla.redhat.com/show_bug.cgi?id=1103806 This seems to be caused by /sys/class/backlight/intel_backlight/brightness reading back 0 when re-initializing the outputs. Unlike /sys/class/backlight/acpi_video0/brightness which is used without the video.use_native_backlight=1 param, which keeps returning the value from before Here is an excerpt from Xorg.log when this happens: [28225]: (II) intel(0): resizing framebuffer to 3286x1080 [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 0 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): switch to mode 1920x1080@60.0 on pipe 0 using HDMI2, position (1366, 0), rotation normal [28225]: (II) intel(0): DPMS off mode 3, saved backlight level 0 ^^^ This is an extra debug line I added, mode == the mode parameter to xxx_output_dpms_backlight, saved backlight level is the value of backlight_active_level after the xxx_output_backlight_get call. Note how backlight_active_level becomes 0 here. [28225]: (II) intel(0): switch to mode 1366x768@59.8 on pipe 1 using LVDS1, position (0, 0), rotation normal [28225]: (II) intel(0): DPMS on mode 0, setting backlight to 0 And here we restore the backlight to backlight_active_level which now is 0. This commit fixes this by not reading back the backlight setting from the kernel on DPMS off. I'm not at all familiar with the code base you're changing, and I'm just speculating here, but this seems a little odd. My guess is that the sna_output_backlight_get and/or intel_output_backlight_get functions read the actual_brightness sysfs file, which reads back the value from hardware. This is the contract for backlight class device. The acpi video implementation returns the cached value if there's no BQC or BCQ method. Hmm, interesting, I just checked, and xxx_output_backlight_get in the 2.21.15 driver which is where this is seen indeed reads actual_brightness not just brightness. Where as current master uses backlight not actual_backlight, but some of the reporting users have tried with 2.99.x driver versions and they still had the problem. Still I'll prepare a scratch build for these users using just backlight to see if that helps. I think perhaps either the current brightness should be read before switching off the output. It is read before we switch off the CRTC (and thus the output). So where it is getting the zero from is a puzzle - it should be the current state of the hardware, ergo what the user set by some other path. Note that it is read after the framebuffer has been resized and a new mode has been set on pipe 0 using LVDS1, could this perhaps cause the 0 to be read when using actual_brightness ? Also I've just had a user who has been testing this patch come back to me it does help, but he still has a suspend/resume issue. It seems that some X app / gnome-component is doing the following: 1) DPMS off 2) Read backlight xrandr property - this will now return 0 3) Set backlight xrandr property value to the value just read, aka 0 4) DPMS on - restores backlight to 0 because of the property set I believe the best way to fix this will be to make xxx_output_get_property(backlight) return backlight_active_level when in DPMS off, rather then calling xxx_output_backlight_get. I'll write a patch doing this tomorrow and ask the user to test (I'm calling it a day for now). If you've a better idea please let me know before I write and submit this patch :) Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [I-G-T]Add rc6_residency_counter subtest
On Thu, Jun 5, 2014 at 7:19 PM, Ben Widawsky b...@bwidawsk.net wrote: On Thu, Jun 05, 2014 at 10:27:42AM +0800, Wendy Wang wrote: Move rc6_residency_check to subtest, add new rc6_residency_counter subtest for pm_rc6_residency IGT case. Looks good to me. You have some formatting issues: for loops don't use the right coding style useless comment to fopen bad sign-off in mail added unnecessary whitespace replace assert with open coded abort So I've merged it with all those warts (except I fixed the signed-off-by). Please keep these things in mind next patch, and feel free to submit patches to fix these issues as well. I guess you've missed my reply to Wendy's patch. Since you've gone ahead and merged it, can you please address these issues? 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] backlight: Don't read back backlight setting from kernel on DPMS off
On Thu, Jun 05, 2014 at 09:08:33PM +0200, Hans de Goede wrote: Note that it is read after the framebuffer has been resized and a new mode has been set on pipe 0 using LVDS1, could this perhaps cause the 0 to be read when using actual_brightness ? Indeed, that is likely the explanation, and shows the fallacy in the current approach. And also explains why acpi_backlight works with the current code, but that the kernel interfering with intel_backlight does not. Also I've just had a user who has been testing this patch come back to me it does help, but he still has a suspend/resume issue. It seems that some X app / gnome-component is doing the following: 1) DPMS off 2) Read backlight xrandr property - this will now return 0 3) Set backlight xrandr property value to the value just read, aka 0 4) DPMS on - restores backlight to 0 because of the property set I believe the best way to fix this will be to make xxx_output_get_property(backlight) return backlight_active_level when in DPMS off, rather then calling xxx_output_backlight_get. I had the same thought when reviewing the code following your email. I modified sna, but I think I want to restructure how backlight is saved around modesets. -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 01/15] drm/i915: Use named initializers for gmch wm params
On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Using names initializers when filling out the watermark structs saves you from having go look up the struct definition every single time. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Thank you, 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] drm/i915/vlv: drop punit freq staus read after setting idle
This may take awhile (~10ms), and we don't need to make noise about it. References: https://bugs.freedesktop.org/show_bug.cgi?id=75244 Tested-by: huax...@intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ee27d74..4eebfd8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3227,10 +3227,6 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv) vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, dev_priv-rps.min_freq_softlimit); - if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS)) -GENFREQSTATUS) == 0, 5)) - DRM_ERROR(timed out waiting for Punit\n); - vlv_force_gfx_clock(dev_priv, false); I915_WRITE(GEN6_PMINTRMSK, -- 1.8.3.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/15] drm/i915: Use named initializers for gmch wm params
Am 05.06.2014 22:43, schrieb Chris Wilson: On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjäläville.syrj...@linux.intel.com Using names initializers when filling out the watermark structs saves you from having go look up the struct definition every single time. Signed-off-by: Ville Syrjäläville.syrj...@linux.intel.com Thank you, Reviewed-by: Chris Wilsonch...@chris-wilson.co.uk Thanks for the patch and for all the work, unfortunately it does not quite work as presented. I applied the patch correctly to drm-intel-nightly, and it compiles fine. However, the following issues exist: *) If you boot with the kernel parameter vga=792 (i.e. the same console resolutions as initiated by KMS) the system just hangs with a black screen. Booting aborts, nothing happens. *) Watermark settings are *still* not correct. *SIGH*, *sigh* intel_reg_read 0x20d8 0x20D8 : 0x11F0104 This is a watermark level of 4. As I said multiple times, the watermark register needs to be *AT LEAST* eight (in numbers, 8) to have a stable display. It is stable between 8 and 32. To reproduce, use a panning display with xrandr: xrandr --output DVI1 --mode 1024x768 --panning 2048x1536 then scroll, and see the display flicker. Folks, I really appreciate all your effort, but I would be really happy if my comments on the wrong watermarks wouldn't be continuously ignored. I submitted patches, twice, thrice... all went into the trash. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix VLV CRC reading.
Adding missing Display mmio reg offset.
Credits-to: Laws, Philip philip.l...@intel.com
Cc: He, Shuang shuang...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 286f05c..05e2541 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2627,7 +2627,7 @@ enum punit_power_well {
#define PORT_DFT_I9XX 0x61150
#define DC_BALANCE_RESET (1 25)
-#define PORT_DFT2_G4X 0x61154
+#define PORT_DFT2_G4X (dev_priv-info.display_mmio_offset + 0x61154)
#define DC_BALANCE_RESET_VLV (1 31)
#define PIPE_SCRAMBLE_RESET_MASK (0x3 0)
#define PIPE_B_SCRAMBLE_RESET(1 1)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Bug reports on 830MG patches (thanks, but more trouble)
Update on the 830MG Updates: As Ville already said, resume from suspend-to-ram is broken. No surprise, old broken bios. However, there is a big difference between the kernel with the pipe-A quirk disabled, and the one with pipe-a and pipe-b quirks enabled: If resumed without the quirk, the display is dead, but you can at least re-initiate it with vbetool post, then restart the X server. So at least, the kernel is working. With the pipe A quirk enabled, something dies immediately when attempting to resume from suspend. The machine is completely unresponsive, also not reachable over the network. The kernel dies away. This is *probably* related to the dying kernel when booting with vga=792 (or vga=791 or vga=790, all cause the same problem, no working machine.) Thanks for the patch and for all the work, unfortunately it does not quite work as presented. I applied the patch correctly to drm-intel-nightly, and it compiles fine. However, the following issues exist: *) If you boot with the kernel parameter vga=792 (i.e. the same console resolutions as initiated by KMS) the system just hangs with a black screen. Booting aborts, nothing happens. *) Watermark settings are *still* not correct. *SIGH*, *sigh* intel_reg_read 0x20d8 0x20D8 : 0x11F0104 This is a watermark level of 4. As I said multiple times, the watermark register needs to be *AT LEAST* eight (in numbers, 8) to have a stable display. It is stable between 8 and 32. To reproduce, use a panning display with xrandr: xrandr --output DVI1 --mode 1024x768 --panning 2048x1536 then scroll, and see the display flicker. Folks, I really appreciate all your effort, but I would be really happy if my comments on the wrong watermarks wouldn't be continuously ignored. I submitted patches, twice, thrice... all went into the trash. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915: Eliminate rmw from .update_primary_plane()
On Thu, Jun 05, 2014 at 07:16:02PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move the entire DSPCNTR register setup into the .update_primary_plane()
functions. That's where it belongs anyway and it'll also help 830M which
has the extra problem that plane registers reads will return the value
latched at the last vblank, not the value that was last written.
Also move DSPPOS and DSPSIZE setup there.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
The code changes here look good to me. You may want to reword/clarify
in the commit message exactly what move entire register setup means
since I didn't really know what you meant by that phrase until I looked
at the code and realized you were talking about starting to build the
new value for DSPCNTR which had previously started in *_crtc_enable().
Looking at these *_update_primary_plane() functions makes me wonder
whether it might help future review if we were to add another patch for
these functions that reorders the bit setting to match the order they
appear in the docs. Maybe also drop in a code comment in for each of
the bits that are described in the PRM, but that we're purposely just
leaving to a default value of 0 (180 rotation, async update, etc.) so
that it's clear to the reader that we expect the implicit assignment of
0 rather than overlooking overlooking we should have been programming.
Anyway, the code changes here look good, so with or without my
suggestions this is
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 110
+++
1 file changed, 34 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f02464..74bbab9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2431,20 +2431,31 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
- struct drm_i915_gem_object *obj;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
int plane = intel_crtc-plane;
unsigned long linear_offset;
u32 dspcntr;
- u32 reg;
+ u32 reg = DSPCNTR(plane);
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb-obj;
+ dspcntr = DISPPLANE_GAMMA_ENABLE;
+
+ if (intel_crtc-primary_enabled)
+ dspcntr |= DISPLAY_PLANE_ENABLE;
+
+ if (INTEL_INFO(dev)-gen 4) {
+ if (intel_crtc-pipe == PIPE_B)
+ dspcntr |= DISPPLANE_SEL_PIPE_B;
+
+ /* pipesrc and dspsize control the size that is scaled from,
+ * which should always be the user's requested size.
+ */
+ I915_WRITE(DSPSIZE(plane),
+((intel_crtc-config.pipe_src_h - 1) 16) |
+(intel_crtc-config.pipe_src_w - 1));
+ I915_WRITE(DSPPOS(plane), 0);
+ }
- reg = DSPCNTR(plane);
- dspcntr = I915_READ(reg);
- /* Mask out pixel format bits in case we change it */
- dspcntr = ~DISPPLANE_PIXFORMAT_MASK;
switch (fb-pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2476,12 +2487,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
BUG();
}
- if (INTEL_INFO(dev)-gen = 4) {
- if (obj-tiling_mode != I915_TILING_NONE)
- dspcntr |= DISPPLANE_TILED;
- else
- dspcntr = ~DISPPLANE_TILED;
- }
+ if (INTEL_INFO(dev)-gen = 4
+ obj-tiling_mode != I915_TILING_NONE)
+ dspcntr |= DISPPLANE_TILED;
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
@@ -2521,20 +2529,21 @@ static void ironlake_update_primary_plane(struct
drm_crtc *crtc,
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_framebuffer *intel_fb;
- struct drm_i915_gem_object *obj;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
int plane = intel_crtc-plane;
unsigned long linear_offset;
u32 dspcntr;
- u32 reg;
+ u32 reg = DSPCNTR(plane);
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb-obj;
+ dspcntr = DISPPLANE_GAMMA_ENABLE;
+
+ if (intel_crtc-primary_enabled)
+ dspcntr |= DISPLAY_PLANE_ENABLE;
+
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ dspcntr |=
Re: [Intel-gfx] [PATCH 14/15] drm/i915: Call .update_primary_plane in intel_{enable, disable}_primary_hw_plane()
On Thu, Jun 05, 2014 at 07:16:03PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make the intel_{enable,disable}_primary_hw_plane() simply call
.update_primary_plane(), thus eliminating the rmw from these functions
which should help the poor old 830M.
Now we can also remove the .update_primary_plane() from the
.crtc_enable() hooks.
This is because intel_crtc_enable_planes() -
intel_enable_primary_hw_plane() takes care of it for us, right? Can you
clarify that in the message? That wasn't immediately obvious from the
context visible in the diff.
This also has the nice benefit of making primary planes a bit closer to
the way we handle sprite planes during modesets.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
On a somewhat related note, is there any reason not to call
.update_primary_plane() at the end of the various sprite update
functions in intel_sprite.c instead of calling
intel_update_primary_plane() and intel_flush_primary_plane()? I find
the name similarity between intel_update_primary_plane() and
.update_primary_plane() confusing and it looks like we might be able to
consolidate a bit there unless I'm overlooking something.
Matt
---
drivers/gpu/drm/i915/intel_display.c | 92
+++-
1 file changed, 27 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 74bbab9..098017a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2147,63 +2147,51 @@ void intel_flush_primary_plane(struct
drm_i915_private *dev_priv,
/**
* intel_enable_primary_hw_plane - enable the primary plane on a given pipe
- * @dev_priv: i915 private structure
- * @plane: plane to enable
- * @pipe: pipe being fed
+ * @plane: plane to be enabled
+ * @crtc: crtc for the plane
*
- * Enable @plane on @pipe, making sure that @pipe is running first.
+ * Enable @plane on @crtc, making sure that the pipe is running first.
*/
-static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_enable_primary_hw_plane(struct drm_plane *plane,
+ struct drm_crtc *crtc)
{
- struct intel_crtc *intel_crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
- int reg;
- u32 val;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
/* If the pipe isn't enabled, we can't pump pixels and may hang */
- assert_pipe_enabled(dev_priv, pipe);
+ assert_pipe_enabled(dev_priv, intel_crtc-pipe);
if (intel_crtc-primary_enabled)
return;
intel_crtc-primary_enabled = true;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- WARN_ON(val DISPLAY_PLANE_ENABLE);
-
- I915_WRITE(reg, val | DISPLAY_PLANE_ENABLE);
- intel_flush_primary_plane(dev_priv, plane);
+ dev_priv-display.update_primary_plane(crtc, plane-fb,
+crtc-x, crtc-y);
}
/**
* intel_disable_primary_hw_plane - disable the primary hardware plane
- * @dev_priv: i915 private structure
- * @plane: plane to disable
- * @pipe: pipe consuming the data
+ * @plane: plane to be disabled
+ * @crtc: crtc for the plane
*
- * Disable @plane; should be an independent operation.
+ * Disable @plane on @crtc, making sure that the pipe is running first.
*/
-static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
-enum plane plane, enum pipe pipe)
+static void intel_disable_primary_hw_plane(struct drm_plane *plane,
+struct drm_crtc *crtc)
{
- struct intel_crtc *intel_crtc =
- to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
- int reg;
- u32 val;
+ struct drm_i915_private *dev_priv = crtc-dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ assert_pipe_enabled(dev_priv, intel_crtc-pipe);
if (!intel_crtc-primary_enabled)
return;
intel_crtc-primary_enabled = false;
- reg = DSPCNTR(plane);
- val = I915_READ(reg);
- WARN_ON((val DISPLAY_PLANE_ENABLE) == 0);
-
- I915_WRITE(reg, val ~DISPLAY_PLANE_ENABLE);
- intel_flush_primary_plane(dev_priv, plane);
+ dev_priv-display.update_primary_plane(crtc, plane-fb,
+crtc-x, crtc-y);
}
static bool need_vtd_wa(struct drm_device *dev)
@@ -3955,11 +3943,10 @@ static void intel_crtc_enable_planes(struct drm_crtc
*crtc)
struct drm_i915_private *dev_priv = dev-dev_private;
struct
[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
Hi all, After merging the drm-intel-fixes tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/i915/intel_fbdev.c: In function 'intel_fb_initial_config': drivers/gpu/drm/i915/intel_fbdev.c:392:4: error: implicit declaration of function 'drm_get_connector_name' [-Werror=implicit-function-declaration] DRM_DEBUG_KMS(using first mode listed on connector %s\n, ^ This is just the error I reported yesterday against the drm and drm-intel trees, but migrated to the drm-intel-fixes tree. Your -fixes tree shoudl really only contain stuff that depend on Linus' trees ... but here it include all of yesterday's drm tree as well. I have used the drm-intel-fixes tree from next-20140605 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP
On 6/5/2014 9:34 PM, Jesse Barnes wrote: On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP detection works across platforms The current bits will match correctly for 0x1806. I don't have a problem with the patch per-say but would be nice to know what the troublesome device type really was, if indeed there was one. I'm just slightly worried that we might start to get false positives on some platforms if we make it too relaxed. Still waiting for results, but https://bugs.freedesktop.org/show_bug.cgi?id=78795 was what motivated this. Yeah and update from Jesse that forcefully returning true from the function make things work, I assumed this is the reason, without really checking that even the old values will result DEVIVE_TYPE_eDP DEVICE_TYPE_eDP_BITS = 0x1806 :) Nevertheless I still feel that a simplified bit mask is good to have. We need to check further on this issue Jesse. Let me know once you have results. It would be still better to spit out the device_type being read from VBT as a log to confirm that indeed it is coming as 0x1806 or can just ask to get the opregion dump from debugfs and we can check ourselves. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Update bits to check in device class from VBT to detect eDP
On 6/6/2014 9:33 AM, Kumar, Shobhit wrote: On 6/5/2014 9:34 PM, Jesse Barnes wrote: On Thu, 5 Jun 2014 16:09:29 +0300 Ville Syrjälä ville.syrj...@linux.intel.com wrote: On Thu, Jun 05, 2014 at 06:25:13PM +0530, Shobhit Kumar wrote: The DEVICE_TYPE_eDP has been changed to 0x1806 in case of BYT which can causes wrong detection failures for eDP. Reduce the number of bits of interest in DEVICE_TYPE_eDP_BITS to just check most relevant and conclusive ones and ensure they are set in device_class from VBT. This will ensure that eDP detection works across platforms The current bits will match correctly for 0x1806. I don't have a problem with the patch per-say but would be nice to know what the troublesome device type really was, if indeed there was one. I'm just slightly worried that we might start to get false positives on some platforms if we make it too relaxed. Still waiting for results, but https://bugs.freedesktop.org/show_bug.cgi?id=78795 was what motivated this. Yeah and update from Jesse that forcefully returning true from the function make things work, I assumed this is the reason, without really checking that even the old values will result DEVIVE_TYPE_eDP DEVICE_TYPE_eDP_BITS = 0x1806 :) Nevertheless I still feel that a simplified bit mask is good to have. We need to check further on this issue Jesse. Let me know once you have results. It would be still better to spit out the device_type being read from VBT as a log to confirm that indeed it is coming as 0x1806 or can just ask to get the opregion dump from debugfs and we can check ourselves. I see above are already been asked in BZ. Will track there for updates. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
