[Intel-gfx] [PATCH v4 4/4] thinkpad-acpi: fix handle locate for video and query of _BCL
The tpacpi_acpi_handle_locate function makes use of acpi_get_devices to
locate handle for ACPI video by HID, the problem is, ACPI video node
doesn't really have HID defined(i.e. no _HID control method is defined
for video device), so.. that function would fail. This can be solved by
enhancing the callback function for acpi_get_devices, where we can use
acpi_device_hid function to check if the ACPI node corresponds to a
video controller.
In addition to that, the _BCL control method only exists under a video
output device node, not a video controller device node. So to evaluate
_BCL, we need the handle of a video output device node, which is child
of the located video controller node from tpacpi_acpi_handle_locate.
The two fix are necessary for some Thinkpad models to emit notification
on backlight hotkey press as a result of evaluation of _BCL.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Acked-by: Henrique de Moraes Holschuh
---
drivers/platform/x86/thinkpad_acpi.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 03ca6c1..170f278 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -700,6 +700,14 @@ static void __init drv_acpi_handle_init(const char *name,
static acpi_status __init tpacpi_acpi_handle_locate_callback(acpi_handle
handle,
u32 level, void *context, void **return_value)
{
+ struct acpi_device *dev;
+ if (!strcmp(context, "video")) {
+ if (acpi_bus_get_device(handle, &dev))
+ return AE_OK;
+ if (strcmp(ACPI_VIDEO_HID, acpi_device_hid(dev)))
+ return AE_OK;
+ }
+
*(acpi_handle *)return_value = handle;
return AE_CTRL_TERMINATE;
@@ -712,10 +720,10 @@ static void __init tpacpi_acpi_handle_locate(const char
*name,
acpi_status status;
acpi_handle device_found;
- BUG_ON(!name || !hid || !handle);
+ BUG_ON(!name || !handle);
vdbg_printk(TPACPI_DBG_INIT,
"trying to locate ACPI handle for %s, using HID %s\n",
- name, hid);
+ name, hid ? hid : "NULL");
memset(&device_found, 0, sizeof(device_found));
status = acpi_get_devices(hid, tpacpi_acpi_handle_locate_callback,
@@ -6090,19 +6098,28 @@ static int __init tpacpi_query_bcl_levels(acpi_handle
handle)
{
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
+ struct acpi_device *device, *child;
int rc;
- if (ACPI_SUCCESS(acpi_evaluate_object(handle, "_BCL", NULL, &buffer))) {
+ if (acpi_bus_get_device(handle, &device))
+ return 0;
+
+ rc = 0;
+ list_for_each_entry(child, &device->children, node) {
+ acpi_status status = acpi_evaluate_object(child->handle, "_BCL",
+ NULL, &buffer);
+ if (ACPI_FAILURE(status))
+ continue;
+
obj = (union acpi_object *)buffer.pointer;
if (!obj || (obj->type != ACPI_TYPE_PACKAGE)) {
pr_err("Unknown _BCL data, please report this to %s\n",
- TPACPI_MAIL);
+ TPACPI_MAIL);
rc = 0;
} else {
rc = obj->package.count;
}
- } else {
- return 0;
+ break;
}
kfree(buffer.pointer);
@@ -6118,7 +6135,7 @@ static unsigned int __init
tpacpi_check_std_acpi_brightness_support(void)
acpi_handle video_device;
int bcl_levels = 0;
- tpacpi_acpi_handle_locate("video", ACPI_VIDEO_HID, &video_device);
+ tpacpi_acpi_handle_locate("video", NULL, &video_device);
if (video_device)
bcl_levels = tpacpi_query_bcl_levels(video_device);
--
1.8.4.12.g2ea3df6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] ACPI / video: seperate backlight control and event interface
The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functionalities are actually independent and one may be useful
while the other one may be broken, so it is desirable to seperate the
two functionalities such that it is clear and easy to disable one
functionality without affecting the other one.
APIs to selectively remove backlight control interface and/or event
delivery functionality can be easily added once needed.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/acpi/video.c | 434 +--
1 file changed, 245 insertions(+), 189 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index aebcf63..3bd1eaa 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
static int register_count;
+static struct mutex video_list_lock;
+static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
@@ -157,6 +159,7 @@ struct acpi_video_bus {
struct acpi_video_bus_flags flags;
struct list_head video_device_list;
struct mutex device_list_lock; /* protects video_device_list */
+ struct list_head entry;
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
@@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
if (acpi_has_method(device->dev->handle, "_DDC"))
device->cap._DDC = 1;
-
- if (acpi_video_backlight_support()) {
- struct backlight_properties props;
- struct pci_dev *pdev;
- acpi_handle acpi_parent;
- struct device *parent = NULL;
- int result;
- static int count;
- char *name;
-
- result = acpi_video_init_brightness(device);
- if (result)
- return;
- name = kasprintf(GFP_KERNEL, "acpi_video%d", count);
- if (!name)
- return;
- count++;
-
- acpi_get_parent(device->dev->handle, &acpi_parent);
-
- pdev = acpi_get_pci_dev(acpi_parent);
- if (pdev) {
- parent = &pdev->dev;
- pci_dev_put(pdev);
- }
-
- memset(&props, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_FIRMWARE;
- props.max_brightness = device->brightness->count - 3;
- device->backlight = backlight_device_register(name,
- parent,
- device,
-
&acpi_backlight_ops,
- &props);
- kfree(name);
- if (IS_ERR(device->backlight))
- return;
-
- /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
- device->backlight->props.brightness =
- acpi_video_get_brightness(device->backlight);
-
- device->cooling_dev = thermal_cooling_device_register("LCD",
- device->dev, &video_cooling_ops);
- if (IS_ERR(device->cooling_dev)) {
- /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
- device->cooling_dev = NULL;
- return;
- }
-
- dev_info(&device->dev->dev, "registered as cooling_device%d\n",
-device->cooling_dev->id);
- result = sysfs_create_link(&device->dev->dev.kobj,
- &device->cooling_dev->device.kobj,
- "thermal_cooling");
- if (result)
- printk(KERN_ERR PREFIX "Create sysfs link\n"
[Intel-gfx] [PATCH v4 3/4] ACPI / video: Do not register backlight if win8 and native interface exists
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems".
So for Win8 systems, if there is native backlight control interface
registered by GPU driver, ACPI video will not register its own. For
users who prefer to keep ACPI video's backlight interface, the existing
kernel cmdline option acpi_backlight=video can be used.
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/acpi/internal.h | 5 ++---
drivers/acpi/video.c| 10 +-
drivers/acpi/video_detect.c | 14 --
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..453ae8d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -169,9 +169,8 @@ int acpi_create_platform_device(struct acpi_device *adev,
Video
-- */
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
-bool acpi_video_backlight_quirks(void);
-#else
-static inline bool acpi_video_backlight_quirks(void) { return false; }
+bool acpi_osi_is_win8(void);
+bool acpi_video_verify_backlight_support(void);
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 3bd1eaa..343db59 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device->brightness)
@@ -1386,13 +1386,13 @@ acpi_video_bus_get_devices(struct acpi_video_bus *video,
static int acpi_video_bus_start_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 1 : 0);
+ acpi_osi_is_win8() ? 1 : 0);
}
static int acpi_video_bus_stop_devices(struct acpi_video_bus *video)
{
return acpi_video_bus_DOS(video, 0,
- acpi_video_backlight_quirks() ? 0 : 1);
+ acpi_osi_is_win8() ? 0 : 1);
}
static void acpi_video_bus_notify(struct acpi_device *device, u32 event)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void
*context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 940edbf..23d7d26 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -233,11 +234,11 @@ static void acpi_video_caps_check(void)
acpi_video_get_capabilities(NULL);
}
-bool acpi_video_backlight_quirks(void)
+bool acpi_osi_is_win8(void)
{
return acpi_gbl_osi_data >= ACPI_OSI_WIN_8;
}
-EXPORT_SYMBOL(acpi_video_backlight_quirks);
+EXPORT_SYMBOL(acpi_osi_is_win8);
/* Promote the vendor interface instead of the generic video module.
* This function allow DMI blacklists to be implemented by externals
@@ -283,6 +284,15 @@ int acpi_video_backlight_support(void)
}
EXPORT_SYMBOL(acpi_video_backlight_support);
+bool acpi_video_verify_backlight_support(void)
+{
+ if (!(acpi_video_support & ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO) &&
+ acpi_osi_is_win8() && backlight_device_registered(BACKLIGHT_RAW))
+ return false;
+ return acpi_video_backlight_support();
+}
+EXPORT_SYMBOL(acpi_video_verify_backlight_support);
+
/*
* Use acpi_backlight=vendor/video to force that backlight switching
* is processed by vendor specific acpi drivers or video.ko driver.
--
1.8.4.12.g2ea3df6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/4] Fix Win8 backlight issue
v4: Remove decleration and stub for acpi_video_unregister_backlight in video.h of patch 2/4 since that function doesn't exist anymore in v3. v3: 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; 2 Remove unnecessary function acpi_video_unregister_backlight introduced in patch 2/4 as pointed out by Jani Nikula. v2: v1 has the subject of "Rework ACPI video driver" and is posted here: http://lkml.org/lkml/2013/9/9/74 Since the objective is really to fix Win8 backlight issues, I changed the subject in this version, sorry about that. This patchset has four patches, the first introduced a new API named backlight_device_registered in backlight layer that can be used for backlight interface provider module to check if a specific type backlight interface has been registered, see changelog for patch 1/4 for details. Then patch 2/4 does the cleanup to sepeate the backlight control and event delivery functionality in the ACPI video module and patch 3/4 solves some Win8 backlight control problems by avoiding register ACPI video's backlight interface if: 1 Kernel cmdline option acpi_backlight=video is not given; 2 This is a Win8 system; 3 Native backlight control interface exists. Patch 4/4 fixes some problems in thinkpad-acpi module. Technically, patch 2/4 is not required to fix the issue here. So if you think it is not necessary, I can remove it from the series. Aaron Lu (4): backlight: introduce backlight_device_registered ACPI / video: seperate backlight control and event interface ACPI / video: Do not register backlight if win8 and native interface exists thinkpad-acpi: fix handle locate for video and query of _BCL drivers/acpi/internal.h | 5 +- drivers/acpi/video.c | 442 --- drivers/acpi/video_detect.c | 14 +- drivers/platform/x86/thinkpad_acpi.c | 31 ++- drivers/video/backlight/backlight.c | 31 +++ include/linux/backlight.h| 4 + 6 files changed, 322 insertions(+), 205 deletions(-) -- 1.8.4.12.g2ea3df6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] backlight: introduce backlight_device_registered
Introduce a new API for modules to query if a specific type of backlight
device has been registered. This is useful for some backlight device
provider module(e.g. ACPI video) to know if a native control
interface(e.g. the interface created by i915) is available and then do
things accordingly(e.g. avoid register its own on Win8 systems).
Signed-off-by: Aaron Lu
Tested-by: Igor Gnatenko
Tested-by: Yves-Alexis Perez
Tested-by: Mika Westerberg
---
drivers/video/backlight/backlight.c | 31 +++
include/linux/backlight.h | 4
2 files changed, 35 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..bf2d71d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -21,6 +21,9 @@
#include
#endif
+static struct list_head bd_list_head;
+static struct mutex bd_list_mutex;
+
static const char *const backlight_types[] = {
[BACKLIGHT_RAW] = "raw",
[BACKLIGHT_PLATFORM] = "platform",
@@ -349,10 +352,32 @@ struct backlight_device *backlight_device_register(const
char *name,
mutex_unlock(&pmac_backlight_mutex);
#endif
+ mutex_lock(&bd_list_mutex);
+ list_add(&new_bd->entry, &bd_list_head);
+ mutex_unlock(&bd_list_mutex);
+
return new_bd;
}
EXPORT_SYMBOL(backlight_device_register);
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
+ struct backlight_device *bd;
+
+ mutex_lock(&bd_list_mutex);
+ list_for_each_entry(bd, &bd_list_head, entry) {
+ if (bd->props.type == type) {
+ found = true;
+ break;
+ }
+ }
+ mutex_unlock(&bd_list_mutex);
+
+ return found;
+}
+EXPORT_SYMBOL(backlight_device_registered);
+
/**
* backlight_device_unregister - unregisters a backlight device object.
* @bd: the backlight device object to be unregistered and freed.
@@ -364,6 +389,10 @@ void backlight_device_unregister(struct backlight_device
*bd)
if (!bd)
return;
+ mutex_lock(&bd_list_mutex);
+ list_del(&bd->entry);
+ mutex_unlock(&bd_list_mutex);
+
#ifdef CONFIG_PMAC_BACKLIGHT
mutex_lock(&pmac_backlight_mutex);
if (pmac_backlight == bd)
@@ -499,6 +528,8 @@ static int __init backlight_class_init(void)
backlight_class->dev_groups = bl_device_groups;
backlight_class->pm = &backlight_class_dev_pm_ops;
+ INIT_LIST_HEAD(&bd_list_head);
+ mutex_init(&bd_list_mutex);
return 0;
}
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..5f9cd96 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -100,6 +100,9 @@ struct backlight_device {
/* The framebuffer notifier block */
struct notifier_block fb_notif;
+ /* list entry of all registered backlight devices */
+ struct list_head entry;
+
struct device dev;
};
@@ -123,6 +126,7 @@ extern void devm_backlight_device_unregister(struct device
*dev,
struct backlight_device *bd);
extern void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason);
+extern bool backlight_device_registered(enum backlight_type type);
#define to_backlight_device(obj) container_of(obj, struct backlight_device,
dev)
--
1.8.4.12.g2ea3df6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Use the real cpu max frequency for ring scaling
On Mon, Oct 07, 2013 at 05:15:48PM -0300, Rodrigo Vivi wrote: > From: Ben Widawsky > > The policy's max frequency is not equal to the CPU's max frequency. The > ring frequency is derived from the CPU frequency, and not the policy > frequency. > > One example of how this may differ through sysfs. If the sysfs max > frequency is modified, that will be used for the max ring frequency > calculation. > (/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I > know, no current governor uses anything but max as the default, but in > theory, they could. Similarly distributions might set policy as part of > their init process. > > It's ideal to use the real frequency because when we're currently scaled > up on the GPU. In this case we likely want to race to idle, and using a > less than max ring frequency is non-optimal for this situation. > > AFAIK, this patch should have no impact on a majority of people. > > This behavior hasn't been changed since it was first introduced: > commit 23b2f8bb92feb83127679c53633def32d3108e70 > Author: Jesse Barnes > Date: Tue Jun 28 13:04:16 2011 -0700 > > drm/i915: load a ring frequency scaling table v3 > > CC: Jesse Barnes > Signed-off-by: Ben Widawsky > Reviewed-by: Chris Wilson > Signed-off-by: Rodrigo Vivi Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 deadlock on laptop undock
On Mon, Oct 07, 2013 at 03:41:05PM -0700, Roland Dreier wrote: > Hi, > > I have a Lenovo T410s (Ironlake/Arrandale graphics) that I use docked > and connected to an external DP monitor (laptop is closed so the only > active display is the DP monitor). With 3.12-rc4 I reproducably hit a > deadlock when I undock the laptop -- it seems to be a deadlock on > dev->mode_confix.mutext between intel_crtc_wait_for_pending_flips > (mutex held because of drm_modeset_lock_all in intel_lid_notify) and > drm_mode_getconnector. See below for the kernel logging (there's no > logging for more than 2 minutes before the hung task stuff) -- it > seems that intel_crtc_wait_for_pending_flips is getting stuck, and > then everything else piles up behind it: > > [ 241.009121] INFO: task kworker/0:1:70 blocked for more than 120 > seconds. > [ 241.009131] Tainted: GW3.12.0-999-generic > #201310070425 > [ 241.009133] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 241.009137] kworker/0:1 D 070 2 > 0x > [ 241.009152] Workqueue: kacpi_notify acpi_os_execute_deferred > [ 241.009156] 88022b2c9ae8 0046 88022b2c9ab8 > 8e17de71 > [ 241.009162] 88022b2c9fd8 88022b2c9fd8 88022b2c9fd8 > 000144c0 > [ 241.009167] 81c144a0 88022b29 0286 > 88022ae7 > [ 241.009173] Call Trace: > [ 241.009186] [] schedule+0x29/0x70 > [ 241.009247] [] > intel_crtc_wait_for_pending_flips+0x8d/0x120 [i915] > [ 241.009257] [] ? add_wait_queue+0x60/0x60 > [ 241.009289] [] ironlake_crtc_disable+0x7f/0x2a0 > [i915] > [ 241.009318] [] intel_crtc_update_dpms+0x76/0xb0 > [i915] > [ 241.009347] [] intel_sanitize_crtc+0xd5/0x370 [i915] > [ 241.009377] [] > intel_modeset_setup_hw_state+0x17d/0x380 [i915] > [ 241.009407] [] intel_lid_notify+0xc1/0x100 [i915] > [ 241.009412] [] notifier_call_chain+0x4d/0x70 > [ 241.009419] [] > __blocking_notifier_call_chain+0x58/0x80 > [ 241.009424] [] > blocking_notifier_call_chain+0x16/0x20 > [ 241.009431] [] acpi_lid_send_state+0x86/0xaf > [ 241.009436] [] acpi_button_notify+0x3b/0xa2 > [ 241.009442] [] acpi_device_notify+0x19/0x1b > [ 241.009448] [] acpi_ev_notify_dispatch+0x41/0x5c > [ 241.009453] [] acpi_os_execute_deferred+0x25/0x32 > [ 241.009458] [] process_one_work+0x17f/0x4d0 > [ 241.009463] [] worker_thread+0x11b/0x3d0 > [ 241.009468] [] ? manage_workers.isra.20+0x1b0/0x1b0 > [ 241.009473] [] kthread+0xc0/0xd0 > [ 241.009479] [] ? flush_kthread_worker+0xb0/0xb0 > [ 241.009484] [] ret_from_fork+0x7c/0xb0 > [ 241.009489] [] ? flush_kthread_worker+0xb0/0xb0 > [ 241.009525] INFO: task Xorg:1436 blocked for more than 120 seconds. > [ 241.009528] Tainted: GW3.12.0-999-generic > #201310070425 > [ 241.009531] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 241.009533] XorgD 0 1436 1410 > 0x0044 > [ 241.009538] 88022ca1bc48 0082 88022ca1bc18 > 811a31a1 > [ 241.009543] 88022ca1bfd8 88022ca1bfd8 88022ca1bfd8 > 000144c0 > [ 241.009549] 880230198000 8800b06546e0 88022ca1bc28 > 8800363b8330 > [ 241.009554] Call Trace: > [ 241.009562] [] ? kmem_cache_free+0x121/0x180 > [ 241.009568] [] schedule+0x29/0x70 > [ 241.009574] [] schedule_preempt_disabled+0xe/0x10 > [ 241.009580] [] __mutex_lock_slowpath+0x114/0x1b0 > [ 241.009585] [] mutex_lock+0x23/0x40 > [ 241.009613] [] drm_mode_getconnector+0xb2/0x430 > [drm] > [ 241.009633] [] drm_ioctl+0x4fa/0x620 [drm] > [ 241.009656] [] ? drm_mode_getcrtc+0xe0/0xe0 [drm] > [ 241.009663] [] do_vfs_ioctl+0x7a/0x2e0 > [ 241.009668] [] ? vfs_read+0x111/0x180 > [ 241.009673] [] SyS_ioctl+0x91/0xb0 > [ 241.009678] [] ? SyS_read+0x70/0xa0 > [ 241.009683] [] system_call_fastpath+0x1a/0x1f > > Detailed lspci info for my laptop: > > 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM > Controller [8086:0044] (rev 02) > 00:02.0 VGA compatible controller [0300]: Intel Corporation Core > Processor Integrated Graphics Controller [8086:0046] (rev 02) > 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 > Series Chipset HECI Controller [8086:3b64] (rev 06) > 00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit > Network Connection [8086:10ea] (rev 06) > 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series > Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06) > 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series > Chipset High Definition Audio [8086:3b57] (rev
Re: [Intel-gfx] [PATCH 0/4] drm-intel-collector - review request
On Mon, Oct 07, 2013 at 09:25:44PM -0700, Ben Widawsky wrote: > On Mon, Oct 07, 2013 at 05:15:44PM -0300, Rodrigo Vivi wrote: > > > > This is another drm-intel-collector push for review: > > http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector > > > > Here goes the list in order for better reviewers assignment: > > > > Patch drm/i915: check that the i965g/gm 4G limit is really obeyed - > > Reviewer: Damien Lespiau > > Patch drm/i915: Asynchronously perform the set-base for a simple > > modeset - Reviewer: I would prefer Ville review this since he had concerns > > about sorround code. switch to fbcon is much faster with this patch so I > > let it here and will try to review by myself if I heard nothing else until > > next update. > > Patch drm/i915: implement another plane WM workaround for HSW - > > Reviewer: If no body else volunteer I'll do this review until next update. > > Patch drm/i915: Use the real cpu max frequency for ring scaling - > > Reviewed by Chris. > > > > Overall Process: > > > > drm-intel-collector - review request > > 1. Daniel pushs drm-intel-testing (every 2 weeks) > > 2. I rebase drm-intel-collector onto drm-intel-testing > > 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you > > should be assigned on a particular patch please don't get mad just tell you > > wont review or volunteer someone else. > > 4. I resubmit remaining patches for review without picking any new > > (drm-intel-collector - review request) > > > > drm-intel-collector - updated > > 5. One week later I collect all simple (1-2) patches that wasn't yet > > reviewed and not queued by Daniel from one testing update until another. > > 6. Request automated QA's PRTS automated i-g-t tests comparing > > drm-intel-testing x drm-intel-collector > > 7. If tests are ok I send the update notification or the patches as a > > series to intel-gfx mailing list for better tracking and to be reviewed. > > (drm-intel-collector - updated) > > 8. Let me know volunteers for review new patches and also let me know if > > I've picked any patch that I shouldn't. > > > > There are some reasons that some patches can be left behind: > > 1. Your patch didn't applied cleanly and I couldn't easily solve the > > conflicts. > > 2. Kernel didn't compiled with your patch. > > 3. I simply missed it. If you believe this is the case please warn me. > > > > Please help me to get these patches reviewed and queued by Daniel. > > > > Also, please let me know if you have further ideas how to improve this > > process. > > > > Thanks in advance, > > Rodrigo. > > > > > > Ben Widawsky (1): > > drm/i915: Use the real cpu max frequency for ring scaling > > > > Chris Wilson (1): > > drm/i915: Asynchronously perform the set-base for a simple modeset > > > > Daniel Vetter (1): > > drm/i915: check that the i965g/gm 4G limit is really obeyed > > > > Paulo Zanoni (1): > > drm/i915: implement another plane WM workaround for HSW > > > > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > > drivers/gpu/drm/i915/intel_display.c | 20 > > drivers/gpu/drm/i915/intel_pm.c | 17 +++-- > > 3 files changed, 30 insertions(+), 10 deletions(-) > > > > Hi Rodrigo. Thanks for doing this. Could I make a small request - can > you please CC all the relevant people when you send these mails? Good idea. It's probably simplest to add the Reviewer: also as Cc: in the patch before sending out the new pile. -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 0/4] drm-intel-collector - review request
On Mon, Oct 07, 2013 at 05:15:44PM -0300, Rodrigo Vivi wrote: > > This is another drm-intel-collector push for review: > http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector > > Here goes the list in order for better reviewers assignment: > > Patch drm/i915: check that the i965g/gm 4G limit is really obeyed - > Reviewer: Damien Lespiau > Patch drm/i915: Asynchronously perform the set-base for a simple modeset > - Reviewer: I would prefer Ville review this since he had concerns about > sorround code. switch to fbcon is much faster with this patch so I let it > here and will try to review by myself if I heard nothing else until next > update. > Patch drm/i915: implement another plane WM workaround for HSW - Reviewer: > If no body else volunteer I'll do this review until next update. > Patch drm/i915: Use the real cpu max frequency for ring scaling - > Reviewed by Chris. > > Overall Process: > > drm-intel-collector - review request > 1. Daniel pushs drm-intel-testing (every 2 weeks) > 2. I rebase drm-intel-collector onto drm-intel-testing > 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you > should be assigned on a particular patch please don't get mad just tell you > wont review or volunteer someone else. > 4. I resubmit remaining patches for review without picking any new > (drm-intel-collector - review request) > > drm-intel-collector - updated > 5. One week later I collect all simple (1-2) patches that wasn't yet > reviewed and not queued by Daniel from one testing update until another. > 6. Request automated QA's PRTS automated i-g-t tests comparing > drm-intel-testing x drm-intel-collector > 7. If tests are ok I send the update notification or the patches as a series > to intel-gfx mailing list for better tracking and to be reviewed. > (drm-intel-collector - updated) > 8. Let me know volunteers for review new patches and also let me know if > I've picked any patch that I shouldn't. > > There are some reasons that some patches can be left behind: > 1. Your patch didn't applied cleanly and I couldn't easily solve the > conflicts. > 2. Kernel didn't compiled with your patch. > 3. I simply missed it. If you believe this is the case please warn me. > > Please help me to get these patches reviewed and queued by Daniel. > > Also, please let me know if you have further ideas how to improve this > process. > > Thanks in advance, > Rodrigo. > > > Ben Widawsky (1): > drm/i915: Use the real cpu max frequency for ring scaling > > Chris Wilson (1): > drm/i915: Asynchronously perform the set-base for a simple modeset > > Daniel Vetter (1): > drm/i915: check that the i965g/gm 4G limit is really obeyed > > Paulo Zanoni (1): > drm/i915: implement another plane WM workaround for HSW > > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > drivers/gpu/drm/i915/intel_display.c | 20 > drivers/gpu/drm/i915/intel_pm.c | 17 +++-- > 3 files changed, 30 insertions(+), 10 deletions(-) > Hi Rodrigo. Thanks for doing this. Could I make a small request - can you please CC all the relevant people when you send these mails? -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i810 only partially usable
On 2013-10-04 19:32 (GMT-0400) Felix Miata composed: Valid modes are now being recognized, but PreferredMode is still being ignored, and EDID preferred is inescapable via /etc/X11/xorg.conf*. Linux gx110 3.11.2-1.g420e19b-default #1 SMP Sat Sep 28 16:00:10 UTC 2013 (420e19b) i686 i686 i386 GNU/Linux glamor-0.5.1-39.1.i586 intel-gpu-tools-1.3-20.10.i586 libdrm2-2.4.46-121.1.i586 libdrm_intel1-2.4.46-121.1.i586 (no Plymouth) vaapi-intel-driver-1.2.0-22.8.i586 xf86-video-intel-2.99.903-88.2.i586 xorg-x11-server-7.6_1.14.3-251.12.i586 log: http://fm.no-ip.com/Tmp/Linux/Xorg/xorg.0.log.gx110-os131b1-PreferredModeIGNORED Still broken: Linux gx110 3.11.3-3.gac1d7be-default #1 SMP Fri Oct 4 12:14:40 UTC 2013 (ac1d7be) i686 i686 i386 GNU/Linux glamor-0.5.1-39.2.i586 intel-gpu-tools-1.3-20.10.i586 libdrm_intel1-2.4.46-121.1.i586 libdrm2-2.4.46-121.1.i586 vaapi-intel-driver-1.2.0-22.8.i586 xf86-video-intel-2.99.903-88.2.i586 xorg-x11-server-7.6_1.14.3-251.15.i586 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken in 3.10.10 (was: Questions on display pipes on 835GM)
On 06.10.2013 01:37, Daniel Vetter wrote: On Sun, Oct 6, 2013 at 1:09 AM, Thomas Richter wrote: Now if you follow the callchains around the dvo->dpms callbacks the DVO port and DPLL are always enabled at that point in time, so I think we should be able to fix this all by moving the modeset code around to that place. True, but probably with the high-speed bit in the wrong state. We always program the dpll with the high-speed select bit set when using it for a DVO port, so this will also automatically be taken care of. Actually, I was testing with the 3.10.10 kernel here. Unfortunately, I need to tell you that 3.11.4 and 3.12.0-rc.4 does *not work at all*. All I get on these kernel releases is a blank screen, though with a working mouse cursor. Apparently, nothing is rendered on the screen at all. Otherwise, it does the same as 3.10.10, namely lock up if I connect an external monitor during bootstrap. For 3.12.0-rc.4, if I connect the monitor *after* bootup on the gdm login, I first see nothing on the external screen, and the mouse pointer on the internal TFT. Then, after logging in blindly, the cursor appears at the external monitor, the system beeps and then crashes and hangs. Thus, sorry, but: broken in 3.11 and up... Sorry for the bad news, please try try again. Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.11-rc7: i915: stuck on render ring
On Thu, Oct 3, 2013 at 22:42:06 +0200, Pavel Machek wrote: > On Wed 2013-09-04 11:08:14, Chris Wilson wrote: > > On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: > > > Hi! > > > > > > I was happily using X... and then screen froze. Mouse still > > > moves. Switching to text console still worked, good. It is first time > > > in a while, normally this machine works well. > > > > > > i915_error_state is attached. > > > > > > Any ideas? > > > > It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29). > > Aha, so I need to update X or rather debian should update the X > server. Thanks for the info. > Pavel I don't know what version you're running, but stable has 2.19, and unstable has 2.21.15. Both are > 2.14.902. Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Use the real cpu max frequency for ring scaling
From: Ben Widawsky
The policy's max frequency is not equal to the CPU's max frequency. The
ring frequency is derived from the CPU frequency, and not the policy
frequency.
One example of how this may differ through sysfs. If the sysfs max
frequency is modified, that will be used for the max ring frequency
calculation.
(/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I
know, no current governor uses anything but max as the default, but in
theory, they could. Similarly distributions might set policy as part of
their init process.
It's ideal to use the real frequency because when we're currently scaled
up on the GPU. In this case we likely want to race to idle, and using a
less than max ring frequency is non-optimal for this situation.
AFAIK, this patch should have no impact on a majority of people.
This behavior hasn't been changed since it was first introduced:
commit 23b2f8bb92feb83127679c53633def32d3108e70
Author: Jesse Barnes
Date: Tue Jun 28 13:04:16 2011 -0700
drm/i915: load a ring frequency scaling table v3
CC: Jesse Barnes
Signed-off-by: Ben Widawsky
Reviewed-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0b4de57..4ec4846 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3740,16 +3740,21 @@ void gen6_update_ring_freq(struct drm_device *dev)
unsigned int gpu_freq;
unsigned int max_ia_freq, min_ring_freq;
int scaling_factor = 180;
+ struct cpufreq_policy *policy;
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
- max_ia_freq = cpufreq_quick_get_max(0);
- /*
-* Default to measured freq if none found, PCU will ensure we don't go
-* over
-*/
- if (!max_ia_freq)
+ policy = cpufreq_cpu_get(0);
+ if (policy) {
+ max_ia_freq = policy->cpuinfo.max_freq;
+ cpufreq_cpu_put(policy);
+ } else {
+ /*
+* Default to measured freq if none found, PCU will ensure we
+* don't go over
+*/
max_ia_freq = tsc_khz;
+ }
/* Convert from kHz to MHz */
max_ia_freq /= 1000;
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: implement another plane WM workaround for HSW
From: Paulo Zanoni In some Haswell machines we're seeing a full system hang while calling haswell_crtc_enable. Ville bisected the problem to the following commit: commit 90a8864320b2a9f91e5b5d561924a4bb70b90dcc Author: Paulo Zanoni Date: Fri May 3 17:23:45 2013 -0300 drm/i915: set FORCE_ARB_IDLE_PLANES workaround After some BSpec-digging I discovered that we don't implement one of the workarounds mentioned in the description of bit 31 of PRI_CTL, SPR_CTL and CUR_CTL. This patch implements the workaround, which makes the problem go away on my machine. Also notice that the workaround implementation is almost a revert of the commit mentioned above, but it still allows LP watermarks to be used. Thanks to Ville for the help debugging the issue and for doing the bisect. Cc: sta...@vger.kernel.org Credits-to: Ville Syrjälä Signed-off-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_display.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bc47f1e..8069bff 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3565,6 +3565,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) struct intel_crtc *intel_crtc = to_intel_crtc(crtc); struct intel_encoder *encoder; int pipe = intel_crtc->pipe; + uint32_t wm_dbg_val; WARN_ON(!crtc->enabled); @@ -3597,6 +3598,11 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) intel_ddi_set_pipe_settings(crtc); intel_ddi_enable_transcoder_func(crtc); + /* Workaround described in PRI_CTL, CUR_CTL and SPR_CTL bit 31. */ + wm_dbg_val = I915_READ(WM_DBG); + I915_WRITE(WM_DBG, wm_dbg_val | WM_DBG_DISALLOW_MULTIPLE_LP | + WM_DBG_DISALLOW_MAXFIFO | WM_DBG_DISALLOW_SPRITE); + intel_update_watermarks(crtc); intel_enable_pipe(dev_priv, pipe, intel_crtc->config.has_pch_encoder, false); @@ -3623,6 +3629,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc) * happening. */ intel_wait_for_vblank(dev, intel_crtc->pipe); + + /* Second part of the WM_DBG workaround. */ + I915_WRITE(WM_DBG, wm_dbg_val); } static void ironlake_pfit_disable(struct intel_crtc *crtc) -- 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/4] drm/i915: Asynchronously perform the set-base for a simple modeset
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is left on the scanout.
2. We need to flush any pending rendering before performing the mmio
so that the frame is complete before it is shown.
3. We currently wait for the vblank after the mmio to be sure that the
old fb is no longer being shown before releasing it.
(1) can only be eliminated by userspace preparing the fb->obj in advance
to already be in the display domain. This can be done through use of the
create2 ioctl, or by reusing an existing fb->obj.
However, (2) and (3) are already solved by the existing page flip
mechanism, and it is surprisingly trivial to wire them up for use in the
set-base fast path. Though it can be argued that this represents a
subtle ABI break in that the set_config ioctl now returns before the old
framebuffer is unpinned. The danger is that userspace will start to
modify it before it is no longer being shown, however we should be able
to prevent that through proper domain tracking.
By combining all of the above, we can achieve an instaneous set_config:
[ 6.601] (II) intel(0): switch to mode 2560x1440@60.0 on pipe 0 using DP2,
position (0, 0), rotation normal
[ 6.601] (II) intel(0): Setting screen physical size to 677 x 381
v2 (by Vivi): page_flip_flag was added to intel_crtc_page_flip
in a previous commit. using 0.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b9cede7..bc47f1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9569,10 +9569,13 @@ static int intel_crtc_set_config(struct drm_mode_set
*set)
ret = intel_set_mode(set->crtc, set->mode,
set->x, set->y, set->fb);
} else if (config->fb_changed) {
- intel_crtc_wait_for_pending_flips(set->crtc);
-
- ret = intel_pipe_set_base(set->crtc,
- set->x, set->y, set->fb);
+ if (to_intel_framebuffer(set->fb)->obj->ring == NULL ||
+ save_set.x != set->x || save_set.y != set->y ||
+ intel_crtc_page_flip(set->crtc, set->fb, NULL, 0)) {
+ intel_crtc_wait_for_pending_flips(set->crtc);
+ ret = intel_pipe_set_base(set->crtc,
+ set->x, set->y, set->fb);
+ }
}
if (ret) {
--
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/4] drm/i915: check that the i965g/gm 4G limit is really obeyed
From: Daniel Vetter In truly crazy circumstances shmem might give us the wrong type of page. So be a bit paranoid and double check this. Reviewer: Damien Lespiau Cc: Rob Clark References: http://lkml.org/lkml/2011/7/11/238 Signed-off-by: Daniel Vetter Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 19ecfa8..692ebf7 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1903,6 +1903,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj) sg->length += PAGE_SIZE; } last_pfn = page_to_pfn(page); + + /* Check that the i965g/gm workaround works. */ + WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL)); } #ifdef CONFIG_SWIOTLB if (!swiotlb_nr_tbl()) -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm-intel-collector - review request
This is another drm-intel-collector push for review: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the list in order for better reviewers assignment: Patch drm/i915: check that the i965g/gm 4G limit is really obeyed - Reviewer: Damien Lespiau Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewer: I would prefer Ville review this since he had concerns about sorround code. switch to fbcon is much faster with this patch so I let it here and will try to review by myself if I heard nothing else until next update. Patch drm/i915: implement another plane WM workaround for HSW - Reviewer: If no body else volunteer I'll do this review until next update. Patch drm/i915: Use the real cpu max frequency for ring scaling - Reviewed by Chris. Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Ben Widawsky (1): drm/i915: Use the real cpu max frequency for ring scaling Chris Wilson (1): drm/i915: Asynchronously perform the set-base for a simple modeset Daniel Vetter (1): drm/i915: check that the i965g/gm 4G limit is really obeyed Paulo Zanoni (1): drm/i915: implement another plane WM workaround for HSW drivers/gpu/drm/i915/i915_gem.c | 3 +++ drivers/gpu/drm/i915/intel_display.c | 20 drivers/gpu/drm/i915/intel_pm.c | 17 +++-- 3 files changed, 30 insertions(+), 10 deletions(-) -- 1.8.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable LVDS clock gating on CPT v2
On Mon, Oct 07, 2013 at 02:39:22PM -0300, Rodrigo Vivi wrote: > Reviewed-by: Rodrigo Vivi > > On Mon, Oct 7, 2013 at 1:27 PM, Jesse Barnes wrote: > > Doesn't completely fix Uli's machine, but apparently it helps a bit, so: > > > > Tested-by: Ulrich Drepper > > > > On Wed, 2 Oct 2013 10:34:19 -0700 > > Jesse Barnes wrote: > > > >> Needed to prevent display corruption in high res panels. > >> > >> v2: use correct unit names (Rodrigo) > >> > >> Signed-off-by: Jesse Barnes Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable LVDS clock gating on CPT v2
Reviewed-by: Rodrigo Vivi On Mon, Oct 7, 2013 at 1:27 PM, Jesse Barnes wrote: > Doesn't completely fix Uli's machine, but apparently it helps a bit, so: > > Tested-by: Ulrich Drepper > > On Wed, 2 Oct 2013 10:34:19 -0700 > Jesse Barnes wrote: > >> Needed to prevent display corruption in high res panels. >> >> v2: use correct unit names (Rodrigo) >> >> Signed-off-by: Jesse Barnes >> --- >> drivers/gpu/drm/i915/i915_reg.h |2 ++ >> drivers/gpu/drm/i915/intel_pm.c |4 +++- >> 2 files changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index 96fd2ce..b6312d9 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -4338,7 +4338,9 @@ >> #define FDI_RX_CHICKEN(pipe) _PIPE(pipe, _FDI_RXA_CHICKEN, _FDI_RXB_CHICKEN) >> >> #define SOUTH_DSPCLK_GATE_D 0xc2020 >> +#define PCH_DPLUNIT_CLOCK_GATE_DISABLE (1<<30) >> #define PCH_DPLSUNIT_CLOCK_GATE_DISABLE (1<<29) >> +#define PCH_CPUNIT_CLOCK_GATE_DISABLE (1<<14) >> #define PCH_LP_PARTITION_LEVEL_DISABLE (1<<12) >> >> /* CPU: FDI_TX */ >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 698257c..9443f8e 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -4791,7 +4791,9 @@ static void cpt_init_clock_gating(struct drm_device >> *dev) >>* gating for the panel power sequencer or it will fail to >>* start up when no ports are active. >>*/ >> - I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE); >> + I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE | >> +PCH_DPLUNIT_CLOCK_GATE_DISABLE | >> +PCH_CPUNIT_CLOCK_GATE_DISABLE); >> I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) | >> DPLS_EDP_PPS_FIX_DIS); >> /* The below fixes the weird display corruption, a few pixels shifted > > > -- > Jesse Barnes, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable LVDS clock gating on CPT v2
Doesn't completely fix Uli's machine, but apparently it helps a bit, so: Tested-by: Ulrich Drepper On Wed, 2 Oct 2013 10:34:19 -0700 Jesse Barnes wrote: > Needed to prevent display corruption in high res panels. > > v2: use correct unit names (Rodrigo) > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/i915_reg.h |2 ++ > drivers/gpu/drm/i915/intel_pm.c |4 +++- > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 96fd2ce..b6312d9 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -4338,7 +4338,9 @@ > #define FDI_RX_CHICKEN(pipe) _PIPE(pipe, _FDI_RXA_CHICKEN, _FDI_RXB_CHICKEN) > > #define SOUTH_DSPCLK_GATE_D 0xc2020 > +#define PCH_DPLUNIT_CLOCK_GATE_DISABLE (1<<30) > #define PCH_DPLSUNIT_CLOCK_GATE_DISABLE (1<<29) > +#define PCH_CPUNIT_CLOCK_GATE_DISABLE (1<<14) > #define PCH_LP_PARTITION_LEVEL_DISABLE (1<<12) > > /* CPU: FDI_TX */ > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 698257c..9443f8e 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4791,7 +4791,9 @@ static void cpt_init_clock_gating(struct drm_device > *dev) >* gating for the panel power sequencer or it will fail to >* start up when no ports are active. >*/ > - I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE); > + I915_WRITE(SOUTH_DSPCLK_GATE_D, PCH_DPLSUNIT_CLOCK_GATE_DISABLE | > +PCH_DPLUNIT_CLOCK_GATE_DISABLE | > +PCH_CPUNIT_CLOCK_GATE_DISABLE); > I915_WRITE(SOUTH_CHICKEN2, I915_READ(SOUTH_CHICKEN2) | > DPLS_EDP_PPS_FIX_DIS); > /* The below fixes the weird display corruption, a few pixels shifted -- 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] [BUG] Crash during startup
On 05.10.2013 00:19, Knut Petersen wrote: Hi everybody! A full Oct-1 build runs fine here, a full Oct-3 builds crashes reliably, see attached log and diff of version list used. hardware: AOpen i915GMm-hfs Oct-7: Current git sources work fine again. cu, Knut ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/dp: add helper for checking DP_ENHANCED_FRAME_CAP in DPCD
On Fri, Oct 4, 2013 at 8:08 AM, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Patches 1 and 2 are:
Reviewed-by: Alex Deucher
> ---
> include/drm/drm_dp_helper.h |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ae8dbfb..fdf58fa 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -390,4 +390,11 @@ drm_dp_max_lane_count(u8 dpcd[DP_RECEIVER_CAP_SIZE])
> return dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
> }
>
> +static inline bool
> +drm_dp_enhanced_frame_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + return dpcd[DP_DPCD_REV] >= 0x11 &&
> + (dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP);
> +}
> +
> #endif /* _DRM_DP_HELPER_H_ */
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915] invert_brightness on 8086:0116:103c:1854
On Mon, Oct 07, 2013 at 05:43:11PM +0400, Kirill Tkhai wrote: > > > 07.10.2013, 16:14, "Kirill Tkhai" : > > 07.10.2013, 11:42, "Jani Nikula" : > > > >> On Sat, 05 Oct 2013, Kirill Tkhai wrote: > >>> Hi, > >>> > >>> I've just installed kernel 3.10 on HP 250 G1 and the found option > >>> invert_brightness is required. > >> Hi Kirill, thanks for the report. I suspect invert_brightness is not the > >> right fix, since we've only ever seen that on gen4 Acer based > >> laptops. Please file a bug on DRM/Intel at [1]. > > > > One more detail before I post a BUG. > > > > My screen is black in *console* right after kernel is started unless > > the option is passed. > > > > DRI is about XServer as I understand right. Do we mean the same? > > *if* I understand right :) DRI is X server, but DR_M_ is the kernel part. Yeah, the linux gfx stack is a rather complex beast ... -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] [i915] invert_brightness on 8086:0116:103c:1854
07.10.2013, 16:14, "Kirill Tkhai" : > 07.10.2013, 11:42, "Jani Nikula" : > >> On Sat, 05 Oct 2013, Kirill Tkhai wrote: >>> Hi, >>> >>> I've just installed kernel 3.10 on HP 250 G1 and the found option >>> invert_brightness is required. >> Hi Kirill, thanks for the report. I suspect invert_brightness is not the >> right fix, since we've only ever seen that on gen4 Acer based >> laptops. Please file a bug on DRM/Intel at [1]. > > One more detail before I post a BUG. > > My screen is black in *console* right after kernel is started unless > the option is passed. > > DRI is about XServer as I understand right. Do we mean the same? *if* I understand right :) >> BR, >> Jani. >> >> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI >>> IDs are 8086:0116:103c:1854 (vendor:device:subvendor:subdevice) >>> >>> lspci is: >>> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core >>> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA >>> controller]) >>> Subsystem: Hewlett-Packard Company Device 1854 >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>> ParErr- Stepping- SERR- FastB2B- DisINTx+ >>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- >>> SERR- >> Latency: 0 >>> Interrupt: pin A routed to IRQ 42 >>> Region 0: Memory at c200 (64-bit, non-prefetchable) [size=4M] >>> Region 2: Memory at b000 (64-bit, prefetchable) [size=256M] >>> Region 4: I/O ports at 4000 [size=64] >>> Expansion ROM at [disabled] >>> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- >>> Address: fee0f00c Data: 41b1 >>> Capabilities: [d0] Power Management version 2 >>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA >>> PME(D0-,D1-,D2-,D3hot-,D3cold-) >>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>> Capabilities: [a4] PCI Advanced Features >>> AFCap: TP+ FLR+ >>> AFCtrl: FLR- >>> AFStatus: TP- >>> Kernel driver in use: i915 >>> >>> Regards, >>> Kirill >>> ___ >>> 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] [i915] invert_brightness on 8086:0116:103c:1854
07.10.2013, 11:42, "Jani Nikula" : > On Sat, 05 Oct 2013, Kirill Tkhai wrote: > >> Hi, >> >> I've just installed kernel 3.10 on HP 250 G1 and the found option >> invert_brightness is required. > > Hi Kirill, thanks for the report. I suspect invert_brightness is not the > right fix, since we've only ever seen that on gen4 Acer based > laptops. Please file a bug on DRM/Intel at [1]. One more detail before I post a BUG. My screen is black in *console* right after kernel is started unless the option is passed. DRI is about XServer as I understand right. Do we mean the same? > > BR, > Jani. > > [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI > >> IDs are 8086:0116:103c:1854 (vendor:device:subvendor:subdevice) >> >> lspci is: >> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core >> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA >> controller]) >> Subsystem: Hewlett-Packard Company Device 1854 >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- >> Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- >> SERR- > Latency: 0 >> Interrupt: pin A routed to IRQ 42 >> Region 0: Memory at c200 (64-bit, non-prefetchable) [size=4M] >> Region 2: Memory at b000 (64-bit, prefetchable) [size=256M] >> Region 4: I/O ports at 4000 [size=64] >> Expansion ROM at [disabled] >> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- >> Address: fee0f00c Data: 41b1 >> Capabilities: [d0] Power Management version 2 >> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA >> PME(D0-,D1-,D2-,D3hot-,D3cold-) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [a4] PCI Advanced Features >> AFCap: TP+ FLR+ >> AFCtrl: FLR- >> AFStatus: TP- >> Kernel driver in use: i915 >> >> Regards, >> Kirill >> ___ >> 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 v3 2/4] ACPI / video: seperate backlight control and event interface
On Tuesday, September 24, 2013 05:54:53 PM Aaron Lu wrote: > On 09/24/2013 05:47 PM, Aaron Lu wrote: [...] > > diff --git a/include/acpi/video.h b/include/acpi/video.h > > index 61109f2..0c665b5 100644 > > --- a/include/acpi/video.h > > +++ b/include/acpi/video.h > > @@ -19,11 +19,13 @@ struct acpi_device; > > #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE) > > extern int acpi_video_register(void); > > extern void acpi_video_unregister(void); > > +extern int acpi_video_unregister_backlight(void); > > Oops, forgot to remove the declration and the stub below. But it doesn't > affect the test of the patches, so I'll leave it for a while till next > revision. Any chance to send the next revision? Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix VGA handling using stop_machine() or mmio
On Mon, Oct 07, 2013 at 12:25:03PM +0300, Ville Syrjälä wrote: > On Mon, Oct 07, 2013 at 10:15:16AM +0100, Chris Wilson wrote: > > On Wed, Oct 02, 2013 at 04:42:55PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > We have several problems with out VGA handling: > > > - We try to use the GMCH control VGA disable bit even though it may > > > be locked > > > - If we manage to disable VGA throuh GMCH control, we're no longer > > > able to correctly disable the VGA plane > > > - Taking part in the VGA arbitration is too expensive for X [1] > > > > > > So let's treat the GMCH control VGA disable bit as read-only and leave > > > it for the BIOS to set, as it was intended. To disable VGA we will use > > > the VGA misc register, and to disable VGA IO we will disable IO space > > > completely via the PCI command register. > > > > > > But we still need VGA register access during resume (and possibly during > > > lid event on insane BIOSen) to disable the VGA plane. Also we need to > > > re-disable VGA memory decode via the VGA misc register on resume. > > > > > > Luckily up to gen4, VGA registers can be accessed through MMIO. > > > Unfortunately from gen5 onwards only the legacy VGA IO port range > > > works. So on gen5+ we still need IO space to be enabled during those > > > few special moments when we need to access VGA registers. > > > > > > We still want to opt out of VGA arbitration on gen5+, so we have keep > > > IO space disabled most of the time. And when we do need to poke at VGA > > > registers, we enable IO space briefly while no one is looking. To > > > guarantee that no one is looking we will use stop_machine(). > > > > > > [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html > > > > > > v2: Use SNB_GMCH_TRL on SNB+ > > > Use port IO instead of MMIO on CTG/ELK > > > Add WaEnableVGAAccessThroughIOPort comment > > > Fix the max number of devices on the bus limit > > > v3: Allocate the temp space dynamically > > > Print some errors if we fail to execute the vga "op" due to alloc > > > failure > > > > Passes the dGPU test, the SNB laptop, but is doa for CTG. > > Crap. And v2 still works all right there? No, appears I mislead you. The last one to successfully work was the composite v1 patch set. Sorry. -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 v3] drm/i915: Fix VGA handling using stop_machine() or mmio
On Mon, Oct 07, 2013 at 10:15:16AM +0100, Chris Wilson wrote: > On Wed, Oct 02, 2013 at 04:42:55PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We have several problems with out VGA handling: > > - We try to use the GMCH control VGA disable bit even though it may > > be locked > > - If we manage to disable VGA throuh GMCH control, we're no longer > > able to correctly disable the VGA plane > > - Taking part in the VGA arbitration is too expensive for X [1] > > > > So let's treat the GMCH control VGA disable bit as read-only and leave > > it for the BIOS to set, as it was intended. To disable VGA we will use > > the VGA misc register, and to disable VGA IO we will disable IO space > > completely via the PCI command register. > > > > But we still need VGA register access during resume (and possibly during > > lid event on insane BIOSen) to disable the VGA plane. Also we need to > > re-disable VGA memory decode via the VGA misc register on resume. > > > > Luckily up to gen4, VGA registers can be accessed through MMIO. > > Unfortunately from gen5 onwards only the legacy VGA IO port range > > works. So on gen5+ we still need IO space to be enabled during those > > few special moments when we need to access VGA registers. > > > > We still want to opt out of VGA arbitration on gen5+, so we have keep > > IO space disabled most of the time. And when we do need to poke at VGA > > registers, we enable IO space briefly while no one is looking. To > > guarantee that no one is looking we will use stop_machine(). > > > > [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html > > > > v2: Use SNB_GMCH_TRL on SNB+ > > Use port IO instead of MMIO on CTG/ELK > > Add WaEnableVGAAccessThroughIOPort comment > > Fix the max number of devices on the bus limit > > v3: Allocate the temp space dynamically > > Print some errors if we fail to execute the vga "op" due to alloc > > failure > > Passes the dGPU test, the SNB laptop, but is doa for CTG. Crap. And v2 still works all right there? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix VGA handling using stop_machine() or mmio
On Wed, Oct 02, 2013 at 04:42:55PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We have several problems with out VGA handling: > - We try to use the GMCH control VGA disable bit even though it may > be locked > - If we manage to disable VGA throuh GMCH control, we're no longer > able to correctly disable the VGA plane > - Taking part in the VGA arbitration is too expensive for X [1] > > So let's treat the GMCH control VGA disable bit as read-only and leave > it for the BIOS to set, as it was intended. To disable VGA we will use > the VGA misc register, and to disable VGA IO we will disable IO space > completely via the PCI command register. > > But we still need VGA register access during resume (and possibly during > lid event on insane BIOSen) to disable the VGA plane. Also we need to > re-disable VGA memory decode via the VGA misc register on resume. > > Luckily up to gen4, VGA registers can be accessed through MMIO. > Unfortunately from gen5 onwards only the legacy VGA IO port range > works. So on gen5+ we still need IO space to be enabled during those > few special moments when we need to access VGA registers. > > We still want to opt out of VGA arbitration on gen5+, so we have keep > IO space disabled most of the time. And when we do need to poke at VGA > registers, we enable IO space briefly while no one is looking. To > guarantee that no one is looking we will use stop_machine(). > > [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html > > v2: Use SNB_GMCH_TRL on SNB+ > Use port IO instead of MMIO on CTG/ELK > Add WaEnableVGAAccessThroughIOPort comment > Fix the max number of devices on the bus limit > v3: Allocate the temp space dynamically > Print some errors if we fail to execute the vga "op" due to alloc failure Passes the dGPU test, the SNB laptop, but is doa for CTG. -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 00/12] drm/i915: Some cleanups and fixes to the sprite code v2
On Fri, Oct 04, 2013 at 11:28:16AM +0100, Chris Wilson wrote: > On Tue, Oct 01, 2013 at 06:02:09PM +0300, ville.syrj...@linux.intel.com wrote: > > Chris asked for some renames and assertions during v1. While adding those I > > noticed that what I did in the original patch 02 didn't match quite so well > > with the assertions. So I modified patch 02 a bit, and that caused quite a > > bit > > of bit of rebase issues for most of the other patches, so I figured it's > > better > > to repost the whole thing. > > > > Changes from v1: > > - Move the primary disable/enable calls inside intel_crtc->active checks > > in intel_update_plane/intel_disable_plane. That also ate up patch 03 from > > the original series. > > - Add primary_disabled WARNs > > - Rename primary plane funcs > > - Flush primary plane changes from sprite code > > - Add a POSTING_READ() to intel_flush_primary_plane. This shouldn't really > > be necessary now that I think about it some more. So we might want to drop > > that change... > > Looks good, very good, to me. > > Even with throwing up over FBC, > > Reviewed-by: Chris Wilson > > except for > > 08/12: drm/i915: Enable/disable IPS when primary is >enabled/disabled > > For which the code looks ok, but only merits an > Acked-by: Chris Wilson All merged, thanks for patches&review. Now my problem here is that I'm really uneasy with our complete lack of testcoverage for all these corner-cases. I know that we can't really get full functional testing going for sprites/planes/cursors before we have the CRC stuff all merged, but at least exercising all this code would be great. So can we please move "polish/create testcases for cursor/sprite/plane corner-cases and push the to igt" to the top-spot for all things planes? At least before we start to wreak utter havoc with atomic pageflips/modeset I want to have some assurance that we don't break all the low-level functions we've painstakingly beaten into shape in the past few months ... Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: Clarify automated test constant and add constant for FAUX test pattern
On Fri, 04 Oct 2013, Todd Previte wrote: > - DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN > to clarify > - Added DP_TEST_LINK_FAUX_PATTERN to support automated testing of Fast AUX > > Signed-off-by: Todd Previte Reviewed-by: Jani Nikula > --- > include/drm/drm_dp_helper.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index ae8dbfb..34c8202 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -266,9 +266,10 @@ > > #define DP_TEST_REQUEST 0x218 > # define DP_TEST_LINK_TRAINING (1 << 0) > -# define DP_TEST_LINK_PATTERN(1 << 1) > +# define DP_TEST_LINK_VIDEO_PATTERN (1 << 1) > # define DP_TEST_LINK_EDID_READ (1 << 2) > # define DP_TEST_LINK_PHY_TEST_PATTERN (1 << 3) /* DPCD >= 1.1 */ > +# define DP_TEST_LINK_FAUX_PATTERN (1 << 4) /* DPCD >= 1.2 */ > > #define DP_TEST_LINK_RATE0x219 > # define DP_LINK_RATE_162(0x6) > -- > 1.8.1.2 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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] [i915] invert_brightness on 8086:0116:103c:1854
On Sat, 05 Oct 2013, Kirill Tkhai wrote: > Hi, > > I've just installed kernel 3.10 on HP 250 G1 and the found option > invert_brightness is required. Hi Kirill, thanks for the report. I suspect invert_brightness is not the right fix, since we've only ever seen that on gen4 Acer based laptops. Please file a bug on DRM/Intel at [1]. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI > > IDs are 8086:0116:103c:1854 (vendor:device:subvendor:subdevice) > > lspci is: > 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core > Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA > controller]) > Subsystem: Hewlett-Packard Company Device 1854 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 42 > Region 0: Memory at c200 (64-bit, non-prefetchable) [size=4M] > Region 2: Memory at b000 (64-bit, prefetchable) [size=256M] > Region 4: I/O ports at 4000 [size=64] > Expansion ROM at [disabled] > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- > Address: fee0f00c Data: 41b1 > Capabilities: [d0] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [a4] PCI Advanced Features > AFCap: TP+ FLR+ > AFCtrl: FLR- > AFStatus: TP- > Kernel driver in use: i915 > > Regards, > Kirill > ___ > 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 v2 1/1] drm/i915: Fix VGA handling using stop_machine() or mmio
On Mon, Oct 7, 2013 at 2:23 AM, Dave Airlie wrote: > I'm think I'm going to make an executive decision to merge Ville's > latest patch to avoid the regression, the other option being just to > revert everything back to the status quo by reverting all the patches > from the past few months, if people are happier with that then maybe > we should just do that for now and try and design our way out of it > properly by reengineering userspace and plan to avoid the regression > next time. Ack on merging Ville's hack. Longer-term we could beautify the pig a bit by moving it into vgaarb.c and avoiding the stop_machine if no one else has a vga lock. And I think in next we could try to limit the vga redisable hack in the lid notifier a bit on more modern platforms to avoid the dreaded stop_machine at runtime and relegate it to just resume/driver load. Really long term (once broken X servers have died) we can try to rip this hack out again. Or maybe intel hw engineers get their act together beforehand ;-) So can you directly pick it up since I've just flushed out my -fixes queue? 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
