[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=83262 --- Comment #2 from Kevin --- Created attachment 105936 --> https://bugs.freedesktop.org/attachment.cgi?id=105936&action=edit dmesg output shortly after boot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/2d4a117f/attachment.html>
[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=83262 --- Comment #3 from Kevin --- Created attachment 105937 --> https://bugs.freedesktop.org/attachment.cgi?id=105937&action=edit Xorg log shortly after boot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/36b11d2f/attachment.html>
[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=83262 --- Comment #4 from Kevin --- Created attachment 105938 --> https://bugs.freedesktop.org/attachment.cgi?id=105938&action=edit dmesg output just after resuming from suspend -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/d133116c/attachment.html>
[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=83262 --- Comment #5 from Kevin --- Created attachment 105939 --> https://bugs.freedesktop.org/attachment.cgi?id=105939&action=edit Xorg log shortly after resuming from suspend -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/c2db8b70/attachment.html>
[Bug 83262] Radeon DPM re-clocking fails after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=83262 --- Comment #6 from Kevin --- Alex, thank you for your help! I think I have attached all that you asked for. I tried to include the files both after a fresh boot and after resuming from suspend. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/e4334f92/attachment.html>
role of crtcs in modesetting interfaces and possible abstraction away from userspace
Hi, So I've been attempting to hide the 30" Dell MST monitors in the kernel, and ran into a number of problems, but the major one is how to steal a crtc and get away with it. The standard scenario I have is CRTC 0: eDP monitor connected hotplug 30" monitor, userspace decides to configure things as CRTC 1: DP-4 - 30" monitor CRTC 2: eDP-1 But since we lack atomic it does this in two steps, so when I get the first modeset to set the 30" monitor up I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still, then I have to fail the second modeset, and things end up with me crying. So this led me to wonder why we expose CRTCs at all, and KMS does it because randr did it, but I've no idea why randr did it (Keith??). >From my POV I don't think the modesetting interface needs to take crtcs, just connectors and modes, so I'm wondering going forward for atomic should we even accept crtcs in the interface, just a list of rectangles, connectors per rectangle, etc. Now I'm at the point of trying to work out if I can make DP MST monitors a possibility before we get atomic, Myself and Ben discussed this here and he suggested we should make the userspace crtc ids pretty much meaningless and not have them tied to actual hw crtcs, so we can reroute things underneath userspace without changing it. Any input is welcome! Dave.
[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On 09.09.2014 02:36, Alex Deucher wrote:
>
> Updated version with comments integrated.
[...]
> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
> domain, u64 max_offset,
> unsigned lpfn = 0;
>
> /* force to pin into visible video ram */
> - if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
> - lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
> - else
> + if (bo->placements[i].flags & TTM_PL_FLAG_VRAM) {
> + if (!(bo->flags & RADEON_GEM_NO_CPU_ACCESS))
> + lpfn = bo->rdev->mc.visible_vram_size >>
> PAGE_SHIFT;
> + } else {
> lpfn = bo->rdev->mc.gtt_size >> PAGE_SHIFT; /* ??? */
> + }
The else block can be removed as well, but that can be done in another
patch.
Either way, v2 is
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On 09.09.2014 09:47, Michel D?nzer wrote:
> On 09.09.2014 02:36, Alex Deucher wrote:
>>
>> Updated version with comments integrated.
>
> [...]
>
>> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo
>> *bo, u32 domain, u64 max_offset,
>> unsigned lpfn = 0;
>>
>> /* force to pin into visible video ram */
>> -if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
>> -lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>> -else
>> +if (bo->placements[i].flags & TTM_PL_FLAG_VRAM) {
>> +if (!(bo->flags & RADEON_GEM_NO_CPU_ACCESS))
>> +lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>> +} else {
>> lpfn = bo->rdev->mc.gtt_size >> PAGE_SHIFT; /* ??? */
>> +}
>
> The else block can be removed as well, but that can be done in another
> patch.
Actually, I just noticed a problem, the following if statement:
> if (max_offset)
> lpfn = min (lpfn, (unsigned)(max_offset >> PAGE_SHIFT));
This will ignore max_offset if lpfn is 0. So either go with v1 of this hunk,
or rebase on top of the patch below.
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Tue, 9 Sep 2014 10:09:23 +0900
Subject: [PATCH] drm/radeon: Clean up assignment of TTM placement lpfn member
for pinning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_object.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 908ea541..8ec8150 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -307,18 +307,14 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
domain, u64 max_offset,
}
radeon_ttm_placement_from_domain(bo, domain);
for (i = 0; i < bo->placement.num_placement; i++) {
- unsigned lpfn = 0;
-
/* force to pin into visible video ram */
if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
- lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
+ bo->placements[i].lpfn =
+ min(bo->rdev->mc.visible_vram_size, max_offset)
+ >> PAGE_SHIFT;
else
- lpfn = bo->rdev->mc.gtt_size >> PAGE_SHIFT; /* ??? */
-
- if (max_offset)
- lpfn = min (lpfn, (unsigned)(max_offset >> PAGE_SHIFT));
+ bo->placements[i].lpfn = max_offset >> PAGE_SHIFT;
- bo->placements[i].lpfn = lpfn;
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
}
--
2.1.0
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 --- Comment #22 from t3st3r at mail.ru --- Attempted to test on 3.17-rc4. Result: crashed in about 3 minutes of run (see below). Are some stability fixes missing 3.17-rc4 mainline? At first glance I do not see radeon-related commits in drm-fixes which haven't made it to -rc4. Am I missing something? ===cut=== kernel: [ 599.949295] radeon :01:00.0: ring 3 stalled for more than 10167msec kernel: [ 599.949305] radeon :01:00.0: GPU lockup (waiting for 0x1eb0 last fence id 0x1eaf on ring 3) kernel: [ 599.949312] radeon :01:00.0: scheduling IB failed (-35). kernel: [ 600.507409] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0018 address=0x8040a840 flags=0x0010] kernel: [ 600.507420] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0018 address=0x8040a870 flags=0x0030] kernel: [ 600.507426] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0018 address=0x8100 flags=0x0030] kernel: [ 600.507431] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0018 address=0x8040a700 flags=0x0010] kernel: [ 600.507460] radeon :01:00.0: Saved 19308 dwords of commands on ring 0. kernel: [ 600.507590] radeon :01:00.0: GPU softreset: 0x006C kernel: [ 600.507593] radeon :01:00.0: GRBM_STATUS = 0xA0003028 kernel: [ 600.507596] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 kernel: [ 600.507598] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 kernel: [ 600.507600] radeon :01:00.0: SRBM_STATUS = 0x20C0 kernel: [ 600.507711] radeon :01:00.0: SRBM_STATUS2 = 0x kernel: [ 600.507714] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x kernel: [ 600.507716] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x0001 kernel: [ 600.507718] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 kernel: [ 600.507720] radeon :01:00.0: R_008680_CP_STAT = 0x80010243 kernel: [ 600.507723] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44483106 kernel: [ 600.507725] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44E84266 kernel: [ 600.507728] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x kernel: [ 600.507730] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x kernel: [ 601.054357] radeon :01:00.0: GRBM_SOFT_RESET=0xDDFF kernel: [ 601.054411] radeon :01:00.0: SRBM_SOFT_RESET=0x00100140 kernel: [ 601.055568] radeon :01:00.0: GRBM_STATUS = 0x3028 kernel: [ 601.055571] radeon :01:00.0: GRBM_STATUS_SE0 = 0x0006 kernel: [ 601.055573] radeon :01:00.0: GRBM_STATUS_SE1 = 0x0006 kernel: [ 601.055575] radeon :01:00.0: SRBM_STATUS = 0x2AC0 kernel: [ 601.055686] radeon :01:00.0: SRBM_STATUS2 = 0x kernel: [ 601.055689] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x kernel: [ 601.055691] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x kernel: [ 601.055693] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x kernel: [ 601.055695] radeon :01:00.0: R_008680_CP_STAT = 0x kernel: [ 601.055698] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 kernel: [ 601.055700] radeon :01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 kernel: [ 601.055951] radeon :01:00.0: GPU reset succeeded, trying to resume kernel: [ 601.083744] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0 kernel: [ 601.083747] [drm] PCIE gen 2 link speeds already enabled kernel: [ 601.084938] [drm] PCIE GART of 1024M enabled (table at 0x00276000). kernel: [ 601.085046] radeon :01:00.0: WB enabled kernel: [ 601.085049] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x880413fbec00 kernel: [ 601.085052] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x880413fbec04 kernel: [ 601.085054] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x880413fbec08 kernel: [ 601.085056] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x880413fbec0c kernel: [ 601.085057] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x880413fbec10 kernel: [ 601.086030] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90011db5a18 kernel: [ 601.271000] [drm] ring test on 0 succeeded in 3 usecs kernel: [ 601.271006] [drm] ring test on 1 succeeded in 1 usecs kernel: [ 601.271011] [drm] ring test on 2 succeeded in 1 usecs kernel: [ 601.271075] [drm] ring test on 3 succeeded in 2 usecs kernel: [
[Bug 83616] System crashes in xonotic with kernel 3.17-rc since linux commit 86302eeadebfab94530b00f5e53a23f911ff41e4
https://bugs.freedesktop.org/show_bug.cgi?id=83616 Alexandre Demers changed: What|Removed |Added Summary|Sydtem crashes in xonotic |System crashes in xonotic |with kernel 3.17-rc since |with kernel 3.17-rc since |linux commit|linux commit |86302eeadebfab94530b00f5e53 |86302eeadebfab94530b00f5e53 |a23f911ff41e4 |a23f911ff41e4 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/c5ee7c86/attachment.html>
[PATCH 01/11] drm/mst: rework payload table allocation to conform better.
From: Dave Airlie
The old code has problems with the Dell MST monitors due to some
assumptions I made that weren't true.
I initially thought the Virtual Channel Payload IDs had to be in
the DPCD table in ascending order, however it appears that assumption
is bogus.
The old code also assumed it was possible to insert a member
into the table and it would move other members up, like it does
when you remove table entries, however reality has shown this
isn't true.
So the new code allocates VCPIs separate from entries in the payload
tracking table, and when we remove an entry from the DPCD table,
I shuffle the tracking payload entries around in the struct.
This appears to make VT switch more robust (still not perfect)
with an MST enabled Dell monitor.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 77 ++-
include/drm/drm_dp_mst_helper.h | 2 +
2 files changed, 59 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ac3c273..50926db 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -682,7 +682,7 @@ static int build_allocate_payload(struct
drm_dp_sideband_msg_tx *msg, int port_n
static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_vcpi *vcpi)
{
- int ret;
+ int ret, vcpi_ret;
mutex_lock(&mgr->payload_lock);
ret = find_first_zero_bit(&mgr->payload_mask, mgr->max_payloads + 1);
@@ -692,8 +692,16 @@ static int drm_dp_mst_assign_payload_id(struct
drm_dp_mst_topology_mgr *mgr,
goto out_unlock;
}
+ vcpi_ret = find_first_zero_bit(&mgr->vcpi_mask, mgr->max_payloads + 1);
+ if (vcpi_ret > mgr->max_payloads) {
+ ret = -EINVAL;
+ DRM_DEBUG_KMS("out of vcpi ids %d\n", ret);
+ goto out_unlock;
+ }
+
set_bit(ret, &mgr->payload_mask);
- vcpi->vcpi = ret;
+ set_bit(vcpi_ret, &mgr->vcpi_mask);
+ vcpi->vcpi = vcpi_ret + 1;
mgr->proposed_vcpis[ret - 1] = vcpi;
out_unlock:
mutex_unlock(&mgr->payload_lock);
@@ -701,15 +709,23 @@ out_unlock:
}
static void drm_dp_mst_put_payload_id(struct drm_dp_mst_topology_mgr *mgr,
- int id)
+ int vcpi)
{
- if (id == 0)
+ int i;
+ if (vcpi == 0)
return;
mutex_lock(&mgr->payload_lock);
- DRM_DEBUG_KMS("putting payload %d\n", id);
- clear_bit(id, &mgr->payload_mask);
- mgr->proposed_vcpis[id - 1] = NULL;
+ DRM_DEBUG_KMS("putting payload %d\n", vcpi);
+ clear_bit(vcpi - 1, &mgr->vcpi_mask);
+
+ for (i = 0; i < mgr->max_payloads; i++) {
+ if (mgr->proposed_vcpis[i])
+ if (mgr->proposed_vcpis[i]->vcpi == vcpi) {
+ mgr->proposed_vcpis[i] = NULL;
+ clear_bit(i + 1, &mgr->payload_mask);
+ }
+ }
mutex_unlock(&mgr->payload_lock);
}
@@ -1563,7 +1579,7 @@ static int drm_dp_destroy_payload_step1(struct
drm_dp_mst_topology_mgr *mgr,
}
drm_dp_dpcd_write_payload(mgr, id, payload);
- payload->payload_state = 0;
+ payload->payload_state = DP_PAYLOAD_DELETE_LOCAL;
return 0;
}
@@ -1590,7 +1606,7 @@ static int drm_dp_destroy_payload_step2(struct
drm_dp_mst_topology_mgr *mgr,
*/
int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr)
{
- int i;
+ int i, j;
int cur_slots = 1;
struct drm_dp_payload req_payload;
struct drm_dp_mst_port *port;
@@ -1607,26 +1623,46 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr)
port = NULL;
req_payload.num_slots = 0;
}
+
+ if (mgr->payloads[i].start_slot != req_payload.start_slot) {
+ mgr->payloads[i].start_slot = req_payload.start_slot;
+ }
/* work out what is required to happen with this payload */
- if (mgr->payloads[i].start_slot != req_payload.start_slot ||
- mgr->payloads[i].num_slots != req_payload.num_slots) {
+ if (mgr->payloads[i].num_slots != req_payload.num_slots) {
/* need to push an update for this payload */
if (req_payload.num_slots) {
- drm_dp_create_payload_step1(mgr, i + 1,
&req_payload);
+ drm_dp_create_payload_step1(mgr,
mgr->proposed_vcpis[i]->vcpi, &req_payload);
mgr->payloads[i].num_slots =
req_payload.num_slots;
} else if (mgr->payloads[i].num_slots) {
mgr->payloads[i].nu
[RFC] attempting to hide 30" monitor in kernel (raw)
All these are on top of rc3 (also in my drm-mst-hide-monitor branch). So after talking to Keith and Daniel in Chicago I decided to give another go at hiding the horror that is 30" 4k dual-panel MST monitors in the kernel. Also this hw is not going away, if anything it seems to be getting worse with Dell promising a 5k monitor, requiring 2 MST ports. The first two patches aren't really part of this series, I should probably put them in -fixes anyways. (i.e. ignore them) So this series, contains the functionality changes required to hide tiled crtc underneath a master crtc, and to keep track of them for modeset and pageflipping and cursors (not finished). It also allows EDID patching to fake the super-mode, along with hiding the sub-connectors. Patch 9 is probably the biggest hack here due to lack of atomic modesetting, and how userspace picks crtcs. Patch 10 is pageflip so hacky as well, and 11 is just bogus cursor handling, I just wanted to see the cursor in some form for now. Mostly I'm looking for some high-level review of the concepts of this and how much harder it'll make life going forward. Dave.
[PATCH 02/11] drm/i915: add config option to enable/disable DP MST
From: Dave Airlie
Since DP MST has new userspace requirements and any effort at trying
to shoehorn things into the something the current userspace can handle are
doomed, lets just put this behind a config option.
This also adds a command line arg to switch it on as well.
Distros should probably turn it on when they have a new enough Xorg intel
driver.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/Kconfig| 10 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_params.c | 5 +
drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
4 files changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab3..94a9094 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -69,3 +69,13 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
option changes the default for that module option.
If in doubt, say "N".
+
+config DRM_I915_DP_MST
+ bool "Enable DisplayPort 1.2 MST support by default"
+ depends on DRM_I915
+ default n
+ help
+ Choose this option if you want to support DP 1.2 MST and have a new
+ enough userspace to use it. DP 1.2 MST is required for multi-head
+ support on many laptop docks when combined with Haswell or later
+ chipsets.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7a830ea..86759ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2149,6 +2149,7 @@ struct i915_params {
bool disable_vtd_wa;
int use_mmio_flip;
bool mmio_debug;
+ bool dp_mst;
};
extern struct i915_params i915 __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7f84dd26..973c773 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -50,6 +50,7 @@ struct i915_params i915 __read_mostly = {
.disable_vtd_wa = 0,
.use_mmio_flip = 0,
.mmio_debug = 0,
+ .dp_mst = IS_ENABLED(CONFIG_DRM_I915_DP_MST),
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -167,3 +168,7 @@ module_param_named(mmio_debug, i915.mmio_debug, bool, 0600);
MODULE_PARM_DESC(mmio_debug,
"Enable the MMIO debug code (default: false). This may negatively "
"affect performance.");
+
+module_param_named(dp_mst, i915.dp_mst, bool, 0600);
+MODULE_PARM_DESC(dp_mst,
+ "Enable DP MST support (1=enabled, 0=disabled, default depends on
CONFIG_DRM_I915_DP_MST.");
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d9a7a78..116b656 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -522,6 +522,9 @@ intel_dp_mst_encoder_init(struct intel_digital_port
*intel_dig_port, int conn_ba
struct drm_device *dev = intel_dig_port->base.base.dev;
int ret;
+ if (i915.dp_mst == false)
+ return 0;
+
intel_dp->can_mst = true;
intel_dp->mst_mgr.cbs = &mst_cbs;
--
1.9.3
[PATCH 03/11] drm/mst: start caching edid for logical ports
From: Dave Airlie
For the monitors with panels we only want EDID once,
and they show up on logical ports, which are always connected.
This is required as if we start hiding connector status
we won't be able to get the EDID normally later.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
include/drm/drm_dp_mst_helper.h | 4 +++-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 50926db..234a82c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1096,6 +1096,9 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
char proppath[255];
build_mst_prop_path(port, mstb, proppath);
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
+
+ if (port->port_num >= 8)
+ port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
}
/* put reference to this port */
@@ -2149,7 +2152,8 @@ EXPORT_SYMBOL(drm_dp_mst_hpd_irq);
* This returns the current connection state for a port. It validates the
* port pointer still exists so the caller doesn't require a reference
*/
-enum drm_connector_status drm_dp_mst_detect_port(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
+enum drm_connector_status drm_dp_mst_detect_port(struct drm_connector
*connector,
+struct drm_dp_mst_topology_mgr
*mgr, struct drm_dp_mst_port *port)
{
enum drm_connector_status status = connector_status_disconnected;
@@ -2168,6 +2172,10 @@ enum drm_connector_status drm_dp_mst_detect_port(struct
drm_dp_mst_topology_mgr
case DP_PEER_DEVICE_SST_SINK:
status = connector_status_connected;
+ /* for logical ports - cache the EDID */
+ if (port->port_num >= 8 && !port->cached_edid) {
+ port->cached_edid = drm_get_edid(connector,
&port->aux.ddc);
+ }
break;
case DP_PEER_DEVICE_DP_LEGACY_CONV:
if (port->ldps)
@@ -2199,7 +2207,10 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
*connector, struct drm_dp_
if (!port)
return NULL;
- edid = drm_get_edid(connector, &port->aux.ddc);
+ if (port->cached_edid)
+ edid = drm_edid_duplicate(port->cached_edid);
+ else
+ edid = drm_get_edid(connector, &port->aux.ddc);
drm_dp_put_port(port);
return edid;
}
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 116b656..d92048b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -283,7 +283,7 @@ intel_mst_port_dp_detect(struct drm_connector *connector)
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
- return drm_dp_mst_detect_port(&intel_dp->mst_mgr,
intel_connector->port);
+ return drm_dp_mst_detect_port(connector, &intel_dp->mst_mgr,
intel_connector->port);
}
static enum drm_connector_status
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 338fc10..ee6fbad 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -92,6 +92,8 @@ struct drm_dp_mst_port {
struct drm_dp_vcpi vcpi;
struct drm_connector *connector;
struct drm_dp_mst_topology_mgr *mgr;
+
+ struct edid *cached_edid; /* for DP logical ports - make tiling work */
};
/**
@@ -474,7 +476,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool
*handled);
-enum drm_connector_status drm_dp_mst_detect_port(struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+enum drm_connector_status drm_dp_mst_detect_port(struct drm_connector
*connector, struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
--
1.9.3
[PATCH 04/11] drm/displayid: add some DisplayID related defines/structs.
From: Dave Airlie
Just enough to get the tiling info from a Dell 4k monitor.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_displayid.c| 68 ++
drivers/gpu/drm/drm_edid.c | 29 ++--
drivers/gpu/drm/i915/intel_modes.c | 3 ++
include/drm/drm_crtc.h | 5 +++
include/drm/drm_displayid.h| 55 ++
include/drm/drm_edid.h | 2 ++
7 files changed, 161 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/drm_displayid.c
create mode 100644 include/drm/drm_displayid.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..50eebe1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o
+ drm_modeset_lock.o drm_displayid.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
new file mode 100644
index 000..d434da1
--- /dev/null
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -0,0 +1,68 @@
+/* decode display ID block */
+
+/* just enough coding to get tiling blocks from new monitors */
+
+#include "drmP.h"
+#include "drm_edid.h"
+#include "drm_displayid.h"
+
+int drm_parse_display_id(struct drm_connector *connector,
+u8 *displayid, int length, bool is_edid_extension)
+{
+ /* if this is an EDID extension the first byte will be 0x70 */
+ int idx = 0;
+ struct displayid_hdr *base;
+ struct displayid_block *block;
+ u8 csum = 0;
+ int i;
+ if (is_edid_extension)
+ idx = 1;
+
+ base = (struct displayid_hdr *)&displayid[idx];
+
+ printk("base revision 0x%x, length %d, %d %d\n",
+ base->rev, base->bytes, base->prod_id, base->ext_count);
+
+ if (base->bytes + 5 > length - idx)
+ return -EINVAL;
+
+ for (i = idx; i <= base->bytes + 5; i++) {
+ csum += displayid[i];
+ }
+ if (csum) {
+ DRM_ERROR("DisplayID checksum invalid, remainder is %d\n",
csum);
+ return -EINVAL;
+ }
+
+ block = (struct displayid_block *)&displayid[idx + 4];
+ printk("block id %d, rev %d, len %d\n",
+ block->tag, block->rev, block->num_bytes);
+
+ switch (block->tag) {
+ case DATA_BLOCK_TILED_DISPLAY: {
+ struct displayid_tiled_block *tile = (struct
displayid_tiled_block *)block;
+ u16 w, h;
+ u8 tile_v_loc, tile_h_loc;
+ u8 num_v_tile, num_h_tile;
+
+ w = tile->tile_size[0] | tile->tile_size[1] << 8;
+ h = tile->tile_size[2] | tile->tile_size[3] << 8;
+
+ num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 0x30);
+ num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 2) &
0x30);
+ tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 0x3) <<
4);
+ tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 2) &
0x3) << 4);
+
+ printk("tile cap %d\n", tile->tile_cap);
+ printk("tile_size %d x %d\n", w, h);
+ printk("topo num tiles %dx%d, location %dx%d\n",
+ num_h_tile, num_v_tile, tile_h_loc, tile_v_loc);
+ printk("vend %c%c%c\n", tile->topology_id[0],
tile->topology_id[1], tile->topology_id[2]);
+ }
+ break;
+ default:
+ printk("unknown displayid tag %d\n", block->tag);
+ break;
+ }
+ return 0;
+}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1dbf3bc..3d805aa 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2386,7 +2386,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
/*
* Search EDID for CEA extension block.
*/
-static u8 *drm_find_cea_extension(struct edid *edid)
+static u8 *drm_find_edid_extension(struct edid *edid, int ext_id)
{
u8 *edid_ext = NULL;
int i;
@@ -2398,7 +2398,7 @@ static u8 *drm_find_cea_extension(struct edid *edid)
/* Find CEA extension */
for (i = 0; i < edid->extensions; i++) {
edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
- if (edid_ext[0] == CEA_EXT)
+ if (edid_ext[0] == ext_id)
break;
}
@@ -2408,6 +2408,16 @@ static u8 *drm_find_cea_extension(struct edid *edid)
return edid_ext;
}
+static u8 *drm_find_cea_extension(struct edid *edid)
+{
+ return drm_fi
[PATCH 05/11] drm/dp/mst: add concept of base connector id
From: Dave Airlie
This gives us a base identifier to group tiled outputs from.
However after reading about the Dell 5k monitor I expect this
is probably too little, and we need some sort of hash table
from the monitor EDID serial number.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 30 ++
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 234a82c..5d2a08e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -778,14 +778,14 @@ out:
return ret;
}
-static struct drm_dp_mst_branch *drm_dp_add_mst_branch_device(u8 lct, u8 *rad)
+static struct drm_dp_mst_branch *drm_dp_add_mst_branch_device(u8 lct, u8 *rad,
u8 conn_base_id)
{
struct drm_dp_mst_branch *mstb;
mstb = kzalloc(sizeof(*mstb), GFP_KERNEL);
if (!mstb)
return NULL;
-
+ mstb->conn_base_id = conn_base_id;
mstb->lct = lct;
if (lct > 1)
memcpy(mstb->rad, rad, lct / 2);
@@ -983,7 +983,7 @@ static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port
*port)
case DP_PEER_DEVICE_MST_BRANCHING:
lct = drm_dp_calculate_rad(port, rad);
- port->mstb = drm_dp_add_mst_branch_device(lct, rad);
+ port->mstb = drm_dp_add_mst_branch_device(lct, rad, 0);
port->mstb->mgr = port->mgr;
port->mstb->port_parent = port;
@@ -1097,6 +1097,9 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
build_mst_prop_path(port, mstb, proppath);
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
+ if (port->mstb) {
+ port->mstb->conn_base_id = port->connector->base.id;
+ }
if (port->port_num >= 8)
port->cached_edid = drm_get_edid(port->connector,
&port->aux.ddc);
}
@@ -1849,7 +1852,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
mgr->avail_slots = mgr->total_slots;
/* add initial branch device at LCT 1 */
- mstb = drm_dp_add_mst_branch_device(1, NULL);
+ mstb = drm_dp_add_mst_branch_device(1, NULL, mgr->conn_base_id);
if (mstb == NULL) {
ret = -ENOMEM;
goto out_unlock;
@@ -2216,6 +2219,25 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
*connector, struct drm_dp_
}
EXPORT_SYMBOL(drm_dp_mst_get_edid);
+int drm_dp_mst_get_base_id(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port)
+{
+ int val;
+ /* we need to search for the port in the mgr in case its gone */
+ port = drm_dp_get_validated_port_ref(mgr, port);
+ if (!port)
+ return 0;
+
+ if (!port->parent) {
+ drm_dp_put_port(port);
+ return 0;
+ }
+
+ val = port->parent->conn_base_id;
+ drm_dp_put_port(port);
+ return val;
+}
+EXPORT_SYMBOL(drm_dp_mst_get_base_id);
/**
* drm_dp_find_vcpi_slots() - find slots for this PBN value
* @mgr: manager to use
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index ee6fbad..e28d6763 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -131,6 +131,8 @@ struct drm_dp_mst_branch {
struct drm_dp_sideband_msg_tx *tx_slots[2];
int last_seqno;
bool link_address_sent;
+
+ int conn_base_id;
};
@@ -480,6 +482,8 @@ enum drm_connector_status drm_dp_mst_detect_port(struct
drm_connector *connector
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
+int drm_dp_mst_get_base_id(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port);
int drm_dp_calc_pbn_mode(int clock, int bpp);
--
1.9.3
[PATCH 06/11] drm/tile: attempt to set tiled crtcs up
From: Dave Airlie
Using the tiling info attempt to set a mode across two crtcs
---
drivers/gpu/drm/drm_crtc.c| 100 +-
drivers/gpu/drm/drm_displayid.c | 13 -
drivers/gpu/drm/drm_dp_mst_topology.c | 18 +-
drivers/gpu/drm/drm_edid.c| 2 +
drivers/gpu/drm/drm_probe_helper.c| 2 +-
drivers/gpu/drm/i915/intel_modes.c| 1 +
include/drm/drm_crtc.h| 8 +++
7 files changed, 140 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 90e7730..99fa259 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2506,6 +2506,93 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_check_viewport);
+/* tiled variants */
+static int drm_mode_setcrtc_tiled(struct drm_mode_set *orig_set)
+{
+ struct drm_device *dev = orig_set->crtc->dev;
+ struct drm_mode_set set[2];
+ struct drm_crtc *crtc2, *pick_crtc = NULL;
+ struct drm_connector *connector, *pick_conn[2];
+ struct drm_display_mode *cur_mode, *pick_modes[2];
+ int ret;
+
+ /* first up we need to find another crtc to use */
+ list_for_each_entry(crtc2, &dev->mode_config.crtc_list, head) {
+ if (crtc2 == orig_set->crtc)
+ continue;
+ if (crtc2->enabled)
+ continue;
+ pick_crtc = crtc2;
+ break;
+ }
+
+ if (pick_crtc == NULL) {
+ DRM_DEBUG_KMS("unable to located second CRTC for tiling\n");
+ return -EINVAL;
+ }
+
+ pick_conn[0] = orig_set->connectors[0];
+ pick_conn[1] = NULL;
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (!connector->has_tile)
+ continue;
+
+ if (connector == pick_conn[0])
+ continue;
+
+ if (connector->tile_group_id != pick_conn[0]->tile_group_id)
+ continue;
+
+ pick_conn[1] = connector;
+ }
+
+ DRM_DEBUG_KMS("picked connectors %x and %x from tgid %d\n",
pick_conn[0]->base.id,
+ pick_conn[1]->base.id, pick_conn[0]->tile_group_id);
+ if (pick_conn[1] == NULL) {
+ DRM_DEBUG_KMS("unable to located second connector for tiling
%d\n", pick_conn[0]->tile_group_id);
+ return -EINVAL;
+ }
+
+ pick_modes[0] = pick_modes[1] = NULL;
+ list_for_each_entry(cur_mode, &pick_conn[0]->modes, head) {
+ DRM_DEBUG_KMS("trying %d %d\n", cur_mode->hdisplay,
cur_mode->vdisplay);
+ if (cur_mode->hdisplay == pick_conn[1]->tile_h_size + 1 &&
+ cur_mode->vdisplay == pick_conn[1]->tile_v_size + 1) {
+ pick_modes[0] = pick_modes[1] = cur_mode;
+ break;
+ }
+ }
+ if (pick_modes[0] == NULL) {
+ DRM_DEBUG_KMS("unable to locate second mode for tiling %d
%d\n", pick_conn[1]->tile_h_size, pick_conn[1]->tile_v_size);
+ return -EINVAL;
+ }
+
+ set[0].fb = set[1].fb = orig_set->fb;
+
+ set[0].crtc = orig_set->crtc;
+ set[1].crtc = pick_crtc;
+
+ set[0].connectors = &pick_conn[0];
+ set[0].num_connectors = 1;
+
+ set[1].connectors = &pick_conn[1];
+ set[1].num_connectors = 1;
+
+ set[0].x = orig_set->x;
+ set[0].y = orig_set->y;
+ set[1].x = orig_set->x + ((pick_conn[1]->tile_h_loc == 1) ?
pick_conn[0]->tile_h_size + 1 : 0);
+ set[1].y = orig_set->y + ((pick_conn[1]->tile_v_loc == 1) ?
pick_conn[0]->tile_v_size + 1 : 0);
+
+ /* find a mode to use on each head */
+ set[0].mode = pick_modes[0];
+ set[1].mode = pick_modes[1];
+
+ ret = drm_mode_set_config_internal(&set[0]);
+
+ ret = drm_mode_set_config_internal(&set[1]);
+
+ return ret;
+}
/**
* drm_mode_setcrtc - set CRTC configuration
* @dev: drm device for the ioctl
@@ -2532,6 +2619,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
uint32_t __user *set_connectors_ptr;
int ret;
int i;
+ int num_tiles = 1;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -2640,6 +2728,12 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
connector->base.id,
connector->name);
+ if (crtc_req->count_connectors == 1) {
+ if (connector->has_tile &&
connector->tile_is_single_monitor) {
+ if (mode->hdisplay >
connector->tile_h_size || mode->vdisplay > connector->tile_v_size)
+ num_tiles = 2;
+ }
+ }
[PATCH 07/11] drm/edid: allow patching the EDID to report monster mode
From: Dave Airlie
This patches the EDID to add the special mode.
TODO make this more generic.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 13 ++---
drivers/gpu/drm/drm_edid.c| 36 +++
include/drm/drm_edid.h| 5 -
3 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1f15d85..08b7140 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -31,6 +31,7 @@
#include
#include
+#include
/**
* DOC: dp mst helper
@@ -2225,9 +2226,15 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
*connector, struct drm_dp_
goto out;
}
}
- if (port->cached_edid)
- edid = drm_edid_duplicate(port->cached_edid);
- else
+ if (port->cached_edid) {
+ if (connector->has_tile && connector->tile_is_single_monitor) {
+ edid = drm_patch_edid_detailed_mode(connector->dev,
+ port->cached_edid,
+ 3840, 2160, 60);
+ } else {
+ edid = drm_edid_duplicate(port->cached_edid);
+ }
+ } else
edid = drm_get_edid(connector, &port->aux.ddc);
out:
drm_dp_put_port(port);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 94e8a57..3ccc2c6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3892,3 +3892,39 @@ void drm_get_displayid(struct drm_connector *connector,
return;
}
EXPORT_SYMBOL(drm_get_displayid);
+
+static void drm_patch_edid_reset_csum(struct edid *edid)
+{
+ unsigned i, sum = 0;
+ unsigned char *p = (unsigned char *)edid;
+
+ for (i = 0; i < EDID_LENGTH - 1; i++)
+ sum += p[i];
+ edid->checksum = (0x100 - (sum & 0xff)) & 0xff;
+}
+
+struct edid *drm_patch_edid_detailed_mode(struct drm_device *dev,
+ struct edid *orig_edid,
+ int hdisplay, int vdisplay, int
vrefresh)
+{
+ struct edid *edid = drm_edid_duplicate(orig_edid);
+ struct drm_display_mode *mode = drm_cvt_mode(dev, hdisplay, vdisplay,
vrefresh, true, false, false);
+
+ int hblank = mode->htotal - mode->hdisplay;
+ int vblank = mode->vtotal - mode->vdisplay;
+
+ DRM_DEBUG_KMS("mode->clock is %d, %d\n", mode->clock,
cpu_to_le16(mode->clock / 10));
+ edid->detailed_timings[1] = edid->detailed_timings[0];
+ edid->detailed_timings[0].pixel_clock = cpu_to_le16(mode->clock / 10);
+ edid->detailed_timings[0].data.pixel_data.hactive_lo = mode->hdisplay &
0xff;
+ edid->detailed_timings[0].data.pixel_data.hblank_lo = hblank & 0xff;
+ edid->detailed_timings[0].data.pixel_data.hactive_hblank_hi =
(mode->hdisplay >> 4 & 0xf0) | ((hblank >> 8) & 0xf);
+ edid->detailed_timings[0].data.pixel_data.vactive_lo = mode->vdisplay &
0xff;
+ edid->detailed_timings[0].data.pixel_data.vblank_lo = vblank & 0xff;
+ edid->detailed_timings[0].data.pixel_data.vactive_vblank_hi =
(mode->vdisplay >> 4 & 0xf0) | ((vblank >> 8) & 0xf);
+
+ drm_patch_edid_reset_csum(edid);
+
+ return edid;
+}
+EXPORT_SYMBOL(drm_patch_edid_detailed_mode);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 3e87f5a..17eb503 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -280,5 +280,8 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
int
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
const struct drm_display_mode
*mode);
-
+struct drm_device;
+struct edid *drm_patch_edid_detailed_mode(struct drm_device *dev,
+ struct edid *orig_edid,
+ int hdisplay, int vdisplay, int
vrefresh);
#endif /* __DRM_EDID_H__ */
--
1.9.3
[PATCH 09/11] drm/crtc: workaround userspace trying to derail crtc stealing
From: Dave Airlie
This is probably not the greatest idea in the world, but if userspace
does a modesetting sequences
initial state : crtc 0 -> eDP-1
modeset : crtc 1 -> DP-4 (dual crtc)
we have to steal crtc 2 for DP-3
modeset : crtc 2 -> eDP-1
we are kind off stuck, so when we see this, we back up the crtc
configuration, proceed with the userspace modeset, then do
the second modeset on the released crtc 0.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 107 ++---
1 file changed, 102 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 628f3af..e30518b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2509,6 +2509,91 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_check_viewport);
+static int drm_mode_get_crtc_set(struct drm_crtc *crtc, struct drm_mode_set
*backup_set)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_display_mode *mode;
+ struct drm_connector *connector;
+ int num_connectors = 0;
+ int i;
+
+ backup_set->crtc = crtc;
+ backup_set->x = crtc->x;
+ backup_set->y = crtc->y;
+ backup_set->fb = crtc->primary->fb;
+
+ mode = drm_mode_create(dev);
+ if (!mode) {
+ return -ENOMEM;
+ }
+
+ *mode = crtc->mode;
+ backup_set->mode = mode;
+
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (!connector->encoder)
+ continue;
+ if (!connector->encoder->crtc)
+ continue;
+
+ if (connector->encoder->crtc == crtc)
+ num_connectors++;
+ }
+
+ backup_set->connectors = kmalloc(num_connectors * sizeof(struct
drm_connector *), GFP_KERNEL);
+ if (!backup_set->connectors) {
+ drm_mode_destroy(dev, mode);
+ return -ENOMEM;
+ }
+
+ i = 0;
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (!connector->encoder)
+ continue;
+ if (!connector->encoder->crtc)
+ continue;
+
+ if (connector->encoder->crtc == crtc)
+ backup_set->connectors[i++] = connector;
+ }
+
+ backup_set->num_connectors = i;
+ return 0;
+}
+
+static int drm_mode_reset_tiled_crtc(struct drm_mode_set *backup_set,
+struct drm_crtc *tile_master)
+{
+ struct drm_crtc *crtc2, *pick_crtc = NULL;
+ struct drm_device *dev = backup_set->crtc->dev;
+ int ret;
+ /* first up we need to find another crtc to use */
+ list_for_each_entry(crtc2, &dev->mode_config.crtc_list, head) {
+ if (crtc2 == backup_set->crtc)
+ continue;
+ if (crtc2->enabled && !crtc2->tile_master)
+ continue;
+ pick_crtc = crtc2;
+ break;
+ }
+
+ if (!pick_crtc) {
+ DRM_DEBUG_KMS("unable to find backup crtc\n");
+ goto out;
+
+ }
+
+ backup_set->crtc = pick_crtc;
+
+ pick_crtc->tile_master = tile_master;
+ list_add_tail(&pick_crtc->tile, &tile_master->tile_crtc_list);
+
+ ret = drm_mode_set_config_internal(backup_set);
+out:
+ kfree(backup_set->connectors);
+ return 0;
+}
+
/* tiled variants */
static int drm_mode_setcrtc_tiled(struct drm_mode_set *orig_set)
{
@@ -2631,6 +2716,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
struct drm_framebuffer *fb = NULL;
struct drm_display_mode *mode = NULL;
struct drm_mode_set set;
+ struct drm_mode_set tile_backup_set;
+ struct drm_crtc *backup_tile_master = NULL;
+ bool rework_backup = false;
uint32_t __user *set_connectors_ptr;
int ret;
int i;
@@ -2653,12 +2741,17 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
if (crtc->tile_master) {
- if (crtc_req->mode_valid)
- ret = -EBUSY;
- else
+ if (!crtc_req->mode_valid) {
ret = 0;
- DRM_DEBUG_KMS("[CRTC:%d] refused due to tile %d\n",
crtc->base.id, ret);
- goto out;
+ goto out;
+ }
+
+ drm_mode_get_crtc_set(crtc, &tile_backup_set);
+ DRM_DEBUG_KMS("[CRTC:%d] backing up tiling\n", crtc->base.id);
+ rework_backup = true;
+ backup_tile_master = crtc->tile_master;
+ crtc->tile_master = false;
+ list_del(&crtc->tile);
}
if (crtc_req->mode_valid) {
@@ -2791,6 +2884,10 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
[PATCH 08/11] drm/crtc: attempt to set tiled modes from userspace
From: Dave Airlie
So when userspace asks us to set a mode on a tiled crtc,
split it up and find the actual modes and attempt to set them.
Also disable crtcs when no longer in tiled group.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c| 51 ---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +
include/drm/drm_crtc.h| 8 ++
3 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 99fa259..628f3af 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -764,6 +764,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
crtc->funcs = funcs;
crtc->invert_dimensions = false;
+ INIT_LIST_HEAD(&crtc->tile_crtc_list);
+ crtc->tile_master = NULL;
+
drm_modeset_lock_all(dev);
drm_modeset_lock_init(&crtc->mutex);
/* dropped by _unlock_all(): */
@@ -2520,7 +2523,7 @@ static int drm_mode_setcrtc_tiled(struct drm_mode_set
*orig_set)
list_for_each_entry(crtc2, &dev->mode_config.crtc_list, head) {
if (crtc2 == orig_set->crtc)
continue;
- if (crtc2->enabled)
+ if (crtc2->enabled && !crtc2->tile_master)
continue;
pick_crtc = crtc2;
break;
@@ -2583,14 +2586,26 @@ static int drm_mode_setcrtc_tiled(struct drm_mode_set
*orig_set)
set[1].x = orig_set->x + ((pick_conn[1]->tile_h_loc == 1) ?
pick_conn[0]->tile_h_size + 1 : 0);
set[1].y = orig_set->y + ((pick_conn[1]->tile_v_loc == 1) ?
pick_conn[0]->tile_v_size + 1 : 0);
+ if (set[1].crtc->tile_master) {
+ list_del(&set[1].crtc->tile);
+ set[1].crtc->tile_master = NULL;
+ }
+ list_add_tail(&set[1].crtc->tile, &set[0].crtc->tile_crtc_list);
+ set[1].crtc->tile_master = set[0].crtc;
/* find a mode to use on each head */
set[0].mode = pick_modes[0];
set[1].mode = pick_modes[1];
ret = drm_mode_set_config_internal(&set[0]);
- ret = drm_mode_set_config_internal(&set[1]);
+ if (!ret) {
+ ret = drm_mode_set_config_internal(&set[1]);
+ }
+ if (ret) {
+ set[1].crtc->tile_master = NULL;
+ list_del(&set[1].crtc->tile);
+ }
return ret;
}
/**
@@ -2637,6 +2652,15 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
+ if (crtc->tile_master) {
+ if (crtc_req->mode_valid)
+ ret = -EBUSY;
+ else
+ ret = 0;
+ DRM_DEBUG_KMS("[CRTC:%d] refused due to tile %d\n",
crtc->base.id, ret);
+ goto out;
+ }
+
if (crtc_req->mode_valid) {
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
@@ -2748,9 +2772,25 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
if (num_tiles > 1) {
ret = drm_mode_setcrtc_tiled(&set);
- } else
- ret = drm_mode_set_config_internal(&set);
+ } else {
+ if (!list_empty(&crtc->tile_crtc_list)) {
+ struct drm_crtc *tile_crtc, *t;
+
+ list_for_each_entry_safe(tile_crtc, t,
&crtc->tile_crtc_list, tile) {
+ struct drm_mode_set set2;
+
+ tile_crtc->tile_master = NULL;
+ list_del(&tile_crtc->tile);
+ DRM_DEBUG_KMS("disabling crtc %p due to no
longer needing tiling %p\n", tile_crtc, tile_crtc->primary);
+ memset(&set2, 0, sizeof(struct drm_mode_set));
+ set2.crtc = tile_crtc;
+ set2.fb = NULL;
+ ret = drm_mode_set_config_internal(&set2);
+ }
+ }
+ ret = drm_mode_set_config_internal(&set);
+ }
out:
if (fb)
drm_framebuffer_unreference(fb);
@@ -4226,6 +4266,9 @@ static int drm_mode_connector_set_obj_prop(struct
drm_mode_object *obj,
int ret = -EINVAL;
struct drm_connector *connector = obj_to_connector(obj);
+ if (connector->has_tile && connector->tile_is_single_monitor &&
+ (connector->tile_h_loc || connector->tile_v_loc))
+ return 0;
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
if (connector->funcs->dpms)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 08b7140..ca5eee6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology
[PATCH 10/11] drm/tiled: add page_flip support for multi-crtc monitors
From: Dave Airlie
This is OMG bad, but in order to get semantics that don't defeat
userspace we have to wait for both flips to complete.
So rewrite the event handling code to make sure we wait for
all crtcs in the tile group to complete flipping.
The main problem otherwise is userspace does
add_fb
ioctl(PAGE_FLIP, crtc, fb)
wait_for_event
--> page_flip event
rm_fb
This rm_fb will forcefully nuke the framebuffer from all crtcs
that are currently running, however that causes bad things to happen
like the crtc gets turned off. So we need to wait before sending
the event so userspace doesn't do this. Otherwise gnome-shell
turns off half the display after 5-10 frames.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 31 ++-
drivers/gpu/drm/drm_irq.c| 7 ++-
drivers/gpu/drm/i915/intel_display.c | 12
include/drm/drmP.h | 2 ++
4 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e30518b..dd0649a0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4771,7 +4771,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
int ret = -EINVAL;
-
+ int crtc_count = 1;
if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
page_flip->reserved != 0)
return -EINVAL;
@@ -4833,14 +4833,43 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof e->event;
e->event.user_data = page_flip->user_data;
+ e->master = crtc;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy =
(void (*) (struct drm_pending_event *)) kfree;
}
+ if (!list_empty(&crtc->tile_crtc_list)) {
+ struct drm_crtc *tile;
+
+ list_for_each_entry(tile, &crtc->tile_crtc_list, tile) {
+ crtc_count++;
+ }
+ if (e)
+ e->crtc_count = crtc_count;
+ list_for_each_entry(tile, &crtc->tile_crtc_list, tile) {
+ struct drm_framebuffer *tile_fb = fb;
+
+ drm_framebuffer_reference(fb);
+ old_fb = tile->primary->fb;
+
+ ret = tile->funcs->page_flip(tile, fb, e,
page_flip->flags);
+ if (ret) {
+ old_fb = NULL;
+ } else {
+ tile_fb = NULL;
+ }
+ if (tile_fb)
+ drm_framebuffer_unreference(tile_fb);
+ if (old_fb)
+ drm_framebuffer_unreference(old_fb);
+ }
+ }
old_fb = crtc->primary->fb;
+
ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
+
if (ret) {
if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
spin_lock_irqsave(&dev->event_lock, flags);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 08ba120..9eee6e9 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -783,10 +783,15 @@ static void send_vblank_event(struct drm_device *dev,
* Caller must hold event lock.
*/
void drm_send_vblank_event(struct drm_device *dev, int crtc,
- struct drm_pending_vblank_event *e)
+ struct drm_pending_vblank_event *e)
{
struct timeval now;
unsigned int seq;
+
+ e->crtc_count--;
+ if (e->crtc_count > 0)
+ return;
+
if (crtc >= 0) {
seq = drm_vblank_count_and_time(dev, crtc, &now);
} else {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d074d70..11a6ff3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9153,8 +9153,10 @@ static void do_intel_finish_page_flip(struct drm_device
*dev,
intel_crtc->unpin_work = NULL;
- if (work->event)
- drm_send_vblank_event(dev, intel_crtc->pipe, work->event);
+ if (work->event) {
+ struct intel_crtc *tmp = to_intel_crtc(work->event->master);
+ drm_send_vblank_event(dev, tmp->pipe, work->event);
+ }
drm_crtc_vblank_put(crtc);
@@ -9795,8 +9797,10 @@ free_work:
out_hang:
intel_crtc_wait_for_pending_flips(crtc);
ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
- if (ret == 0 && event)
- drm_send_vblank_event(dev, pipe, event);
+ if (ret == 0 && event) {
+
[PATCH 11/11] drm/tiled: vague attempt at waving at cursors.
From: Dave Airlie
This is going to be a bit of a reference counting nightmare,
Since when we moved from one tile to the other, we need to
transfer the framebuffer over between them.
Also only universal is tackled here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index dd0649a0..55c9ad7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2919,7 +2919,8 @@ out:
*/
static int drm_mode_cursor_universal(struct drm_crtc *crtc,
struct drm_mode_cursor2 *req,
-struct drm_file *file_priv)
+struct drm_file *file_priv,
+bool draw)
{
struct drm_device *dev = crtc->dev;
struct drm_framebuffer *fb = NULL;
@@ -2970,7 +2971,7 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc,
crtc_y = crtc->cursor_y;
}
- if (fb) {
+ if (fb && draw) {
crtc_w = fb->width;
crtc_h = fb->height;
src_w = fb->width << 16;
@@ -2981,7 +2982,7 @@ static int drm_mode_cursor_universal(struct drm_crtc
*crtc,
* setplane_internal will take care of deref'ing either the old or new
* framebuffer depending on success.
*/
- ret = setplane_internal(crtc->cursor, crtc, fb,
+ ret = setplane_internal(crtc->cursor, crtc, draw ? fb : NULL,
crtc_x, crtc_y, crtc_w, crtc_h,
0, 0, src_w, src_h);
@@ -3017,8 +3018,30 @@ static int drm_mode_cursor_common(struct drm_device *dev,
* If this crtc has a universal cursor plane, call that plane's update
* handler rather than using legacy cursor handlers.
*/
- if (crtc->cursor)
- return drm_mode_cursor_universal(crtc, req, file_priv);
+ if (crtc->cursor) {
+ struct drm_mode_cursor2 req2;
+ struct drm_crtc *tile_crtc;
+ list_for_each_entry(tile_crtc, &crtc->tile_crtc_list, tile) {
+ req2 = *req;
+
+ /* TODO broken for > 2 tiles */
+ if (req->flags & DRM_MODE_CURSOR_MOVE) {
+ bool do_move = false;
+ if (req->x > crtc->mode.hdisplay) {
+ do_move = true;
+ req2.x = req->x - crtc->mode.hdisplay;
+ }
+ if (req->y > crtc->mode.vdisplay) {
+ do_move = true;
+ req2.y = req->y - crtc->mode.vdisplay;
+ }
+ if (do_move)
+ ret =
drm_mode_cursor_universal(tile_crtc, &req2, file_priv, true);
+ } else
+ ret = drm_mode_cursor_universal(tile_crtc,
&req2, file_priv, true);
+ }
+ return drm_mode_cursor_universal(crtc, req, file_priv, true);
+ }
drm_modeset_lock(&crtc->mutex, NULL);
if (req->flags & DRM_MODE_CURSOR_BO) {
--
1.9.3
[Bug 68799] [APITRACE] Hyper-Z lockup with Falcon BMS 4.32u6 on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=68799 --- Comment #7 from Stanis?aw Halik --- If the trace's still relevant please mirror it just in case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/d997f5e5/attachment.html>
[PATCH 02/11] drm/i915: add config option to enable/disable DP MST
On Tue, 09 Sep 2014, Dave Airlie wrote:
> From: Dave Airlie
>
> Since DP MST has new userspace requirements and any effort at trying
> to shoehorn things into the something the current userspace can handle are
> doomed, lets just put this behind a config option.
>
> This also adds a command line arg to switch it on as well.
>
> Distros should probably turn it on when they have a new enough Xorg intel
> driver.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/Kconfig| 10 ++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_params.c | 5 +
> drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
> 4 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4e39ab3..94a9094 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -69,3 +69,13 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
> option changes the default for that module option.
>
> If in doubt, say "N".
> +
> +config DRM_I915_DP_MST
> + bool "Enable DisplayPort 1.2 MST support by default"
> + depends on DRM_I915
> + default n
> + help
> + Choose this option if you want to support DP 1.2 MST and have a new
> + enough userspace to use it. DP 1.2 MST is required for multi-head
> + support on many laptop docks when combined with Haswell or later
> + chipsets.
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7a830ea..86759ea 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2149,6 +2149,7 @@ struct i915_params {
> bool disable_vtd_wa;
> int use_mmio_flip;
> bool mmio_debug;
> + bool dp_mst;
> };
> extern struct i915_params i915 __read_mostly;
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 7f84dd26..973c773 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -50,6 +50,7 @@ struct i915_params i915 __read_mostly = {
> .disable_vtd_wa = 0,
> .use_mmio_flip = 0,
> .mmio_debug = 0,
> + .dp_mst = IS_ENABLED(CONFIG_DRM_I915_DP_MST),
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -167,3 +168,7 @@ module_param_named(mmio_debug, i915.mmio_debug, bool,
> 0600);
> MODULE_PARM_DESC(mmio_debug,
> "Enable the MMIO debug code (default: false). This may negatively "
> "affect performance.");
> +
> +module_param_named(dp_mst, i915.dp_mst, bool, 0600);
The permissions should be 0400.
Jani.
> +MODULE_PARM_DESC(dp_mst,
> + "Enable DP MST support (1=enabled, 0=disabled, default depends on
> CONFIG_DRM_I915_DP_MST.");
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index d9a7a78..116b656 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -522,6 +522,9 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *intel_dig_port, int conn_ba
> struct drm_device *dev = intel_dig_port->base.base.dev;
> int ret;
>
> + if (i915.dp_mst == false)
> + return 0;
> +
> intel_dp->can_mst = true;
> intel_dp->mst_mgr.cbs = &mst_cbs;
>
> --
> 1.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33
https://bugs.freedesktop.org/show_bug.cgi?id=72921 --- Comment #41 from FVerrac --- Just my 2 cents: I have this bug too, on a MSI A88XM-E35 desktop mobo with latest bios 30.3 and no OC settings. I posted my bisect at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1355044/ which drives to ... I will now have to understand what I read here and see what I can decide to workaround. Thank you for the job people here. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/949ad7c0/attachment.html>
role of crtcs in modesetting interfaces and possible abstraction away from userspace
On 9 September 2014 10:43, Dave Airlie wrote: > Hi, > > So I've been attempting to hide the 30" Dell MST monitors in the > kernel, and ran into a number of problems, > but the major one is how to steal a crtc and get away with it. > > The standard scenario I have is > > CRTC 0: eDP monitor connected > > hotplug 30" monitor, userspace decides to configure things as > > CRTC 1: DP-4 - 30" monitor > CRTC 2: eDP-1 > > But since we lack atomic it does this in two steps, so when I get the > first modeset to set the 30" monitor up > I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still, > then I have to fail the second modeset, > and things end up with me crying. > > So this led me to wonder why we expose CRTCs at all, and KMS does it > because randr did it, but I've no idea > why randr did it (Keith??). > > From my POV I don't think the modesetting interface needs to take > crtcs, just connectors and modes, > so I'm wondering going forward for atomic should we even accept crtcs > in the interface, just a list of rectangles, > connectors per rectangle, etc. > > Now I'm at the point of trying to work out if I can make DP MST > monitors a possibility before we get atomic, > > Myself and Ben discussed this here and he suggested we should make the > userspace crtc ids pretty much > meaningless and not have them tied to actual hw crtcs, so we can > reroute things underneath userspace > without changing it. The only caveat we came up with is due to page_flip requiring indices we can't probably move things around as much as I'd like, I'm not sure if we have same problems further up! Dave.
role of crtcs in modesetting interfaces and possible abstraction away from userspace
On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote: > Hi, > > So I've been attempting to hide the 30" Dell MST monitors in the > kernel, and ran into a number of problems, > but the major one is how to steal a crtc and get away with it. > > The standard scenario I have is > > CRTC 0: eDP monitor connected > > hotplug 30" monitor, userspace decides to configure things as > > CRTC 1: DP-4 - 30" monitor > CRTC 2: eDP-1 > > But since we lack atomic it does this in two steps, so when I get the > first modeset to set the 30" monitor up > I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still, > then I have to fail the second modeset, > and things end up with me crying. > > So this led me to wonder why we expose CRTCs at all, and KMS does it > because randr did it, but I've no idea > why randr did it (Keith??). > > >From my POV I don't think the modesetting interface needs to take > crtcs, just connectors and modes, > so I'm wondering going forward for atomic should we even accept crtcs > in the interface, just a list of rectangles, > connectors per rectangle, etc. Not all CRTCs are created equal so the user probably wants know what features to expect from a particular CRTC. Now, often that may have something to do with the planes, but there are other hardware features that we want to expose as CRTC properties. If we make all CRTCs appear uniform to userspace the user may not know beforehand that certain features can only be used on a subset of CRTCs. Also if the driver would initially pick the wrong CRTC, and later the user would enable one of those special features, we'd have to do a full modeset to switch hardware CRTCs which would mean a nasty screen blink for the user. So no, I don't think this is a good idea given real world hardware constraints. -- Ville Syrj?l? Intel OTC
[RFC] attempting to hide 30" monitor in kernel (raw)
On Tue, Sep 09, 2014 at 04:28:05PM +1000, Dave Airlie wrote: > All these are on top of rc3 (also in my drm-mst-hide-monitor branch). > > So after talking to Keith and Daniel in Chicago I decided to give > another go at hiding the horror that is 30" 4k dual-panel MST > monitors in the kernel. > > Also this hw is not going away, if anything it seems to be getting > worse with Dell promising a 5k monitor, requiring 2 MST ports. There's also dual-channel dsi and similar stuff which is the same. At least on some platforms where you need 2 crtcs to drive both channels. > The first two patches aren't really part of this series, I should > probably put them in -fixes anyways. (i.e. ignore them) > > So this series, contains the functionality changes required to hide > tiled crtc underneath a master crtc, and to keep track of them > for modeset and pageflipping and cursors (not finished). > > It also allows EDID patching to fake the super-mode, along with > hiding the sub-connectors. > > Patch 9 is probably the biggest hack here due to lack of atomic > modesetting, and how userspace picks crtcs. > > Patch 10 is pageflip so hacky as well, and 11 is just bogus > cursor handling, I just wanted to see the cursor in some form for now. > > Mostly I'm looking for some high-level review of the concepts of this > and how much harder it'll make life going forward. So thinking about this some more I see piles of issues: - It obviously looks and works fairly badly without atomic. And it's not just the crtc stealing, but we also need to steal planes. Which isn't a problem on i915, but on SoC platforms there's often just a set of universal planes for all crtcs, and if we also want to fix the dual channel dsi mess with this those matter. - It will be a lot of work to virtualize the crtcs properly. You ducttape over the pageflip issues, but there's a lot more: We need to consistently pick the leading crtc for pageflips and timestamps since otherwise the timestamps will be all over the place. Which will upset timing applications and result in video judder. We need to virtualize all the planes which runs into all the same issues as virtualizing crtcs: We might run out of them when userspace doesn't expect it, or we might not even be able to seamlessly stitch them together over the two crtcs. E.g. older intel chips only had 1 special purpose video overlay shared between all crtcs, so you just can't virtualize that one for 2 crtcs. There's probably more I've forgotten, but in any case a proper compositor already knows how to deal with all this. Second-guessing the compositor in the kernel is imo not the right approach and will result in major design headaches going forward. So yeah this approach has a lot of appeal since faking it means existing userspace will keep on working. But I also think the troubles for non-X userspace (which actually wants to use planes properly) isn't worth it. And also for simple X compositors the illusion falls appart quickly with the crtc stealing and timestamp troubles for pageflips/vblanks. So let's look at the differnt issues with the split screen stuff again, and I think most are fairly easy to solve: - fbdev configuration: We can just move the tiling detection into the fbdev helpers and it should resolve a lot of the troubles since fbdev emulation can explicitly assign crtcs. - X initial configuration: Decent drivers (sna does it, dunno about the others) already goes to great lengths to faithfully inherit the kernel's setup. Ofc there's stupid xdm which club the driver/kernel right away with a modeset, but imo not trusting the initial setup the kernel has done is a bug. Both from a fastboot perspective and from a "users don't want to spec quirks in 3 billion different config places if kernel cmdline works well enough" pov. - X compositor real screen size detection: I guess there's no way around to add a new "real screen" rectangles on top of the Xrandr crtc rects. Either the xinerama hack or something new in Xrandr, and then also teaching all compositors about it. Xinerama might fare better since some compositors already use it. This is obviously the crux since it means we won't have nice 4/5k support from the start until compositors are all updated. But I really don't see a quick way around this. - Sharing the tile layout detection code: Imo the kernel should expose tile-id, tile-x and tile-y on connectors when they are part of a tiled screen. For dual channel dsi drivers can fill them from DT or vbt or similar. And for dp mst I think your hack is going in the right direction - if we always probe _all_ dp mst slaves on a given master dp port we should be able to fill out the tile properties correctly. Of course that means a bit excessive amounts of reprobing, but that's just a good excuse to finally have decent edid and output state caching in general. Or we just need to add an atomic probe ioctl
[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue
On Tue, Sep 9, 2014 at 3:07 AM, Tomi Valkeinen wrote: > lockdep won't complain though since you essentially open-code a workqueue_flush, and lockdep also doesn't complain about all possible deadlocks (due to some design issues with lockdep). >>> >>> What do you mean "open-code a workqueue_flush"?. I use flush_workqueue >>> there. We have two things to wait for: work on the workqueue and work >>> which is triggered by the vsync irq. So we loop and test for both of >>> those, until there's no more work. >> >> Oops, missed that. Ordering looks wrong though since if the irq can latch >> the workqueue you need to wait for irqs to happen first before flushing. >> And obviously queue the work before signalling the completion of the >> interrupt. But since this seems to lack locking anyway and is only used >> for unload it doesn't really matter. from a quick look at omap_crtc_flush(), you probably also race w/ apply worker list manipulation (like moving from queued_applies to pending_applies) > Yeah, well, the workqueue can create work for the irq also. I don't know > if it does, currently, but I think it's safer to presume that both > workqueue and the irq can create work to the other. > > But that's why I have a loop there. So we flush, then check if there is > work for the irq. If yes, sleep a bit and go back to start. So if the > irq work created new work for the wq, we flush that. And if that work > created new work for the irq, we check that again. Etc. I think adding an internal per-crtc apply_lock would solve a lot of problems. I was originally shying away from recommending that, mostly because I didn't want to think about it and I though there was an easier solution. But with an apply_lock we could at least add some locking to _flush() and make it not racy as well.. Although, I wonder if some waitqueue scheme would be a bit more sane.. ie. end of apply_worker, if there is nothing more queued up, signal the event that _flush() is waiting on. BR, -R
[PATCH 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()
Am Montag, den 08.09.2014, 12:50 -0700 schrieb Greg Kroah-Hartman: > On Tue, Jul 29, 2014 at 11:57:06AM +0200, Philipp Zabel wrote: > > For the overlay plane scanning out a framebuffer with an alpha component, > > enable the DP local alpha feature on the partial plane. > > > > Signed-off-by: Philipp Zabel > > --- > > drivers/staging/imx-drm/ipuv3-plane.c | 12 ++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > Russell, are these ok to take? Actually, no. Thanks for the reminder. There's an error in the double buffering patch. I'll send a v2. regards Philipp
[PATCH v2 4/4] imx-drm: ipuv3-plane: fix plane updates for active planes
While the DMA channel is running, it is not allowed to change anything
but the inactive (double) buffer base address, so resizing a plane or
changing to a frame buffer with different pixel format is not possible.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 15 +++
drivers/staging/imx-drm/ipuv3-plane.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index cca907f..5c65cf6 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -146,6 +146,18 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
if (crtc_h < 2)
return -EINVAL;
+ /*
+* since we cannot touch active IDMAC channels, we do not support
+* resizing the enabled plane or changing its format
+*/
+ if (ipu_plane->enabled) {
+ if (src_w != ipu_plane->w || src_h != ipu_plane->h ||
+ fb->pixel_format != ipu_plane->base.fb->pixel_format)
+ return -EINVAL;
+
+ return ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
+ }
+
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ret = ipu_dp_setup_channel(ipu_plane->dp,
@@ -206,6 +218,9 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
if (ret < 0)
return ret;
+ ipu_plane->w = src_w;
+ ipu_plane->h = src_h;
+
return 0;
}
diff --git a/drivers/staging/imx-drm/ipuv3-plane.h
b/drivers/staging/imx-drm/ipuv3-plane.h
index c0aae5b..af125fb 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.h
+++ b/drivers/staging/imx-drm/ipuv3-plane.h
@@ -26,6 +26,8 @@ struct ipu_plane {
int x;
int y;
+ int w;
+ int h;
boolenabled;
};
--
2.1.0
[PATCH v2 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()
For the overlay plane scanning out a framebuffer with an alpha component,
enable the DP local alpha feature on the partial plane.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 50de10a..43e36ea 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -151,14 +151,22 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
struct drm_crtc *crtc,
ret);
return ret;
}
- ipu_dp_set_global_alpha(ipu_plane->dp, 1, 0, 1);
+ ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
break;
case IPU_DP_FLOW_SYNC_FG:
ipu_dp_setup_channel(ipu_plane->dp,
ipu_drm_fourcc_to_colorspace(fb->pixel_format),
IPUV3_COLORSPACE_UNKNOWN);
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
- break;
+ /* Enable local alpha on partial plane */
+ switch (fb->pixel_format) {
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
+ break;
+ default:
+ break;
+ }
}
ret = ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
--
2.1.0
[PATCH v2 3/4] imx-drm: ipuv3-plane: enable double buffering
This allows to update the buffer base address while the DMA
channel is running. It is needed to flip the frame buffer of
an active plane.
Signed-off-by: Philipp Zabel
---
Change since v1:
- Added missing ipu_idmac_select_buffer call to make the hardware
double buffering actually consider the newly set buffer.
---
drivers/staging/imx-drm/ipuv3-plane.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 9f79a17..cca907f 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -65,6 +65,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
struct ipu_ch_param __iomem *cpmem;
struct drm_gem_cma_object *cma_obj;
unsigned long eba;
+ int active;
cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
if (!cma_obj) {
@@ -75,11 +76,18 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
dev_dbg(ipu_plane->base.dev->dev, "phys = %pad, x = %d, y = %d",
&cma_obj->paddr, x, y);
- cpmem = ipu_get_cpmem(ipu_plane->ipu_ch);
eba = cma_obj->paddr + fb->offsets[0] +
fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
- ipu_cpmem_set_buffer(cpmem, 0, eba);
- ipu_cpmem_set_buffer(cpmem, 1, eba);
+
+ cpmem = ipu_get_cpmem(ipu_plane->ipu_ch);
+ if (ipu_plane->enabled) {
+ active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
+ ipu_cpmem_set_buffer(cpmem, !active, eba);
+ ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
+ } else {
+ ipu_cpmem_set_buffer(cpmem, 0, eba);
+ ipu_cpmem_set_buffer(cpmem, 1, eba);
+ }
/* cache offsets for subsequent pageflips */
ipu_plane->x = x;
@@ -191,6 +199,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
return ret;
}
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
+ ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(cpmem, fb->pitches[0]);
ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
--
2.1.0
[PATCH v2 2/4] imx-drm: ipuv3-plane: move stride setting out of base setup
Setting the stride can only be done on inactive channels, while the buffer base address can also be updated for running channels using the hardware double buffering feature. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipuv3-plane.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/imx-drm/ipuv3-plane.c b/drivers/staging/imx-drm/ipuv3-plane.c index 43e36ea..9f79a17 100644 --- a/drivers/staging/imx-drm/ipuv3-plane.c +++ b/drivers/staging/imx-drm/ipuv3-plane.c @@ -76,8 +76,6 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct drm_framebuffer *fb, &cma_obj->paddr, x, y); cpmem = ipu_get_cpmem(ipu_plane->ipu_ch); - ipu_cpmem_set_stride(cpmem, fb->pitches[0]); - eba = cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x; ipu_cpmem_set_buffer(cpmem, 0, eba); @@ -193,6 +191,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct drm_crtc *crtc, return ret; } ipu_cpmem_set_high_priority(ipu_plane->ipu_ch); + ipu_cpmem_set_stride(cpmem, fb->pitches[0]); ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y); if (ret < 0) -- 2.1.0
[PATCH 1/9] drm/exynos/ipp: traverse ipp drivers list safely
On ipp subsystem removal list of ipp drivers is traversed
and their members are deleted. To do it properly safe version
of list_for_each* should be used.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 4f36a9d..00d74b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1605,11 +1605,11 @@ err:
static void ipp_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
- struct exynos_drm_ippdrv *ippdrv;
+ struct exynos_drm_ippdrv *ippdrv, *t;
struct ipp_context *ctx = get_ipp_context(dev);
/* get ipp driver entry */
- list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
+ list_for_each_entry_safe(ippdrv, t, &exynos_drm_ippdrv_list, drv_list) {
if (is_drm_iommu_supported(drm_dev))
drm_iommu_detach_device(drm_dev, ippdrv->dev);
--
1.9.1
[PATCH 2/9] drm/exynos: fix drm driver de-initialization order
Since components have their own cleanup routines calling drm_mode_config_cleanup before component_unbind_all causes errors due to double free of KMS objects. The patch fixes it by changing de-initialization order. Now it is exactly opposite to init order. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index e11c4d6..b2c710a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -136,14 +136,14 @@ static int exynos_drm_unload(struct drm_device *dev) exynos_drm_device_subdrv_remove(dev); exynos_drm_fbdev_fini(dev); - drm_vblank_cleanup(dev); drm_kms_helper_poll_fini(dev); - drm_mode_config_cleanup(dev); + component_unbind_all(dev->dev, dev); + drm_vblank_cleanup(dev); + drm_mode_config_cleanup(dev); drm_release_iommu_mapping(dev); - kfree(dev->dev_private); - component_unbind_all(dev->dev, dev); + kfree(dev->dev_private); dev->dev_private = NULL; return 0; -- 1.9.1
[PATCH 0/9] drm/exynos: initialization/deinitialization fixes
This set of patches contains fixes of initialization and deinitialization code of exynos_drm core and components. It is based on exynos-drm-next branch. Patchset has been tested on trats and universal_c210 platforms. Regards Andrzej Andrzej Hajda (9): drm/exynos/ipp: traverse ipp drivers list safely drm/exynos: fix drm driver de-initialization order drm/exynos/fbdev: fix fbdev gem object cleanup drm/exynos/fb: free exynos framebuffer on error drm/exynos/crtc: fix framebuffer reference sequence drm/exynos/dsi: unregister connector on removal drm/exynos/dpi: unregister connector and panel on removal drm/exynos/dp: unregister connector on removal drm/exynos/hdmi: unregister connector on removal drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++--- drivers/gpu/drm/exynos/exynos_drm_fb.c| 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 ++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++- 9 files changed, 30 insertions(+), 15 deletions(-) -- 1.9.1
[PATCH 3/9] drm/exynos/fbdev: fix fbdev gem object cleanup
exynos_gem_obj is used by exynos_drm_fbdev_destroy so it cannot be destroyed before calling the latter. exynos_gem_obj will be destroyed anyway by exynos_drm_fbdev_destroy->...->exynos_drm_fb_destroy. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 32e63f6..586e40d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -353,9 +353,6 @@ void exynos_drm_fbdev_fini(struct drm_device *dev) fbdev = to_exynos_fbdev(private->fb_helper); - if (fbdev->exynos_gem_obj) - exynos_drm_gem_destroy(fbdev->exynos_gem_obj); - exynos_drm_fbdev_destroy(dev, private->fb_helper); kfree(fbdev); private->fb_helper = NULL; -- 1.9.1
[PATCH 4/9] drm/exynos/fb: free exynos framebuffer on error
In case drm_framebuffer_init fails exynos_fb should be freed
before returning an error.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 65a22ca..d346d1e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -165,6 +165,7 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
ret = drm_framebuffer_init(dev, &exynos_fb->fb, &exynos_drm_fb_funcs);
if (ret) {
+ kfree(exynos_fb);
DRM_ERROR("failed to initialize framebuffer\n");
return ERR_PTR(ret);
}
--
1.9.1
[PATCH 5/9] drm/exynos/crtc: fix framebuffer reference sequence
Adding reference to framebuffer should be accompanied with removing reference to old framebuffer assigned to the plane. This patch removes following warning: [ 95.038017] WARNING: CPU: 1 PID: 3067 at drivers/gpu/drm/drm_crtc.c:5115 drm_mode_config_cleanup+0x258/0x268() [ 95.048086] Modules linked in: [ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW 3.16.0-11355-g7a6eca5-dirty #3015 [ 95.060058] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 95.067766] [] (show_stack) from [] (dump_stack+0x70/0xbc) [ 95.074953] [] (dump_stack) from [] (warn_slowpath_common+0x64/0x88) [ 95.083005] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 95.091780] [] (warn_slowpath_null) from [] (drm_mode_config_cleanup+0x258/0x268) [ 95.100983] [] (drm_mode_config_cleanup) from [] (exynos_drm_unload+0x38/0x50) [ 95.109915] [] (exynos_drm_unload) from [] (drm_dev_unregister+0x24/0x98) [ 95.118414] [] (drm_dev_unregister) from [] (drm_put_dev+0x28/0x64) [ 95.126412] [] (drm_put_dev) from [] (take_down_master+0x24/0x44) [ 95.134218] [] (take_down_master) from [] (component_del+0x8c/0xc8) [ 95.142201] [] (component_del) from [] (exynos_dsi_remove+0x18/0x2c) [ 95.150294] [] (exynos_dsi_remove) from [] (platform_drv_remove+0x18/0x1c) [ 95.158872] [] (platform_drv_remove) from [] (__device_release_driver+0x70/0xc4) [ 95.167981] [] (__device_release_driver) from [] (device_release_driver+0x20/0x2c) [ 95.177268] [] (device_release_driver) from [] (unbind_store+0x5c/0x94) [ 95.185597] [] (unbind_store) from [] (drv_attr_store+0x20/0x2c) [ 95.193323] [] (drv_attr_store) from [] (sysfs_kf_write+0x4c/0x50) [ 95.201224] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc4/0x184) [ 95.209393] [] (kernfs_fop_write) from [] (vfs_write+0xa0/0x1a8) [ 95.217111] [] (vfs_write) from [] (SyS_write+0x40/0x8c) [ 95.224146] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x48) Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index b68e58f..bde19f4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -145,10 +145,16 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode, if (ret) return ret; + /* we need to unreference current fb after replacing it with new one */ + old_fb = plane->fb; + plane->crtc = crtc; plane->fb = crtc->primary->fb; drm_framebuffer_reference(plane->fb); + if (old_fb) + drm_framebuffer_unreference(old_fb); + return 0; } -- 1.9.1
[PATCH 6/9] drm/exynos/dsi: unregister connector on removal
During component unbind connector should be unregistered.
Also DSI host should be unregistered after KMS cleanup.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 0065a5a..24741d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1441,6 +1441,9 @@ exynos_dsi_detect(struct drm_connector *connector, bool
force)
static void exynos_dsi_connector_destroy(struct drm_connector *connector)
{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+ connector->dev = NULL;
}
static struct drm_connector_funcs exynos_dsi_connector_funcs = {
@@ -1661,10 +1664,10 @@ static void exynos_dsi_unbind(struct device *dev,
struct device *master,
exynos_dsi_dpms(&exynos_dsi_display, DRM_MODE_DPMS_OFF);
- mipi_dsi_host_unregister(&dsi->dsi_host);
-
+ exynos_dsi_connector_destroy(&dsi->connector);
encoder->funcs->destroy(encoder);
- drm_connector_cleanup(&dsi->connector);
+
+ mipi_dsi_host_unregister(&dsi->dsi_host);
}
static const struct component_ops exynos_dsi_component_ops = {
--
1.9.1
[PATCH 7/9] drm/exynos/dpi: unregister connector and panel on removal
During component removal it should unregister connector and optionally detach the panel. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c index fa08f05..96c87db 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c @@ -342,8 +342,12 @@ int exynos_dpi_remove(struct device *dev) struct exynos_dpi *ctx = exynos_dpi_display.ctx; exynos_dpi_dpms(&exynos_dpi_display, DRM_MODE_DPMS_OFF); + + exynos_dpi_connector_destroy(&ctx->connector); encoder->funcs->destroy(encoder); - drm_connector_cleanup(&ctx->connector); + + if (ctx->panel) + drm_panel_detach(ctx->panel); exynos_drm_component_del(dev, EXYNOS_DEVICE_TYPE_CONNECTOR); -- 1.9.1
[PATCH 8/9] drm/exynos/dp: unregister connector on removal
During component removal driver should unregister connector.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 4f3c7eb..32716c0 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -937,6 +937,8 @@ static enum drm_connector_status exynos_dp_detect(
static void exynos_dp_connector_destroy(struct drm_connector *connector)
{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
}
static struct drm_connector_funcs exynos_dp_connector_funcs = {
@@ -1358,8 +1360,8 @@ static void exynos_dp_unbind(struct device *dev, struct
device *master,
exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
+ exynos_dp_connector_destroy(&dp->connector);
encoder->funcs->destroy(encoder);
- drm_connector_cleanup(&dp->connector);
}
static const struct component_ops exynos_dp_ops = {
--
1.9.1
[PATCH 9/9] drm/exynos/hdmi: unregister connector on removal
During component removal driver should unregister connector.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 562966d..7910fb3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1040,6 +1040,8 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
static void hdmi_connector_destroy(struct drm_connector *connector)
{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
}
static struct drm_connector_funcs hdmi_connector_funcs = {
@@ -2314,8 +2316,8 @@ static void hdmi_unbind(struct device *dev, struct device
*master, void *data)
struct drm_encoder *encoder = display->encoder;
struct hdmi_context *hdata = display->ctx;
+ hdmi_connector_destroy(&hdata->connector);
encoder->funcs->destroy(encoder);
- drm_connector_cleanup(&hdata->connector);
}
static const struct component_ops hdmi_component_ops = {
--
1.9.1
[RFC 1/3] drm/i915: remove !enabled handling from commit primary plane step
From: Gustavo Padovan
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5279b99..2ccf7c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11837,32 +11837,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_rect *src = &state->src;
int ret;
- /*
-* If the CRTC isn't enabled, we're just pinning the framebuffer,
-* updating the fb pointer, and returning without touching the
-* hardware. This allows us to later do a drmModeSetCrtc with fb=-1 to
-* turn on the display with all planes setup as desired.
-*/
- if (!crtc->enabled) {
- mutex_lock(&dev->struct_mutex);
-
- /*
-* If we already called setplane while the crtc was disabled,
-* we may have an fb pinned; unpin it.
-*/
- if (plane->fb)
- intel_unpin_fb_obj(old_obj);
-
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
-
- /* Pin and return without programming hardware */
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- mutex_unlock(&dev->struct_mutex);
-
- return ret;
- }
-
intel_crtc_wait_for_pending_flips(crtc);
/*
--
1.9.3
[RFC 3/3] drm/i915: Merge of visible and !visible paths for primary planes
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 100 ---
1 file changed, 69 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e7e7184..175a284 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11821,16 +11821,36 @@ intel_check_primary_plane(struct drm_plane *plane,
struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true, &state->visible);
+ if (ret)
+ return ret;
+
+ if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
+ DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
+ plane_name(intel_crtc->plane),
+ INTEL_INFO(dev)->num_pipes);
+ return -EINVAL;
+ }
+
+ /* no fb bound */
+ if (state->visible && !fb) {
+ DRM_ERROR("No FB bound\n");
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -11842,14 +11862,34 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_rect *src = &state->src;
- int ret;
+ int ret = 0;
intel_crtc_wait_for_pending_flips(crtc);
+ if (intel_crtc_has_pending_flip(crtc)) {
+ DRM_ERROR("pipe is still busy with an old pageflip\n");
+ return -EBUSY;
+ }
+
+ mutex_lock(&dev->struct_mutex);
+ if (plane->fb != fb) {
+ ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+ if (ret == 0)
+ i915_gem_track_fb(old_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
+ }
+ mutex_unlock(&dev->struct_mutex);
+ if (ret != 0) {
+ DRM_ERROR("pin & fence failed\n");
+ return ret;
+ }
+
/*
* If clipping results in a non-visible primary plane, we'll disable
* the primary plane. Note that this is a bit different than what
@@ -11857,33 +11897,9 @@ intel_commit_primary_plane(struct drm_plane *plane,
* because plane->fb still gets set and pinned.
*/
if (!state->visible) {
- mutex_lock(&dev->struct_mutex);
-
- /*
-* Try to pin the new fb first so that we can bail out if we
-* fail.
-*/
- if (plane->fb != fb) {
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- if (ret) {
- mutex_unlock(&dev->struct_mutex);
- return ret;
- }
- }
-
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
-
if (intel_crtc->primary_enabled)
intel_disable_primary_hw_plane(plane, crtc);
-
- if (plane->fb != fb)
- if (plane->fb)
- intel_unpin_fb_obj(old_obj);
-
- mutex_unlock(&dev->struct_mutex);
-
} else {
if (intel_crtc && intel_crtc->active &&
intel_crtc->primary_enabled) {
@@ -11903,12 +11919,34 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_disable_fbc(dev);
}
}
- ret = intel_pipe_set
[RFC 2/3] drm/i915: create intel_update_pipe_size()
From: Gustavo Padovan
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2ccf7c0..e7e7184 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2779,6 +2779,46 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc
*crtc)
return pending;
}
+static void intel_update_pipe_size(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const struct drm_display_mode *adjusted_mode;
+
+ if (!i915.fastboot)
+ return;
+
+ /*
+* Update pipe size and adjust fitter if needed: the reason for this is
+* that in compute_mode_changes we check the native mode (not the pfit
+* mode) to see if we can flip rather than do a full mode set. In the
+* fastboot case, we'll flip, but if we don't update the pipesrc and
+* pfit state, we'll end up with a big fb scanned out into the wrong
+* sized surface.
+*
+* To fix this properly, we need to hoist the checks up into
+* compute_mode_changes (or above), check the actual pfit state and
+* whether the platform allows pfit disable with pipe active, and only
+* then update the pipesrc and pfit state, even on the flip path.
+*/
+
+ adjusted_mode = &intel_crtc->config.adjusted_mode;
+
+ I915_WRITE(PIPESRC(intel_crtc->pipe),
+ ((adjusted_mode->crtc_hdisplay - 1) << 16) |
+ (adjusted_mode->crtc_vdisplay - 1));
+ if (!intel_crtc->config.pch_pfit.enabled &&
+ (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
+ I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
+ I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
+ I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
+ }
+ intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
+ intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
+}
+
static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
@@ -2821,36 +2861,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- /*
-* Update pipe size and adjust fitter if needed: the reason for this is
-* that in compute_mode_changes we check the native mode (not the pfit
-* mode) to see if we can flip rather than do a full mode set. In the
-* fastboot case, we'll flip, but if we don't update the pipesrc and
-* pfit state, we'll end up with a big fb scanned out into the wrong
-* sized surface.
-*
-* To fix this properly, we need to hoist the checks up into
-* compute_mode_changes (or above), check the actual pfit state and
-* whether the platform allows pfit disable with pipe active, and only
-* then update the pipesrc and pfit state, even on the flip path.
-*/
- if (i915.fastboot) {
- const struct drm_display_mode *adjusted_mode =
- &intel_crtc->config.adjusted_mode;
-
- I915_WRITE(PIPESRC(intel_crtc->pipe),
- ((adjusted_mode->crtc_hdisplay - 1) << 16) |
- (adjusted_mode->crtc_vdisplay - 1));
- if (!intel_crtc->config.pch_pfit.enabled &&
- (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
-intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
- I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
- I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
- I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
- }
- intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
- intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
- }
+ intel_update_pipe_size(crtc);
dev_priv->display.update_primary_plane(crtc, fb, x, y);
--
1.9.3
[PATCH] drm/radeon: reduce memory footprint for debugging
On Tue, Sep 9, 2014 at 4:14 AM, Andy Shevchenko
wrote:
> On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote:
>> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
>> wrote:
>> > There is no need to use hex_dump_to_buffer() since we have a kernel helper
>> > to
>> > dump up to 64 bytes just via printk(). In our case the actual size is 15
>> > bytes.
>> >
>> > Signed-off-by: Andy Shevchenko
>>
>> Patch generates the following warning:
>> CC [M] drivers/gpu/drm/radeon/atombios_dp.o
>> drivers/gpu/drm/radeon/atombios_dp.c: In function ?radeon_dp_getdpcd?:
>> drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: field width
>> specifier ?*? expects argument of type ?int?, but argument 3 has type
>> ?u8 *? [-Wformat=]
>>DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
>>^
>> drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: format ?%p?
>> expects argument of type ?void *?, but argument 4 has type ?int?
>> [-Wformat=]
>> LD [M] drivers/gpu/drm/radeon/radeon.o
>> Building modules, stage 2.
>> MODPOST 2485 modules
>> LD [M] drivers/gpu/drm/radeon/radeon.ko
>
> There is a patch v2.
>
> http://www.spinics.net/lists/dri-devel/msg67407.html
Thanks. Applied.
Alex
>
>>
>>
>>
>> > ---
>> > drivers/gpu/drm/radeon/atombios_dp.c | 7 ++-
>> > 1 file changed, 2 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
>> > b/drivers/gpu/drm/radeon/atombios_dp.c
>> > index 95ea276..4e75c48 100644
>> > --- a/drivers/gpu/drm/radeon/atombios_dp.c
>> > +++ b/drivers/gpu/drm/radeon/atombios_dp.c
>> > @@ -405,16 +405,13 @@ bool radeon_dp_getdpcd(struct radeon_connector
>> > *radeon_connector)
>> > u8 msg[DP_DPCD_SIZE];
>> > int ret;
>> >
>> > - char dpcd_hex_dump[DP_DPCD_SIZE * 3];
>> > -
>> > ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux,
>> > DP_DPCD_REV, msg,
>> >DP_DPCD_SIZE);
>> > if (ret > 0) {
>> > memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
>> >
>> > - hex_dump_to_buffer(dig_connector->dpcd,
>> > sizeof(dig_connector->dpcd),
>> > - 32, 1, dpcd_hex_dump,
>> > sizeof(dpcd_hex_dump), false);
>> > - DRM_DEBUG_KMS("DPCD: %s\n", dpcd_hex_dump);
>> > + DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
>> > + (int)sizeof(dig_connector->dpcd));
>> >
>> > radeon_dp_probe_oui(radeon_connector);
>> >
>> > --
>> > 2.1.0
>> >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
> Andy Shevchenko
> Intel Finland Oy
>
[PATCH 0/2] Two imx-drm oops fixes
On Tue, Sep 09, 2014 at 11:13:41PM +0800, Shawn Guo wrote: > On Mon, Sep 08, 2014 at 12:09:49PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote: > > > On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote: > > > > Greg, > > > > > > > > Here's two oops fixes for imx-drm, which I've had queued up for a number > > > > of months now. Shawn posted different fixes for the same oops recently > > > > as well. > > > > > > So do I take your patches, or Shawn's? > > > > Actually, yours are "smaller", so I'll defer to you and take yours... > > Greg, > > My patch is bigger than Russell's because I cleaned up the code a little > bit along the way of fixing the bug. > > I will send you the cleanup as an incremental patch based on Russell's > fixes. That's what you should have done in the first place, don't try to do multiple things in the same patch, especially for bugfixes that need/want to be backported, you know better than that... greg k-h
[RFC 2/3] drm/i915: create intel_update_pipe_size()
On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Factor out a piece of code from intel_pipe_set_base() that updates
> the pipe size and adjust fitter.
>
> This will help refactor the update primary plane path.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 71
> +---
> 1 file changed, 41 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2ccf7c0..e7e7184 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2779,6 +2779,46 @@ static bool intel_crtc_has_pending_flip(struct
> drm_crtc *crtc)
> return pending;
> }
>
> +static void intel_update_pipe_size(struct drm_crtc *crtc)
These days we usually prefer to pass intel_crtc instead of drm_crtc. You
can still call it 'crtc' since that's shorter and because we don't need
anything from drm_crtc in this function there won't be any confusion
between the two.
Otherwise the patch looks good.
> +{
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + const struct drm_display_mode *adjusted_mode;
> +
> + if (!i915.fastboot)
> + return;
> +
> + /*
> + * Update pipe size and adjust fitter if needed: the reason for this is
> + * that in compute_mode_changes we check the native mode (not the pfit
> + * mode) to see if we can flip rather than do a full mode set. In the
> + * fastboot case, we'll flip, but if we don't update the pipesrc and
> + * pfit state, we'll end up with a big fb scanned out into the wrong
> + * sized surface.
> + *
> + * To fix this properly, we need to hoist the checks up into
> + * compute_mode_changes (or above), check the actual pfit state and
> + * whether the platform allows pfit disable with pipe active, and only
> + * then update the pipesrc and pfit state, even on the flip path.
> + */
> +
> + adjusted_mode = &intel_crtc->config.adjusted_mode;
> +
> + I915_WRITE(PIPESRC(intel_crtc->pipe),
> +((adjusted_mode->crtc_hdisplay - 1) << 16) |
> +(adjusted_mode->crtc_vdisplay - 1));
> + if (!intel_crtc->config.pch_pfit.enabled &&
> + (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
> + I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
> + I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
> + I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
> + }
> + intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
> + intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
> +}
> +
> static int
> intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> struct drm_framebuffer *fb)
> @@ -2821,36 +2861,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int
> y,
> return ret;
> }
>
> - /*
> - * Update pipe size and adjust fitter if needed: the reason for this is
> - * that in compute_mode_changes we check the native mode (not the pfit
> - * mode) to see if we can flip rather than do a full mode set. In the
> - * fastboot case, we'll flip, but if we don't update the pipesrc and
> - * pfit state, we'll end up with a big fb scanned out into the wrong
> - * sized surface.
> - *
> - * To fix this properly, we need to hoist the checks up into
> - * compute_mode_changes (or above), check the actual pfit state and
> - * whether the platform allows pfit disable with pipe active, and only
> - * then update the pipesrc and pfit state, even on the flip path.
> - */
> - if (i915.fastboot) {
> - const struct drm_display_mode *adjusted_mode =
> - &intel_crtc->config.adjusted_mode;
> -
> - I915_WRITE(PIPESRC(intel_crtc->pipe),
> -((adjusted_mode->crtc_hdisplay - 1) << 16) |
> -(adjusted_mode->crtc_vdisplay - 1));
> - if (!intel_crtc->config.pch_pfit.enabled &&
> - (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
> - intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
> - I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
> - I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
> - I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
> - }
> - intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
> - intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
> - }
> + intel_update_pipe_size(crtc);
>
> dev_priv->display.update_primary_plane(crtc, fb, x, y);
>
> --
> 1.9.3
>
> ___
> dri-de
[RFC 1/3] drm/i915: remove !enabled handling from commit primary plane step
On Tue, Sep 09, 2014 at 11:43:19AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> The !crtc->enabled case will now be handled by the !visible code,
> since the handling is basically the same.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 --
> 1 file changed, 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5279b99..2ccf7c0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11837,32 +11837,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
> struct drm_rect *src = &state->src;
> int ret;
>
> - /*
> - * If the CRTC isn't enabled, we're just pinning the framebuffer,
> - * updating the fb pointer, and returning without touching the
> - * hardware. This allows us to later do a drmModeSetCrtc with fb=-1 to
> - * turn on the display with all planes setup as desired.
> - */
> - if (!crtc->enabled) {
> - mutex_lock(&dev->struct_mutex);
> -
> - /*
> - * If we already called setplane while the crtc was disabled,
> - * we may have an fb pinned; unpin it.
> - */
> - if (plane->fb)
> - intel_unpin_fb_obj(old_obj);
> -
> - i915_gem_track_fb(old_obj, obj,
> - INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
> -
> - /* Pin and return without programming hardware */
> - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> - mutex_unlock(&dev->struct_mutex);
> -
> - return ret;
> - }
> -
> intel_crtc_wait_for_pending_flips(crtc);
Yeah this should work just fine.
One difference between the code paths is the intel_crtc_wait_for_pending_flips()
call, but since the crtc isn't enabled there can't be any pending flip.
The other difference is the pin vs. unpin order, but that shouldn't matter
unless there's tons of other stuff pinned as well. It's not worth optimizing
setplane calls on disabled CRTCs too much IMO.
Reviewed-by: Ville Syrj?l?
>
> /*
> --
> 1.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrj?l?
Intel OTC
[PATCH] drm/radeon/dpm: set the thermal type properly for special configs
On systems with special thermal configurations make sure we make
note of the thermal setup. This is required for proper firmware
configuration on these systems.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 92b2d8d..3027e9b 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2281,19 +2281,31 @@ static void
radeon_atombios_add_pplib_thermal_controller(struct radeon_device *r
(controller->ucFanParameters &
ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
rdev->pm.int_thermal_type = THERMAL_TYPE_KV;
- } else if ((controller->ucType ==
- ATOM_PP_THERMALCONTROLLER_EXTERNAL_GPIO) ||
- (controller->ucType ==
- ATOM_PP_THERMALCONTROLLER_ADT7473_WITH_INTERNAL) ||
- (controller->ucType ==
- ATOM_PP_THERMALCONTROLLER_EMC2103_WITH_INTERNAL)) {
- DRM_INFO("Special thermal controller config\n");
+ } else if (controller->ucType ==
+ ATOM_PP_THERMALCONTROLLER_EXTERNAL_GPIO) {
+ DRM_INFO("External GPIO thermal controller %s fan
control\n",
+(controller->ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
+ rdev->pm.int_thermal_type = THERMAL_TYPE_EXTERNAL_GPIO;
+ } else if (controller->ucType ==
+ ATOM_PP_THERMALCONTROLLER_ADT7473_WITH_INTERNAL) {
+ DRM_INFO("ADT7473 with internal thermal controller %s
fan control\n",
+(controller->ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
+ rdev->pm.int_thermal_type =
THERMAL_TYPE_ADT7473_WITH_INTERNAL;
+ } else if (controller->ucType ==
+ ATOM_PP_THERMALCONTROLLER_EMC2103_WITH_INTERNAL) {
+ DRM_INFO("EMC2103 with internal thermal controller %s
fan control\n",
+(controller->ucFanParameters &
+ ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
+ rdev->pm.int_thermal_type =
THERMAL_TYPE_EMC2103_WITH_INTERNAL;
} else if (controller->ucType <
ARRAY_SIZE(pp_lib_thermal_controller_names)) {
DRM_INFO("Possible %s thermal controller at 0x%02x %s
fan control\n",
pp_lib_thermal_controller_names[controller->ucType],
controller->ucI2cAddress >> 1,
(controller->ucFanParameters &
ATOM_PP_FANPARAMETERS_NOFAN) ? "without" :
"with");
+ rdev->pm.int_thermal_type = THERMAL_TYPE_EXTERNAL;
i2c_bus = radeon_lookup_i2c_gpio(rdev,
controller->ucI2cLine);
rdev->pm.i2c_bus = radeon_i2c_lookup(rdev, &i2c_bus);
if (rdev->pm.i2c_bus) {
--
1.8.3.1
[Mesa-dev] [PATCH] drm/radeon: Add RADEON_GEM_CPU_ACCESS BO creation flag
On Mon, Sep 8, 2014 at 9:15 PM, Michel D?nzer wrote:
> On 09.09.2014 09:47, Michel D?nzer wrote:
>> On 09.09.2014 02:36, Alex Deucher wrote:
>>>
>>> Updated version with comments integrated.
>>
>> [...]
>>
>>> @@ -314,10 +314,12 @@ int radeon_bo_pin_restricted(struct radeon_bo
>>> *bo, u32 domain, u64 max_offset,
>>> unsigned lpfn = 0;
>>>
>>> /* force to pin into visible video ram */
>>> -if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
>>> -lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>>> -else
>>> +if (bo->placements[i].flags & TTM_PL_FLAG_VRAM) {
>>> +if (!(bo->flags & RADEON_GEM_NO_CPU_ACCESS))
>>> +lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
>>> +} else {
>>> lpfn = bo->rdev->mc.gtt_size >> PAGE_SHIFT; /* ??? */
>>> +}
>>
>> The else block can be removed as well, but that can be done in another
>> patch.
>
> Actually, I just noticed a problem, the following if statement:
>
>> if (max_offset)
>> lpfn = min (lpfn, (unsigned)(max_offset >>
>> PAGE_SHIFT));
>
> This will ignore max_offset if lpfn is 0. So either go with v1 of this hunk,
> or rebase on top of the patch below.
>
Rebased on your patch and attached.
Alex
>
> From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
> Date: Tue, 9 Sep 2014 10:09:23 +0900
> Subject: [PATCH] drm/radeon: Clean up assignment of TTM placement lpfn member
> for pinning
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Michel D?nzer
> ---
> drivers/gpu/drm/radeon/radeon_object.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 908ea541..8ec8150 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -307,18 +307,14 @@ int radeon_bo_pin_restricted(struct radeon_bo *bo, u32
> domain, u64 max_offset,
> }
> radeon_ttm_placement_from_domain(bo, domain);
> for (i = 0; i < bo->placement.num_placement; i++) {
> - unsigned lpfn = 0;
> -
> /* force to pin into visible video ram */
> if (bo->placements[i].flags & TTM_PL_FLAG_VRAM)
> - lpfn = bo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
> + bo->placements[i].lpfn =
> + min(bo->rdev->mc.visible_vram_size,
> max_offset)
> + >> PAGE_SHIFT;
> else
> - lpfn = bo->rdev->mc.gtt_size >> PAGE_SHIFT; /* ??? */
> -
> - if (max_offset)
> - lpfn = min (lpfn, (unsigned)(max_offset >>
> PAGE_SHIFT));
> + bo->placements[i].lpfn = max_offset >> PAGE_SHIFT;
>
> - bo->placements[i].lpfn = lpfn;
> bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
> }
>
> --
> 2.1.0
>
>
> --
> Earthling Michel D?nzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-add-RADEON_GEM_NO_CPU_ACCESS-BO-creation-.patch
Type: text/x-diff
Size: 1804 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/073b383f/attachment.patch>
[RFC 3/3] drm/i915: Merge of visible and !visible paths for primary planes
On Tue, Sep 09, 2014 at 11:43:21AM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Fold intel_pipe_set_base() in the update primary plane path merging
> pieces of code that are common to both paths.
>
> Basically the the pin/unpin procedures are the same for both paths
> and some checks can also be shared (some of the were moved to the
> check() stage)
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 100
> ---
> 1 file changed, 69 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e7e7184..175a284 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11821,16 +11821,36 @@ intel_check_primary_plane(struct drm_plane *plane,
> struct intel_plane_state *state)
> {
> struct drm_crtc *crtc = state->crtc;
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> struct drm_framebuffer *fb = state->fb;
> struct drm_rect *dest = &state->dst;
> struct drm_rect *src = &state->src;
> const struct drm_rect *clip = &state->clip;
> + int ret;
>
> - return drm_plane_helper_check_update(plane, crtc, fb,
> + ret = drm_plane_helper_check_update(plane, crtc, fb,
> src, dest, clip,
> DRM_PLANE_HELPER_NO_SCALING,
> DRM_PLANE_HELPER_NO_SCALING,
> false, true, &state->visible);
> + if (ret)
> + return ret;
> +
> + if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
> + DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
> + plane_name(intel_crtc->plane),
> + INTEL_INFO(dev)->num_pipes);
> + return -EINVAL;
> + }
I think we can just kill this plane check. It serves no purpose IMO.
> +
> + /* no fb bound */
> + if (state->visible && !fb) {
> + DRM_ERROR("No FB bound\n");
> + return -EINVAL;
> + }
Hmm. This one may be needed still in cases where the BIOS fb takeover
fails. Otherwise it shouldn't happen.
> +
> + return 0;
> }
>
> static int
> @@ -11842,14 +11862,34 @@ intel_commit_primary_plane(struct drm_plane *plane,
> struct drm_device *dev = crtc->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> + struct drm_framebuffer *old_fb = plane->fb;
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
> struct intel_plane *intel_plane = to_intel_plane(plane);
> struct drm_rect *src = &state->src;
> - int ret;
> + int ret = 0;
>
> intel_crtc_wait_for_pending_flips(crtc);
>
> + if (intel_crtc_has_pending_flip(crtc)) {
> + DRM_ERROR("pipe is still busy with an old pageflip\n");
> + return -EBUSY;
> + }
Yeah I guess we can keep this sanity check here.
> +
> + mutex_lock(&dev->struct_mutex);
> + if (plane->fb != fb) {
> + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> + if (ret == 0)
> + i915_gem_track_fb(old_obj, obj,
> + INTEL_FRONTBUFFER_PRIMARY(pipe));
> + }
> + mutex_unlock(&dev->struct_mutex);
Could move the locking within the 'if (plane->fb != fb)' block since the
lock just protects the lower level stuff and not the plane->fb pointer.
Hmm. I started to wonder if we can do the pin/unpin conditionally, but
it must be fine, otherwise we already have some kind of problem with
the pin count going astray.
I guess we could apply this small optimization to the sprite code as
well. There we currently do the pin/unpin unconditionally.
> + if (ret != 0) {
> + DRM_ERROR("pin & fence failed\n");
> + return ret;
> + }
Hmm. I wonder if this error is user triggerable on some platforms.
Should probably kill it or make it DRM_DEBUG_KMS or something.
> +
> /*
>* If clipping results in a non-visible primary plane, we'll disable
>* the primary plane. Note that this is a bit different than what
> @@ -11857,33 +11897,9 @@ intel_commit_primary_plane(struct drm_plane *plane,
>* because plane->fb still gets set and pinned.
>*/
> if (!state->visible) {
> - mutex_lock(&dev->struct_mutex);
> -
> - /*
> - * Try to pin the new fb first so that we can bail out if we
> - * fail.
> - */
> - if (plane->fb != fb) {
> - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> -
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #242 from Kajzer --- (In reply to comment #241) > (In reply to comment #239) > > echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level > > > > echo performance > /sys/class/drm/card0/device/power_dpm_state > > > This is effectively the same as disabling dpm. Hm, doesn't appear like that. The only difference I can see from the default dpm values (auto, balanced) is that I'm running 2 Celsius hotter and there are no crashes. Without dpm it's 25 Celsius hotter and that's just on idle. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/6dd350c4/attachment-0001.html>
[RFC 2/3] drm/i915: create intel_update_pipe_size()
2014-09-09 Ville Syrj?l? : > On Tue, Sep 09, 2014 at 11:43:20AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Factor out a piece of code from intel_pipe_set_base() that updates > > the pipe size and adjust fitter. > > > > This will help refactor the update primary plane path. > > > > Signed-off-by: Gustavo Padovan > > --- > > drivers/gpu/drm/i915/intel_display.c | 71 > > +--- > > 1 file changed, 41 insertions(+), 30 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 2ccf7c0..e7e7184 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -2779,6 +2779,46 @@ static bool intel_crtc_has_pending_flip(struct > > drm_crtc *crtc) > > return pending; > > } > > > > +static void intel_update_pipe_size(struct drm_crtc *crtc) > > These days we usually prefer to pass intel_crtc instead of drm_crtc. You > can still call it 'crtc' since that's shorter and because we don't need > anything from drm_crtc in this function there won't be any confusion > between the two. Actually we need the drm_crtc 3 times in this function, that is why I left it as an argument. We could just do the other way around and get it from &intel_crtc->base. Gustavo
[PATCH 1/3] drm/i915: remove !enabled handling from commit primary plane step
From: Gustavo Padovan
The !crtc->enabled case will now be handled by the !visible code,
since the handling is basically the same.
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5279b99..2ccf7c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11837,32 +11837,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_rect *src = &state->src;
int ret;
- /*
-* If the CRTC isn't enabled, we're just pinning the framebuffer,
-* updating the fb pointer, and returning without touching the
-* hardware. This allows us to later do a drmModeSetCrtc with fb=-1 to
-* turn on the display with all planes setup as desired.
-*/
- if (!crtc->enabled) {
- mutex_lock(&dev->struct_mutex);
-
- /*
-* If we already called setplane while the crtc was disabled,
-* we may have an fb pinned; unpin it.
-*/
- if (plane->fb)
- intel_unpin_fb_obj(old_obj);
-
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
-
- /* Pin and return without programming hardware */
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- mutex_unlock(&dev->struct_mutex);
-
- return ret;
- }
-
intel_crtc_wait_for_pending_flips(crtc);
/*
--
1.9.3
[PATCH 2/3] drm/i915: create intel_update_pipe_size()
From: Gustavo Padovan
Factor out a piece of code from intel_pipe_set_base() that updates
the pipe size and adjust fitter.
This will help refactor the update primary plane path.
v2: use struct intel_crtc as argument to intel_update_pipe_size()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2ccf7c0..0e03fee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2779,6 +2779,46 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc
*crtc)
return pending;
}
+static void intel_update_pipe_size(struct intel_crtc *intel_crtc)
+{
+ struct drm_crtc *crtc = &intel_crtc->base;
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const struct drm_display_mode *adjusted_mode;
+
+ if (!i915.fastboot)
+ return;
+
+ /*
+* Update pipe size and adjust fitter if needed: the reason for this is
+* that in compute_mode_changes we check the native mode (not the pfit
+* mode) to see if we can flip rather than do a full mode set. In the
+* fastboot case, we'll flip, but if we don't update the pipesrc and
+* pfit state, we'll end up with a big fb scanned out into the wrong
+* sized surface.
+*
+* To fix this properly, we need to hoist the checks up into
+* compute_mode_changes (or above), check the actual pfit state and
+* whether the platform allows pfit disable with pipe active, and only
+* then update the pipesrc and pfit state, even on the flip path.
+*/
+
+ adjusted_mode = &intel_crtc->config.adjusted_mode;
+
+ I915_WRITE(PIPESRC(intel_crtc->pipe),
+ ((adjusted_mode->crtc_hdisplay - 1) << 16) |
+ (adjusted_mode->crtc_vdisplay - 1));
+ if (!intel_crtc->config.pch_pfit.enabled &&
+ (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
+ I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
+ I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
+ I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
+ }
+ intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
+ intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
+}
+
static int
intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *fb)
@@ -2821,36 +2861,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
- /*
-* Update pipe size and adjust fitter if needed: the reason for this is
-* that in compute_mode_changes we check the native mode (not the pfit
-* mode) to see if we can flip rather than do a full mode set. In the
-* fastboot case, we'll flip, but if we don't update the pipesrc and
-* pfit state, we'll end up with a big fb scanned out into the wrong
-* sized surface.
-*
-* To fix this properly, we need to hoist the checks up into
-* compute_mode_changes (or above), check the actual pfit state and
-* whether the platform allows pfit disable with pipe active, and only
-* then update the pipesrc and pfit state, even on the flip path.
-*/
- if (i915.fastboot) {
- const struct drm_display_mode *adjusted_mode =
- &intel_crtc->config.adjusted_mode;
-
- I915_WRITE(PIPESRC(intel_crtc->pipe),
- ((adjusted_mode->crtc_hdisplay - 1) << 16) |
- (adjusted_mode->crtc_vdisplay - 1));
- if (!intel_crtc->config.pch_pfit.enabled &&
- (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
-intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
- I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
- I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
- I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
- }
- intel_crtc->config.pipe_src_w = adjusted_mode->crtc_hdisplay;
- intel_crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
- }
+ intel_update_pipe_size(intel_crtc);
dev_priv->display.update_primary_plane(crtc, fb, x, y);
--
1.9.3
[PATCH 3/3] drm/i915: Merge of visible and !visible paths for primary planes
From: Gustavo Padovan
Fold intel_pipe_set_base() in the update primary plane path merging
pieces of code that are common to both paths.
Basically the the pin/unpin procedures are the same for both paths
and some checks can also be shared (some of the were moved to the
check() stage)
v2: take Ville's comments:
- remove unecessary plane check
- move mutex lock to inside the conditional
- make the pin fail message a debug one
- add a fixme for the fastboot hack
- call intel_frontbuffer_flip() after FBC update
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 93
1 file changed, 62 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0e03fee..68d7625 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11825,12 +11825,23 @@ intel_check_primary_plane(struct drm_plane *plane,
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
+ int ret;
- return drm_plane_helper_check_update(plane, crtc, fb,
+ ret = drm_plane_helper_check_update(plane, crtc, fb,
src, dest, clip,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true, &state->visible);
+ if (ret)
+ return ret;
+
+ /* no fb bound */
+ if (state->visible && !fb) {
+ DRM_ERROR("No FB bound\n");
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -11842,14 +11853,34 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_rect *src = &state->src;
- int ret;
+ int ret = 0;
intel_crtc_wait_for_pending_flips(crtc);
+ if (intel_crtc_has_pending_flip(crtc)) {
+ DRM_ERROR("pipe is still busy with an old pageflip\n");
+ return -EBUSY;
+ }
+
+ if (plane->fb != fb) {
+ mutex_lock(&dev->struct_mutex);
+ ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+ if (ret == 0)
+ i915_gem_track_fb(old_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
+ mutex_unlock(&dev->struct_mutex);
+ }
+ if (ret != 0) {
+ DRM_DEBUG_KMS("pin & fence failed\n");
+ return ret;
+ }
+
/*
* If clipping results in a non-visible primary plane, we'll disable
* the primary plane. Note that this is a bit different than what
@@ -11857,33 +11888,9 @@ intel_commit_primary_plane(struct drm_plane *plane,
* because plane->fb still gets set and pinned.
*/
if (!state->visible) {
- mutex_lock(&dev->struct_mutex);
-
- /*
-* Try to pin the new fb first so that we can bail out if we
-* fail.
-*/
- if (plane->fb != fb) {
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- if (ret) {
- mutex_unlock(&dev->struct_mutex);
- return ret;
- }
- }
-
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe));
-
if (intel_crtc->primary_enabled)
intel_disable_primary_hw_plane(plane, crtc);
-
- if (plane->fb != fb)
- if (plane->fb)
- intel_unpin_fb_obj(old_obj);
-
- mutex_unlock(&dev->struct_mutex);
-
} else {
if (intel_crtc && intel_crtc->active &&
intel_crtc->primary_enabled) {
@@ -11903,12 +11910,36 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_disable_fbc(dev);
}
}
- ret = intel_pipe_set_base(crtc, src->x1, src->y1, fb);
- if (ret)
- return ret;
- if (!intel_crtc->primary_enabled)
- intel_enable_primary_hw_plane(plane, crtc);
+ /* FIXME: kill this fastboot ha
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 Tom Stellard changed: What|Removed |Added Attachment #98257|0 |1 is obsolete|| Attachment #104448|0 |1 is obsolete|| --- Comment #87 from Tom Stellard --- Created attachment 106006 --> https://bugs.freedesktop.org/attachment.cgi?id=106006&action=edit Fix v3 Thanks for tracking down the bug with v2. Can you try this patch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/646d2612/attachment.html>
[Bug 83221] laptop hangs after loading nouveau fails, pm_runtime_work thread dying
https://bugzilla.kernel.org/show_bug.cgi?id=83221 Karol Herbst changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #3 from Karol Herbst --- seems to be fixed with rc4 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915: pin sprite fb only if it changed
From: Gustavo Padovan
Optimize code avoiding helding dev mutex if old fb and current fb
are the same.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_sprite.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index a4306cf..a301838 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1038,21 +1038,23 @@ intel_commit_sprite_plane(struct drm_plane *plane,
primary_enabled = !drm_rect_equals(dst, clip) ||
colorkey_enabled(intel_plane);
WARN_ON(!primary_enabled && !state->visible && intel_crtc->active);
- mutex_lock(&dev->struct_mutex);
/* Note that this will apply the VT-d workaround for scanouts,
* which is more restrictive than required for sprites. (The
* primary plane requires 256KiB alignment with 64 PTE padding,
* the sprite planes only require 128KiB alignment and 32 PTE padding.
*/
- ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
+ if (old_obj != obj) {
+ mutex_lock(&dev->struct_mutex);
+ ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
- i915_gem_track_fb(old_obj, obj,
- INTEL_FRONTBUFFER_SPRITE(pipe));
- mutex_unlock(&dev->struct_mutex);
+ i915_gem_track_fb(old_obj, obj,
+ INTEL_FRONTBUFFER_SPRITE(pipe));
+ mutex_unlock(&dev->struct_mutex);
- if (ret)
- return ret;
+ if (ret)
+ return ret;
+ }
intel_plane->crtc_x = state->orig_dst.x1;
intel_plane->crtc_y = state->orig_dst.y1;
@@ -1098,15 +1100,18 @@ intel_commit_sprite_plane(struct drm_plane *plane,
intel_post_enable_primary(crtc);
}
+ if (!old_obj)
+ return 0;
+
/* Unpin old obj after new one is active to avoid ugliness */
- if (old_obj) {
+ if (old_obj != obj) {
/*
* It's fairly common to simply update the position of
* an existing object. In that case, we don't need to
* wait for vblank to avoid ugliness, we only need to
* do the pin & ref bookkeeping.
*/
- if (old_obj != obj && intel_crtc->active)
+ if (intel_crtc->active)
intel_wait_for_vblank(dev, intel_crtc->pipe);
mutex_lock(&dev->struct_mutex);
--
1.9.3
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #88 from madcatx at atlas.cz --- Is this patch supposed to apply cleanly against mesa 10.1.5? I'm getting the following build error: In file included from ../../../../src/gallium/auxiliary/util/u_inlines.h:41:0, from ../../../../src/gallium/auxiliary/pipebuffer/pb_buffer.h:49, from ../../winsys/radeon/drm/radeon_winsys.h:43, from si_pm4.h:30, from si_state.h:30, from si_pipe.h:29, from si_state.c:27: si_state.c: In function 'si_init_config': si_state.c:3291:49: error: 'struct radeon_info' has no member named 'max_sh_per_se' unsigned sh_per_se = MAX2(sctx->screen->b.info.max_sh_per_se, 1); ^ ../../../../src/gallium/auxiliary/util/u_math.h:767:27: note: in definition of macro 'MAX2' #define MAX2( A, B ) ( (A)>(B) ? (A) : (B) ) ^ si_state.c:3291:49: error: 'struct radeon_info' has no member named 'max_sh_per_se' unsigned sh_per_se = MAX2(sctx->screen->b.info.max_sh_per_se, 1); ^ ../../../../src/gallium/auxiliary/util/u_math.h:767:37: note: in definition of macro 'MAX2' #define MAX2( A, B ) ( (A)>(B) ? (A) : (B) ) ^ si_state.c:3292:46: error: 'struct radeon_info' has no member named 'max_sh_per_se' unsigned num_se = MAX2(sctx->screen->b.info.max_sh_per_se, 1); ^ ../../../../src/gallium/auxiliary/util/u_math.h:767:27: note: in definition of macro 'MAX2' #define MAX2( A, B ) ( (A)>(B) ? (A) : (B) ) ^ si_state.c:3292:46: error: 'struct radeon_info' has no member named 'max_sh_per_se' unsigned num_se = MAX2(sctx->screen->b.info.max_sh_per_se, 1); ^ ../../../../src/gallium/auxiliary/util/u_math.h:767:37: note: in definition of macro 'MAX2' #define MAX2( A, B ) ( (A)>(B) ? (A) : (B) ) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/80f24f76/attachment.html>
[Bug 82828] Regression: Crash in 3Dmark2001
https://bugs.freedesktop.org/show_bug.cgi?id=82828 --- Comment #21 from Connor Abbott --- FYI, I posted the fix I attached as http://lists.freedesktop.org/archives/mesa-dev/2014-September/067343.html and a few other patches that cleanup things I noticed when fixing this, but I don't have commit access so I'm waiting for someone to push the series before I close this issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/a1403aa9/attachment.html>
role of crtcs in modesetting interfaces and possible abstraction away from userspace
On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrj?l? wrote: > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote: >> Hi, >> >> So I've been attempting to hide the 30" Dell MST monitors in the >> kernel, and ran into a number of problems, >> but the major one is how to steal a crtc and get away with it. >> >> The standard scenario I have is >> >> CRTC 0: eDP monitor connected >> >> hotplug 30" monitor, userspace decides to configure things as >> >> CRTC 1: DP-4 - 30" monitor >> CRTC 2: eDP-1 >> >> But since we lack atomic it does this in two steps, so when I get the >> first modeset to set the 30" monitor up >> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still, >> then I have to fail the second modeset, >> and things end up with me crying. >> >> So this led me to wonder why we expose CRTCs at all, and KMS does it >> because randr did it, but I've no idea >> why randr did it (Keith??). >> >> >From my POV I don't think the modesetting interface needs to take >> crtcs, just connectors and modes, >> so I'm wondering going forward for atomic should we even accept crtcs >> in the interface, just a list of rectangles, >> connectors per rectangle, etc. > > Not all CRTCs are created equal so the user probably wants know what > features to expect from a particular CRTC. Now, often that may have > something to do with the planes, but there are other hardware features > that we want to expose as CRTC properties. If we make all CRTCs appear > uniform to userspace the user may not know beforehand that certain > features can only be used on a subset of CRTCs. Also if the driver > would initially pick the wrong CRTC, and later the user would enable > one of those special features, we'd have to do a full modeset to switch > hardware CRTCs which would mean a nasty screen blink for the user. first off, I tend to think with the trend towards various different wayland compositors doing kms directly, making it easier for userspace sounds pretty attractive. Ie. would you rather fix a bug w/ picking the right crtc for the job in N compositors, or 1 kernel driver? But that said, it seems like the real problem w/ kernel picking the right crtc is going to be with non-atomic modeset. And for pre-atomic (future legacy) xrandr, I'm not entirely sure how userspace is supposed to do a better job at this than the kernel could. It would also need up front knowledge of all the modes that would be picked. So you've just pushed non-atomic suck in the kernel to non-atomic suck in x11. Doesn't sound like that fixes anything. But, I think there is maybe a way to have our cake and eat it too.. to leave extra flexibility for highly customized/specialized userspace, we could just allow for some PICK_ANY_CRTC_FOR_ME type value which would let 99% of userspace push the decision to the kernel, while still allowing for the special cases where userspace knows better. BR, -R > So no, I don't think this is a good idea given real world hardware > constraints. > > -- > Ville Syrj?l? > Intel OTC > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #243 from Kajzer --- I mean, sure, it's not dynamic and it runs on max, but Ill take it. It is what it is, on auto it freezes, theres not much I can do about it. This way I can switch manually from high to low when needed, yeah its a pain but at least it's working without crashes. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/683046e9/attachment.html>
[PATCH] drm/radeon: reduce memory footprint for debugging
On Mon, 2014-09-08 at 18:28 -0400, Alex Deucher wrote:
> On Thu, Sep 4, 2014 at 8:44 AM, Andy Shevchenko
> wrote:
> > There is no need to use hex_dump_to_buffer() since we have a kernel helper
> > to
> > dump up to 64 bytes just via printk(). In our case the actual size is 15
> > bytes.
> >
> > Signed-off-by: Andy Shevchenko
>
> Patch generates the following warning:
> CC [M] drivers/gpu/drm/radeon/atombios_dp.o
> drivers/gpu/drm/radeon/atombios_dp.c: In function ?radeon_dp_getdpcd?:
> drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: field width
> specifier ?*? expects argument of type ?int?, but argument 3 has type
> ?u8 *? [-Wformat=]
>DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
>^
> drivers/gpu/drm/radeon/atombios_dp.c:413:3: warning: format ?%p?
> expects argument of type ?void *?, but argument 4 has type ?int?
> [-Wformat=]
> LD [M] drivers/gpu/drm/radeon/radeon.o
> Building modules, stage 2.
> MODPOST 2485 modules
> LD [M] drivers/gpu/drm/radeon/radeon.ko
There is a patch v2.
http://www.spinics.net/lists/dri-devel/msg67407.html
>
>
>
> > ---
> > drivers/gpu/drm/radeon/atombios_dp.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> > b/drivers/gpu/drm/radeon/atombios_dp.c
> > index 95ea276..4e75c48 100644
> > --- a/drivers/gpu/drm/radeon/atombios_dp.c
> > +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> > @@ -405,16 +405,13 @@ bool radeon_dp_getdpcd(struct radeon_connector
> > *radeon_connector)
> > u8 msg[DP_DPCD_SIZE];
> > int ret;
> >
> > - char dpcd_hex_dump[DP_DPCD_SIZE * 3];
> > -
> > ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux,
> > DP_DPCD_REV, msg,
> >DP_DPCD_SIZE);
> > if (ret > 0) {
> > memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
> >
> > - hex_dump_to_buffer(dig_connector->dpcd,
> > sizeof(dig_connector->dpcd),
> > - 32, 1, dpcd_hex_dump,
> > sizeof(dpcd_hex_dump), false);
> > - DRM_DEBUG_KMS("DPCD: %s\n", dpcd_hex_dump);
> > + DRM_DEBUG_KMS("DPCD: %*ph\n", dig_connector->dpcd,
> > + (int)sizeof(dig_connector->dpcd));
> >
> > radeon_dp_probe_oui(radeon_connector);
> >
> > --
> > 2.1.0
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Andy Shevchenko
Intel Finland Oy
[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue
On 09/09/14 13:43, Rob Clark wrote: > Although, I wonder if some waitqueue scheme would be a bit more sane.. > ie. end of apply_worker, if there is nothing more queued up, signal > the event that _flush() is waiting on. Maybe, but we would still need either the separate apply_lock, or unlock the crtc->mutex to allow the workqueue to run. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/5b7ff192/attachment.sig>
[PATCH 0/2] Two imx-drm oops fixes
On Mon, Sep 08, 2014 at 12:09:49PM -0700, Greg Kroah-Hartman wrote: > On Mon, Sep 08, 2014 at 12:08:59PM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 01, 2014 at 06:07:12PM +0100, Russell King - ARM Linux wrote: > > > Greg, > > > > > > Here's two oops fixes for imx-drm, which I've had queued up for a number > > > of months now. Shawn posted different fixes for the same oops recently > > > as well. > > > > So do I take your patches, or Shawn's? > > Actually, yours are "smaller", so I'll defer to you and take yours... Greg, My patch is bigger than Russell's because I cleaned up the code a little bit along the way of fixing the bug. I will send you the cleanup as an incremental patch based on Russell's fixes. Shawn
[PATCH 7/9] drm/omap: fix omap_crtc_flush() to handle the workqueue
On 08/09/14 16:31, Daniel Vetter wrote: > On Mon, Sep 08, 2014 at 04:03:18PM +0300, Tomi Valkeinen wrote: >> On 03/09/14 17:27, Daniel Vetter wrote: >>> On Wed, Sep 03, 2014 at 02:55:08PM +0300, Tomi Valkeinen wrote: >>>> omap_crtc_flush() is used to wait for scheduled work to be done for the >>>> give crtc. However, it's not quite right at the moment. >>>> >>>> omap_crtc_flush() does wait for work that is ran via vsync irq to be >>>> done. However, work is also queued to the driver's priv->wq workqueue, >>>> which is not handled by omap_crtc_flush(). >>>> >>>> Improve omap_crtc_flush() to flush the workqueue so that work there will >>>> be ran. >>>> >>>> This fixes a race issue on module unload, where an unpin work may be on >>>> the work queue, but does not get ran before drm core starts tearing the >>>> driver down, leading to a WARN. >>>> >>>> Signed-off-by: Tomi Valkeinen >>> >>> I didn't really dig into details, but isn't that the same workqueue as >>> used by the async modeset code? So the same deadlocks might happen ... >> >> Yes, we have just one workqueue in the driver. >> >> Hmm, deadlocks with what lock? The modeconfig or crtc->mutex? I don't >> think they are locked at any place where omap_crtc_flush is called. > > Oh, I presumed you're using _flush in the relevant modeset functions - we No. That's the locking issue again. We can't flush when holding the crtc mutex, as the works in the workqueue also try to grab it... > do that in i915 to make sure that all the pageflips and other stuff > completed before we do another modeset. But omap only calls this at driver > unload, so no direct problem. At the moment yes, but in this series I add the same omap_crtc_flush() call to two new places: dev_preclose and omap_crtc_commit. Of which the omap_crtc_commit is the problematic one, discussed in the mail thread for patch 4. >>> lockdep won't complain though since you essentially open-code a >>> workqueue_flush, and lockdep also doesn't complain about all possible >>> deadlocks (due to some design issues with lockdep). >> >> What do you mean "open-code a workqueue_flush"?. I use flush_workqueue >> there. We have two things to wait for: work on the workqueue and work >> which is triggered by the vsync irq. So we loop and test for both of >> those, until there's no more work. > > Oops, missed that. Ordering looks wrong though since if the irq can latch > the workqueue you need to wait for irqs to happen first before flushing. > And obviously queue the work before signalling the completion of the > interrupt. But since this seems to lack locking anyway and is only used > for unload it doesn't really matter. Yeah, well, the workqueue can create work for the irq also. I don't know if it does, currently, but I think it's safer to presume that both workqueue and the irq can create work to the other. But that's why I have a loop there. So we flush, then check if there is work for the irq. If yes, sleep a bit and go back to start. So if the irq work created new work for the wq, we flush that. And if that work created new work for the irq, we check that again. Etc. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140909/0ef9ea4d/attachment.sig>
[PATCH v2 5/8] ARM: dts: am33xx: Add external clock provider
On 09/09/2014 02:30 AM, Tony Lindgren wrote:
> * Jyri Sarha [140818 14:49]:
>> Add external clock provider for am33xx devices.
>
> Please send all the .dts and defconfig changes separately
> so I can pick them up and we don't get pointless merge
> conflicts.
Moreover, this patch is obsolete now, given I have posted this:
http://www.spinics.net/lists/arm-kernel/msg355992.html
There will be v2 of my patch coming in though this week, but the
functionality will be the same.
-Tero
>
> Regards,
>
> TOny
>
>> Signed-off-by: Jyri Sarha
>> ---
>> arch/arm/boot/dts/am33xx.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index 3a0a161..d2cc397 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -92,6 +92,16 @@
>> pinctrl-single,function-mask = <0x7f>;
>> };
>>
>> +ext_clocks {
>> +compatible = "ti,external-clocks";
>> +
>> +ext_clocks: clocks {
>> +};
>> +
>> +ext_clockdomains: clockdomains {
>> +};
>> +};
>> +
>> /*
>> * XXX: Use a flat representation of the AM33XX interconnect.
>> * The real AM33XX interconnect network is quite complex. Since
>> --
>> 1.7.9.5
>>
[PATCH v5 00/11] drm: add support for Atmel HLCDC Display Controller
I used this patch to add LCD support on our SBC-SAMA5d36 with a mainline kernel and it works properly. I used fb-test to test the framebuffer and I tested the DRI device with modetest and I can set a mode and set planes. Tested-by: Anthony Harivel -Original Message- From: Boris BREZILLON [mailto:boris.brezil...@free-electrons.com] Sent: Monday, September 08, 2014 10:44 AM To: David Airlie; dri-devel at lists.freedesktop.org; Samuel Ortiz; Lee Jones; Thierry Reding; linux-pwm at vger.kernel.org; Nicolas Ferre; Jean-Christophe Plagniol-Villard; Alexandre Belloni; Andrew Victor Cc: Laurent Pinchart; Bo Shen; Ludovic Desroches; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; devicetree at vger.kernel.org; Boris BREZILLON Subject: [PATCH v5 00/11] drm: add support for Atmel HLCDC Display Controller Hello, This patch series adds support for Atmel HLCDC (HLCD Controller) available on some Atmel SoCs (i.e. the sama5d3 family). The HLCDC actually provides a Display Controller and a PWM device, hence I decided to declare an MFD device exposing 2 subdevices: a display controller and a PWM chip. This also solves a circular dependency issue preventing HLCDC driver from unloading. The HLCDC request a drm_panel device, which request a backlight device (a PWM backlight), which depends on a PWM which is provided by the HLCDC driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)). The current implementation only supports sama5d3 SoCs but other SoCs should be easily ported by defining new compatible strings and adding HLCDC description structures for these SoCs (Ludovic tested this driver on an at91sam9x5 board). The drivers supports basic CRTC functionalities, several overlays and an hardware cursor. At the moment, it only supports connection to LCD panels through an RGB connector (defined as an LVDS connector in my implementation), though connection to other kind of devices (like DRM bridges) could be added later. It also supports several RGB formats on all planes and some YUV formats on the HEO overlay plane. This series depends those series: [1] and [2]. I know you're all quite busy, but I was expecting to get support for atmel's HLCDC block in 3.18, and given the lack of review I got on the DRM and PWM parts I doubt it can happen :-(. Moreover, the dependencies ([1] and [2]) are stuck too. The first one has been reviewed by Rob, but didn't get any feedback after that. David, Rob, is there anything blocking this series ? The second patch series contains some rework I've done to describe the transfer format used on a connector bus. Laurent, Thierry, you're the one who suggested this rework. Could you give your opinion on my implementation ? Best Regards, Boris [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html [2]http://www.spinics.net/lists/kernel/msg1791681.html Changes since v4: - fix a few more bugs in rotation handling (rotation was buggy on some formats) - return connector_status_unknown until a panel is exposed by the drm_panel infrastructure (prevent fbdev creation until everyting is in place) - rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration (automatically select this option when selecting the HLCDC PMW or DRM driver, instead of depending on this option) Changes since v3: - rework the layer code to simplify several parts (locking and layer disabling) - make use of the drm_flip_work infrastructure - rely on default HW cursor implementation using on the cursor plane - rework the display controller DT bindings (based on OF graph representation) - add rotation support - retrive RGB bus format from drm_display_info - drop the dynamic pinctrl state selection - rework HLCDC output handling (previously specialized to interface with LCD panels) - drop ".module = THIS_MODULE" lines - change display controller compatible string Changes since v2: - fix coding style issues (macro indentation) - make use of GENMASK in several places - declare regmap config as a static structure - rework hlcdc plane update API - rework cursor handling to make use of the new plane update API - fix backporch config - do not use devm_regmap_init_mmio_clk to avoid extra clk_enable clk disable calls when accessing registers - explicitely include regmap and clk headers instead of relying on atmel-hlcdc.h inclusions - make the atmel-hlcdc driver depends on CONFIG_OF - separate DT bindings documentation from driver implementation - support several pin muxing for HLCDC pins on sama5d3 SoCs Changes since v1: - replace the backlight driver by a PWM driver - make use of drm_panel infrastructure - split driver code in several subsystem: MFD, PWM and DRM - add support for overlays - add support for hardware cursor Boris BREZILLON (11): mfd: add atmel-hlcdc driver mfd: add documentation for atmel-hlcdc DT bindings pwm: add support for atmel-hlcdc-pwm device pwm: add DT bindings documentation for atmel-hlcdc-pwm driver drm: a
3.7+ kernels and Radeon HD 4250 backlight
Hi!
There is a notebook eMashines e442 142G25Mikk Model PEW86 with a video
card Radeon HD 4250. Since a kernel 3.7.10 (tested until 3.16.1) it
have a problem: screen is a white (not black) when PC is idle. A
changes causing problem is:
--- linux-3.6.11/drivers/gpu/drm/radeon/radeon_encoders.c
2012-10-01 03:47:46.0 +0400
+++ linux-3.7.10/dribers/gpu/drm/radeon/radeon_encoders.c
2012-12-11 07:30:57.0 +0400
@@ -153,6 +161,7 @@
void
radeon_link_encoder_connector(struct drm_device *dev)
{
+ struct radeon_device *rdev = dev->dev_private;
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
struct drm_encoder *encoder;
@@ -163,8 +172,16 @@
radeon_connector = to_radeon_connector(connector);
list_for_each_entry(encoder,
&dev->mode_config.encoder_list, head) {
radeon_encoder = to_radeon_encoder(encoder);
- if (radeon_encoder->devices & radeon_connector->devices)
+ if (radeon_encoder->devices &
radeon_connector->devices) {
drm_mode_connector_attach_encoder(connector, encoder);
+ if (radeon_encoder->devices &
(ATOM_DEVICE_LCD_SUPPORT)) {
+ if (rdev->is_atom_bios)
+
radeon_atom_backlight_init(radeon_encoder, connector);
+ else
+
radeon_legacy_backlight_init(radeon_encoder, connector);
+ rdev->mode_info.bl_encoder =
radeon_encoder;
+ }
+ }
}
}
}
bios is atom. But radeon_atom_backlight_init() do something wrong (I think).
Thanks for any suggestions.
role of crtcs in modesetting interfaces and possible abstraction away from userspace
On 09/08/2014 11:37 PM, Keith Packard wrote: > With atomic mode setting in the kernel, I think you're probably right in > proposing to eliminate explicit CRTC allocation from that. I do think > you'll want to indicate the number of available CRTCs in the display > engine, and the number of CRTCs each monitor consumes. Do you know if > there are some of these monitors that can display lower resolution modes > with only a single CRTC? Or is the hardware so separate that you end up > always using multiple CRTCs to drive them? The one I tried definitely can; indeed it has to because the VBIOS doesn't know how to set up MST and drives the port in DP 1.1 mode. I'm sure someone will build a monitor that only turns on half of the display if you do that, but I'd be kind of surprised if someone made one that just doesn't work if you use a DP 1.1-only GPU. -- Aaron
