[PULL] drm-intel-next
On 21 October 2014 23:38, Daniel Vetter wrote: > Hi Dave, > > drm-intel-next-2014-10-03: > - first batch of skl stage 1 enabling > - fixes from Rodrigo to the PSR, fbc and sink crc code > - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic > interrupt enable/disable functions > - smaller stuff all over > drm-intel-next-2014-09-19: > - bunch more i830M fixes from Ville > - full ppgtt now again enabled by default > - more ppgtt fixes from Michel Thierry and Chris Wilson > - plane config work from Gustavo Padovan > - spinlock clarifications > - piles of smaller improvements all over, as usual Chris made some noises about PPGTT being broken somewhere on irc last week, Chris, did you figure that out? Dave.
order 5 memory allocation failures in radeon_vm_get_bos
> Mhm fixing this using another allocator function is probably a good idea, > but on the other hand why does X want to allocate an order 4/5 in vm_get_bos > in the first place? > > Assuming 64 bytes per array element that would mean that we have over 1K BOs > for the address space handling. Even with the lowest settings on BO size > that covers something like 4GB of GPU address space and with normal settings > it is more something like 256GB... > > So question here is why does X need so much GPU address space? The box > doesn't even have so much memory, doesn't it? The user I'm seeing it with us using glamor and I think he is using Xv a lot, and has a lot of stuff open on his desktop and does a lot of gimp and video editing. I've gotten him a non-crashing glamor now (pre-Xserver glamor on F20) and he only sees the alloc failures now. Dave.
[git pull] drm fixes
Hi Linus, intel, nouveau, radeon and qxl, mostly for bugs introduced in the merge window, nothing too shocking. Dave. The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to c572aaf46f71f63ae5914d4e194a955e0ba1b519: qxl: don't create too large primary surface (2014-10-22 11:11:50 +1000) Alex Deucher (6): Revert "drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table" Revert "drm/radeon/dpm: drop clk/voltage dependency filters for SI" drm/radeon: initialize sadb to NULL in the audio code drm/radeon: fix speaker allocation setup drm/radeon: use gart memory for DMA ring tests drm/radeon: fix vm page table block size calculation Ben Skeggs (2): drm/gt215/gr: fix initialisation on gddr5 boards drm/nouveau: fix regression on agp boards Dave Airlie (3): Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-next-fixes-2014-10-17' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes Jani Nikula (1): drm/i915: fix short vs. long hpd detection Marc-Andr? Lureau (1): qxl: don't create too large primary surface Michel D?nzer (2): drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat drm/ttm: Don't evict BOs outside of the requested placement range Michele Curti (1): drm/radeon: reduce sparse false positive warnings Paulo Zanoni (1): drm/i915: properly reenable gen8 pipe IRQs U. Artie Eoff (2): drm/i915: intel_backlight scale() math WA drm/i915: Move DIV_ROUND_CLOSEST_ULL macro to header Ville Syrj?l? (1): drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV drivers/gpu/drm/i915/i915_irq.c| 19 ++-- drivers/gpu/drm/i915/intel_display.c | 36 +- drivers/gpu/drm/i915/intel_drv.h | 3 ++ drivers/gpu/drm/i915/intel_panel.c | 5 ++- .../gpu/drm/nouveau/core/engine/graph/ctxnv50.c| 10 -- drivers/gpu/drm/nouveau/nouveau_chan.c | 12 ++-- drivers/gpu/drm/qxl/qxl_display.c | 16 +- drivers/gpu/drm/radeon/btc_dpm.c | 18 +++ drivers/gpu/drm/radeon/btc_dpm.h | 2 ++ drivers/gpu/drm/radeon/ci_dpm.c| 1 + drivers/gpu/drm/radeon/cik_sdma.c | 21 +++-- drivers/gpu/drm/radeon/cypress_dpm.c | 1 + drivers/gpu/drm/radeon/dce3_1_afmt.c | 6 ++-- drivers/gpu/drm/radeon/dce6_afmt.c | 8 ++--- drivers/gpu/drm/radeon/evergreen_hdmi.c| 8 ++--- drivers/gpu/drm/radeon/ni_dpm.c| 1 + drivers/gpu/drm/radeon/r600_dma.c | 21 +++-- drivers/gpu/drm/radeon/r600_dpm.c | 1 + drivers/gpu/drm/radeon/radeon.h| 2 ++ drivers/gpu/drm/radeon/radeon_device.c | 2 +- drivers/gpu/drm/radeon/rs780_dpm.c | 1 + drivers/gpu/drm/radeon/rv6xx_dpm.c | 1 + drivers/gpu/drm/radeon/rv770_dpm.c | 1 + drivers/gpu/drm/radeon/si_dpm.c| 25 +++ drivers/gpu/drm/radeon/sumo_dpm.c | 1 + drivers/gpu/drm/radeon/trinity_dpm.c | 1 + drivers/gpu/drm/ttm/ttm_bo.c | 28 - 27 files changed, 174 insertions(+), 77 deletions(-)
[PATCH] drm/mode: document path property and function to set it.
From: Dave Airlie
These two didn't get documented properly, do so.
Pointed out by Daniel.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 9 -
drivers/gpu/drm/drm_crtc.c | 10 ++
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index bacefc5..0a5cbbb 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2509,7 +2509,7 @@ void intel_crt_init(struct drm_device *dev)
DRM
- Generic
+ Generic
?EDID?
BLOB | IMMUTABLE
0
@@ -2524,6 +2524,13 @@ void intel_crt_init(struct drm_device *dev)
Contains DPMS operation mode value.
+ ?PATH?
+ BLOB | IMMUTABLE
+ 0
+ Connector
+ Contains topology path to a connector.
+
+
Plane
?type?
ENUM | IMMUTABLE
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 90e7730..363301c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3980,6 +3980,16 @@ done:
return ret;
}
+/**
+ * drm_mode_connector_set_path_property - set tile property on connector
+ * @connector: connector to set property on.
+ * @path: path to use for property.
+ *
+ * This creates a property to expose to userspace to specify a
+ * connector path. This is mainly used for DisplayPort MST where
+ * connectors have a topology and we want to allow userspace to give
+ * them more meaningful names.
+ */
int drm_mode_connector_set_path_property(struct drm_connector *connector,
char *path)
{
--
2.1.0
[PATCH 2/6] drm: add tile_group support.
> Don't you need a kref_get_unless_zero here since we only destroy the idr > entry after the refcount dropped to zero? Or is there some magic thing > that prevents this like another mutex (in which case some mutex assert in > get/put would be good)? This does all happen under mode_config.mutex but I think I'd rather use get_unless_zero. > > And kerneldoc for the non-exported functions please, preferrably with some > overview DOC: section to pull it all together. I'm posting v2, advice on kerneldoc required, so the functions end up in the right place, I don't really wnat to add a new C file for this. Dave.
tile group support (v2)
This is just a second round of the previous series, cleaned up the problems pointed out (except property hotplug - bigger problem), Dave.
[PATCH 1/6] drm/displayid: add displayid defines and edid extension (v2)
From: Dave Airlie
These are just taken from the DisplayID v1.3 spec, and the
DDC spec.
v2: use __packed (Jani)
Signed-off-by: Dave Airlie
---
include/drm/drm_displayid.h | 76 +
include/drm/drm_edid.h | 2 ++
2 files changed, 78 insertions(+)
create mode 100644 include/drm/drm_displayid.h
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
new file mode 100644
index 000..623b4e9
--- /dev/null
+++ b/include/drm/drm_displayid.h
@@ -0,0 +1,76 @@
+/*
+ * Copyright ? 2014 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#ifndef DRM_DISPLAYID_H
+#define DRM_DISPLAYID_H
+
+#define DATA_BLOCK_PRODUCT_ID 0x00
+#define DATA_BLOCK_DISPLAY_PARAMETERS 0x01
+#define DATA_BLOCK_COLOR_CHARACTERISTICS 0x02
+#define DATA_BLOCK_TYPE_1_DETAILED_TIMING 0x03
+#define DATA_BLOCK_TYPE_2_DETAILED_TIMING 0x04
+#define DATA_BLOCK_TYPE_3_SHORT_TIMING 0x05
+#define DATA_BLOCK_TYPE_4_DMT_TIMING 0x06
+#define DATA_BLOCK_VESA_TIMING 0x07
+#define DATA_BLOCK_CEA_TIMING 0x08
+#define DATA_BLOCK_VIDEO_TIMING_RANGE 0x09
+#define DATA_BLOCK_PRODUCT_SERIAL_NUMBER 0x0a
+#define DATA_BLOCK_GP_ASCII_STRING 0x0b
+#define DATA_BLOCK_DISPLAY_DEVICE_DATA 0x0c
+#define DATA_BLOCK_INTERFACE_POWER_SEQUENCING 0x0d
+#define DATA_BLOCK_TRANSFER_CHARACTERISTICS 0x0e
+#define DATA_BLOCK_DISPLAY_INTERFACE 0x0f
+#define DATA_BLOCK_STEREO_DISPLAY_INTERFACE 0x10
+#define DATA_BLOCK_TILED_DISPLAY 0x12
+
+#define DATA_BLOCK_VENDOR_SPECIFIC 0x7f
+
+#define PRODUCT_TYPE_EXTENSION 0
+#define PRODUCT_TYPE_TEST 1
+#define PRODUCT_TYPE_PANEL 2
+#define PRODUCT_TYPE_MONITOR 3
+#define PRODUCT_TYPE_TV 4
+#define PRODUCT_TYPE_REPEATER 5
+#define PRODUCT_TYPE_DIRECT_DRIVE 6
+
+struct displayid_hdr {
+ u8 rev;
+ u8 bytes;
+ u8 prod_id;
+ u8 ext_count;
+} __packed;
+
+struct displayid_block {
+ u8 tag;
+ u8 rev;
+ u8 num_bytes;
+} __packed;
+
+struct displayid_tiled_block {
+ struct displayid_block base;
+ u8 tile_cap;
+ u8 topo[3];
+ u8 tile_size[4];
+ u8 tile_pixel_bezel[5];
+ u8 topology_id[8];
+} __packed;
+
+#endif
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b96031d..3e87f5a 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -27,12 +27,14 @@
#define EDID_LENGTH 128
#define DDC_ADDR 0x50
+#define DDC_ADDR2 0x52 /* E-DDC 1.2 - where DisplayID can hide */
#define CEA_EXT0x02
#define VTB_EXT0x10
#define DI_EXT 0x40
#define LS_EXT 0x50
#define MI_EXT 0x60
+#define DISPLAYID_EXT 0x70
struct est_timings {
u8 t1;
--
2.1.0
[PATCH 2/6] drm: add tile_group support. (v2)
From: Dave Airlie
A tile group is an identifier shared by a single monitor,
DisplayID topology has 8 bytes we can use for this, just
use those for now until something else comes up in the
future. We assign these to an idr and use the idr to
tell userspace what connectors are in the same tile group.
DisplayID v1.3 says the serial number must be unique for
displays from the same manufacturer.
v2:
destroy idr (dvdhrm)
add docbook (danvet)
airlied:- not sure how to make docbook add fns to tile group section.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 4 ++
drivers/gpu/drm/drm_crtc.c | 99 ++
include/drm/drm_crtc.h | 16 +++
3 files changed, 119 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 0a5cbbb..5ea6289 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2374,6 +2374,10 @@ void intel_crt_init(struct drm_device *dev)
Plane Helper Reference
!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
+
+ Tile group
+!Pdrivers/gpu/drm/drm_crtc.c Tile group
+
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 363301c..7f45fdc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5047,6 +5047,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
INIT_LIST_HEAD(&dev->mode_config.plane_list);
idr_init(&dev->mode_config.crtc_idr);
+ idr_init(&dev->mode_config.tile_idr);
drm_modeset_lock_all(dev);
drm_mode_create_standard_connector_properties(dev);
@@ -5134,6 +5135,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
crtc->funcs->destroy(crtc);
}
+ idr_destroy(&dev->mode_config.tile_idr);
idr_destroy(&dev->mode_config.crtc_idr);
drm_modeset_lock_fini(&dev->mode_config.connection_mutex);
}
@@ -5156,3 +5158,100 @@ struct drm_property
*drm_mode_create_rotation_property(struct drm_device *dev,
supported_rotations);
}
EXPORT_SYMBOL(drm_mode_create_rotation_property);
+
+/**
+ * DOC: Tile group
+ *
+ * Tile groups are used to represent tiled monitors with a unique
+ * integer identifier. Tiled monitors using DisplayID v1.3 have
+ * a unique 8-byte handle, we store this in a tile group, so we
+ * have a common identifier for all tiles in a monitor group.
+ */
+static void drm_tile_group_free(struct kref *kref)
+{
+ struct drm_tile_group *tg = container_of(kref, struct drm_tile_group,
refcount);
+ struct drm_device *dev = tg->dev;
+ mutex_lock(&dev->mode_config.idr_mutex);
+ idr_remove(&dev->mode_config.tile_idr, tg->id);
+ mutex_lock(&dev->mode_config.idr_mutex);
+ kfree(tg);
+}
+
+/**
+ * drm_mode_put_tile_group - drop a reference to a tile group.
+ * @dev: DRM device
+ * @tg: tile group to drop reference to.
+ *
+ * drop reference to tile group and free if 0.
+ */
+void drm_mode_put_tile_group(struct drm_device *dev,
+struct drm_tile_group *tg)
+{
+ kref_put(&tg->refcount, drm_tile_group_free);
+}
+
+/**
+ * drm_mode_get_tile_group - get a reference to an existing tile group
+ * @dev: DRM device
+ * @topology: 8-bytes unique per monitor.
+ *
+ * Use the unique bytes to get a reference to an existing tile group.
+ *
+ * RETURNS:
+ * tile group or NULL if not found.
+ */
+struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
+ char topology[8])
+{
+ struct drm_tile_group *tg;
+ int id;
+ mutex_lock(&dev->mode_config.idr_mutex);
+ idr_for_each_entry(&dev->mode_config.tile_idr, tg, id) {
+ if (!memcmp(tg->group_data, topology, 8)) {
+ if (!kref_get_unless_zero(&tg->refcount))
+ tg = NULL;
+ mutex_unlock(&dev->mode_config.idr_mutex);
+ return tg;
+ }
+ }
+ mutex_unlock(&dev->mode_config.idr_mutex);
+ return NULL;
+}
+
+/**
+ * drm_mode_create_tile_group - create a tile group from a displayid
description
+ * @dev: DRM device
+ * @topology: 8-bytes unique per monitor.
+ *
+ * Create a tile group for the unique monitor, and get a unique
+ * identifier for the tile group.
+ *
+ * RETURNS:
+ * new tile group or error.
+ */
+struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
+ char topology[8])
+{
+ struct drm_tile_group *tg;
+ int ret;
+
+ tg = kzalloc(sizeof(*tg), GFP_KERNEL);
+ if (!tg)
+ return ERR_PTR(-ENOMEM);
+
+ kref_init(&tg->refcount);
+ memcpy(tg->group_data, topology, 8);
+ tg->dev = dev;
+
+ mutex_lock(&dev->mode_config.idr_mutex);
+ ret = idr_alloc(
[PATCH 3/6] drm/mst: cached EDID for logical ports
From: Dave Airlie
Logical ports are never going to have EDID changes,
they are used for the internal ports on MST monitors.
We cache the EDIDs from these to save time at MST probe.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 20 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
include/drm/drm_dp_mst_helper.h | 4 +++-
3 files changed, 22 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..ce1113c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -858,6 +858,8 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
port->vcpi.num_slots = 0;
+
+ kfree(port->cached_edid);
if (port->connector)
(*port->mgr->cbs->destroy_connector)(mgr,
port->connector);
drm_dp_port_teardown_pdt(port, port->pdt);
@@ -1096,6 +1098,10 @@ 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 +2155,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 +2175,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 +2210,12 @@ 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_mode_connector_set_tile_property(connector);
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 d9a7a78..c66e73a 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);
--
2.1.0
[PATCH 4/6] drm/connector: store tile information from displayid (v2)
From: Dave Airlie
This creates a tile group from DisplayID block, and
stores the pieces of parsed info from the DisplayID block
into the connector.
v2: add missing signoff, add new connector bits to docs.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 5 ++
drivers/gpu/drm/drm_edid.c | 139 -
include/drm/drm_crtc.h | 18 ++
3 files changed, 160 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7f45fdc..f3e082d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -939,6 +939,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode, *t;
+ if (connector->tile_group) {
+ drm_mode_put_tile_group(dev, connector->tile_group);
+ connector->tile_group = NULL;
+ }
+
list_for_each_entry_safe(mode, t, &connector->probed_modes, head)
drm_mode_remove(connector, mode);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1dbf3bc..7cbdbe5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#define version_greater(edid, maj, min) \
(((edid)->version > (maj)) || \
@@ -1014,6 +1015,8 @@ module_param_named(edid_fixup, edid_fixup, int, 0400);
MODULE_PARM_DESC(edid_fixup,
"Minimum number of valid EDID header bytes (0-8, default 6)");
+static void drm_get_displayid(struct drm_connector *connector,
+ struct edid *edid);
/**
* drm_edid_block_valid - Sanity check the EDID block (base or extension)
* @raw_edid: pointer to raw EDID block
@@ -1294,6 +1297,8 @@ struct edid *drm_get_edid(struct drm_connector *connector,
if (drm_probe_ddc(adapter))
edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (edid)
+ drm_get_displayid(connector, edid);
return edid;
}
EXPORT_SYMBOL(drm_get_edid);
@@ -2386,7 +2391,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 +2403,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 +2413,16 @@ static u8 *drm_find_cea_extension(struct edid *edid)
return edid_ext;
}
+static u8 *drm_find_cea_extension(struct edid *edid)
+{
+ return drm_find_edid_extension(edid, CEA_EXT);
+}
+
+static u8 *drm_find_displayid_extension(struct edid *edid)
+{
+ return drm_find_edid_extension(edid, DISPLAYID_EXT);
+}
+
/*
* Calculate the alternate clock for the CEA mode
* (60Hz vs. 59.94Hz etc.)
@@ -3865,3 +3880,123 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
hdmi_vendor_infoframe *frame,
return 0;
}
EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
+
+static 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;
+ struct drm_tile_group *tg;
+
+ w = tile->tile_size[0] | tile->tile_size[1] << 8;
+ h = tile->tile_size[2] | tile->tile_size[3] <<
[PATCH 5/6] drm/tile: expose the tile property to userspace (v2)
From: Dave Airlie
This takes the tiling info from the connector and
exposes it to userspace, as a blob object in a
connector property.
The contents of the blob is ABI.
v2: add property + function documentation.
Signed-off-by: Dave Airlie
---
Documentation/DocBook/drm.tmpl | 9 +++-
drivers/gpu/drm/drm_crtc.c | 44 +
drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
include/drm/drm_crtc.h | 4
4 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 5ea6289..1f19340 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2513,7 +2513,7 @@ void intel_crt_init(struct drm_device *dev)
DRM
- Generic
+ Generic
?EDID?
BLOB | IMMUTABLE
0
@@ -2535,6 +2535,13 @@ void intel_crt_init(struct drm_device *dev)
Contains topology path to a connector.
+ ?TILE?
+ BLOB | IMMUTABLE
+ 0
+ Connector
+ Contains tiling information for a connector.
+
+
Plane
?type?
ENUM | IMMUTABLE
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f3e082d..1c64f5f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1319,6 +1319,11 @@ static int
drm_mode_create_standard_connector_properties(struct drm_device *dev)
"PATH", 0);
dev->mode_config.path_property = dev_path;
+ dev->mode_config.tile_property = drm_property_create(dev,
+DRM_MODE_PROP_BLOB
|
+
DRM_MODE_PROP_IMMUTABLE,
+"TILE", 0);
+
return 0;
}
@@ -4015,6 +4020,45 @@ int drm_mode_connector_set_path_property(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_mode_connector_set_path_property);
/**
+ * drm_mode_connector_set_tile_property - set tile property on connector
+ * @connector: connector to set property on.
+ *
+ * This looks up the tile information for a connector, and creates a
+ * property for userspace to parse if it exists. The property is of
+ * the form of 8 integers using ':' as a separator.
+ */
+int drm_mode_connector_set_tile_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ int ret, size;
+ char tile[256];
+
+ if (connector->tile_blob_ptr)
+ drm_property_destroy_blob(dev, connector->tile_blob_ptr);
+
+ if (!connector->has_tile) {
+ connector->tile_blob_ptr = NULL;
+ ret = drm_object_property_set_value(&connector->base,
+
dev->mode_config.tile_property, 0);
+ return ret;
+ }
+
+ snprintf(tile, 256, "%d:%d:%d:%d:%d:%d:%d:%d",
connector->tile_group->id, connector->tile_is_single_monitor,
connector->num_h_tile, connector->num_v_tile, connector->tile_h_loc,
connector->tile_v_loc, connector->tile_h_size, connector->tile_v_size);
+ size = strlen(tile) + 1;
+
+ connector->tile_blob_ptr = drm_property_create_blob(connector->dev,
+ size, tile);
+ if (!connector->tile_blob_ptr)
+ return -EINVAL;
+
+ ret = drm_object_property_set_value(&connector->base,
+ dev->mode_config.tile_property,
+ connector->tile_blob_ptr->base.id);
+ return ret;
+}
+EXPORT_SYMBOL(drm_mode_connector_set_tile_property);
+
+/**
* drm_mode_connector_update_edid_property - update the edid property of a
connector
* @connector: drm connector
* @edid: new value of the edid property
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c66e73a..c5529ff 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -422,6 +422,8 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_dp_add_properties(intel_dp, connector);
drm_object_attach_property(&connector->base,
dev->mode_config.path_property, 0);
+ drm_object_attach_property(&connector->base,
dev->mode_config.tile_property, 0);
+
drm_mode_connector_set_path_property(connector, pathprop);
drm_reinit_primary_mode_group(dev);
mutex_lock(&dev->mode_config.mutex);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39c9858..c41cd51 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -557,6 +557,8 @@ struct drm_connector {
struct drm_property_blob *path_blob_ptr;
+ struct drm_property_blob *tile_blob_ptr;
+
uint8_t polled; /* DRM_CONNECTOR_POLL_* */
/* r
[PATCH 6/6] drm/fb: add support for tiled monitor configurations.
From: Dave Airlie
This adds fbdev/con support for tiled monitors, so that we
only set a mode on the correct half of the monitor, or
span the two halves if needed.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c| 122 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 25 +++-
include/drm/drm_fb_helper.h| 6 ++
3 files changed, 130 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9..095f9d5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1042,19 +1042,21 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
+ int x, y;
desired_mode = fb_helper->crtc_info[i].desired_mode;
-
+ x = fb_helper->crtc_info[i].x;
+ y = fb_helper->crtc_info[i].y;
if (desired_mode) {
if (gamma_size == 0)
gamma_size =
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
- if (desired_mode->hdisplay < sizes.fb_width)
- sizes.fb_width = desired_mode->hdisplay;
- if (desired_mode->vdisplay < sizes.fb_height)
- sizes.fb_height = desired_mode->vdisplay;
- if (desired_mode->hdisplay > sizes.surface_width)
- sizes.surface_width = desired_mode->hdisplay;
- if (desired_mode->vdisplay > sizes.surface_height)
- sizes.surface_height = desired_mode->vdisplay;
+ if (desired_mode->hdisplay + x < sizes.fb_width)
+ sizes.fb_width = desired_mode->hdisplay + x;
+ if (desired_mode->vdisplay + y < sizes.fb_height)
+ sizes.fb_height = desired_mode->vdisplay + y;
+ if (desired_mode->hdisplay + x > sizes.surface_width)
+ sizes.surface_width = desired_mode->hdisplay +
x;
+ if (desired_mode->vdisplay + y > sizes.surface_height)
+ sizes.surface_height = desired_mode->vdisplay +
y;
crtc_count++;
}
}
@@ -1356,6 +1358,7 @@ static void drm_enable_connectors(struct drm_fb_helper
*fb_helper,
static bool drm_target_cloned(struct drm_fb_helper *fb_helper,
struct drm_display_mode **modes,
+ struct drm_fb_offset *offsets,
bool *enabled, int width, int height)
{
int count, i, j;
@@ -1427,27 +1430,88 @@ static bool drm_target_cloned(struct drm_fb_helper
*fb_helper,
return false;
}
+static int drm_get_tile_offsets(struct drm_fb_helper *fb_helper,
+ struct drm_display_mode **modes,
+ struct drm_fb_offset *offsets,
+ int idx,
+ int h_idx, int v_idx)
+{
+ struct drm_fb_helper_connector *fb_helper_conn;
+ int i;
+ int hoffset = 0, voffset = 0;
+
+ for (i = 0; i < fb_helper->connector_count; i++) {
+ fb_helper_conn = fb_helper->connector_info[i];
+ if (!fb_helper_conn->connector->has_tile)
+ continue;
+
+ if (!modes[i] && (h_idx || v_idx)) {
+ DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
+ fb_helper_conn->connector->base.id);
+ continue;
+ }
+ if (fb_helper_conn->connector->tile_h_loc < h_idx)
+ hoffset += modes[i]->hdisplay;
+
+ if (fb_helper_conn->connector->tile_v_loc < v_idx)
+ voffset += modes[i]->vdisplay;
+ }
+ offsets[idx].x = hoffset;
+ offsets[idx].y = voffset;
+ DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
+ return 0;
+}
+
static bool drm_target_preferred(struct drm_fb_helper *fb_helper,
struct drm_display_mode **modes,
+struct drm_fb_offset *offsets,
bool *enabled, int width, int height)
{
struct drm_fb_helper_connector *fb_helper_conn;
int i;
-
+ uint64_t conn_configured = 0, mask;
+ int tile_pass = 0;
+ mask = (1 << fb_helper->connector_count) - 1;
+retry:
for (i = 0; i < fb_helper->connector_count; i++) {
fb_helper_conn = fb_helper->connector_info[i];
- if (enabled[i] == false)
+ if (conn_configured & (1 << i))
+
[PULL] drm-intel-next
On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote: > On 21 October 2014 23:38, Daniel Vetter wrote: > > Hi Dave, > > > > drm-intel-next-2014-10-03: > > - first batch of skl stage 1 enabling > > - fixes from Rodrigo to the PSR, fbc and sink crc code > > - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic > > interrupt enable/disable functions > > - smaller stuff all over > > drm-intel-next-2014-09-19: > > - bunch more i830M fixes from Ville > > - full ppgtt now again enabled by default > > - more ppgtt fixes from Michel Thierry and Chris Wilson > > - plane config work from Gustavo Padovan > > - spinlock clarifications > > - piles of smaller improvements all over, as usual > > Chris made some noises about PPGTT being broken somewhere on irc last week, > > Chris, did you figure that out? Nope. All full-ppgtt platforms (ivb/byt/hsw) suffer from spontaneously loosing track of the right page directories and end up executing garbage. It correlates with load, so frequently makes igt (and a few tests in particular) die, along with piglit, webgl conformance, benchmarking and even eventually light loads on composited desktops. I've made the pd uncached, added copious flushing, forced switch_mm every time, added noops, cacheline alignment, srm, forced the execution of batches to be synchronous, and yet IPEHR != *ACTHD. The register and command state looks valid. The gpu resets ok and runs fine until the error strikes again. [So I need to test whether switch_mm(aliasing_ppgtt) on every batch fails as well, and whether i915.enable_rc6=0 masks it. There is the worrying bits in bspec that talk of non-RCS as being part of the render context state, but only the RCS pd registers are shown in the context diagrams. I guess I should inspect the context state and see if I can spot the other registers. If context restore (and with rc6 that could happen at any time) switched the pd on the other rings, that would be a nice snafu.] I would suggest that full-ppgtt be disabled unless someone else has had better luck finding a hsd or figuring out the missing magic. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED
> -Original Message-
> From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> Sent: Tuesday, October 21, 2014 6:30 PM
> To: Cheng, Yao
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> Kelley,
> Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R
> Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup
> bridge for VED
>
> On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> > Setup minimum required resources during i915_driver_load:
> > 1. Create a platform device to share MMIO/IRQ resources 2. Make the
> > platform device child of i915 device for runtime PM.
> > 3. Create IRQ chip to forward the VED irqs.
> > VED driver (a standalone drm driver) probes the VED device and creates
> > a new dri card on install.
> >
> > Currently only supports VED on valleyview.
> > Kerneldoc is updated for i915_ved.c.
> >
> > Signed-off-by: Yao Cheng
> > ---
> > Documentation/DocBook/drm.tmpl | 5 +
> > drivers/gpu/drm/i915/Makefile | 3 +
> > drivers/gpu/drm/i915/i915_dma.c | 11 ++
> > drivers/gpu/drm/i915/i915_drv.h | 9 ++
> > drivers/gpu/drm/i915/i915_irq.c | 2 +
> > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > drivers/gpu/drm/i915/i915_ved.c | 264
> >
> > 7 files changed, 299 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/i915_ved.c
> >
> > diff --git a/Documentation/DocBook/drm.tmpl
> > b/Documentation/DocBook/drm.tmpl index d7cfc98..f1787b4 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -3806,6 +3806,11 @@ int num_ioctls;
> > !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
> > !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
> >
> > +
> > +VED video core integration
> > +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> > +!Idrivers/gpu/drm/i915/i915_ved.c
> > +
> >
> >
> >Display Hardware Handling diff --git
> > a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index
> > 3a6bce0..a4b9252 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \ i915-y += i915_dma.o \
> > i915_ums.o
> >
> > +# VED for VLV
> > +i915-y += i915_ved.o
> > +
> > obj-$(CONFIG_DRM_I915) += i915.o
> >
> > CFLAGS_i915_trace_points.o := -I$(src) diff --git
> > a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > index 85d14e1..47714e1 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev,
> unsigned long flags)
> > if (IS_GEN5(dev))
> > intel_gpu_ips_init(dev_priv);
> >
> > + if (IS_VALLEYVIEW(dev)) {
>
> These must be (IS_VLV && !IS_CHV), or maybe define some HAS_VED()
> macro to hide that.
Accepted. Will add HAS_VED() to hide this.
>
> > + ret = vlv_setup_ved(dev);
> > + if (ret < 0) {
> > + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> > + }
> > + }
> > +
> > intel_runtime_pm_enable(dev_priv);
> >
> > return 0;
> > @@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int ret;
> >
> > + if (IS_VALLEYVIEW(dev)) {
> > + vlv_teardown_ved(dev);
> > + }
> > +
> > ret = i915_gem_suspend(dev);
> > if (ret) {
> > DRM_ERROR("failed to idle hardware: %d\n", ret); diff --git
> > a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 821ba26..952df34 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1709,6 +1709,10 @@ struct drm_i915_private {
> >
> > uint32_t bios_vgacntr;
> >
> > + /* used for setup VED bridge */
> > + struct platform_device *ved_platdev;
> > + int ved_irq;
> > +
>
> Could be neater to wrap this in a struct:
>
> struct {
> struct platform_device *platdev;
> int irq;
> } ved;
Ok, thanks for the suggestion.
>
>
> > /* Old dri1 support infrastructure, beware the dragons ya fools
> entering
> > * here! */
> > struct i915_dri1_state dri1;
> > @@ -2785,6 +2789,11 @@ void i915_restore_display_reg(struct
> drm_device
> > *dev); void i915_setup_sysfs(struct drm_device *dev_priv); void
> > i915_teardown_sysfs(struct drm_device *dev_priv);
> >
> > +/* i915_ved.c */
> > +int vlv_setup_ved(struct drm_device *dev); void
> > +vlv_teardown_ved(struct drm_device *dev); void
> > +vlv_ved_irq_handler(struct drm_device *dev);
> > +
> > /* intel_i2c.c */
> > extern int intel_setup_gmbus(struct drm_device *dev); extern void
> > intel_teardown_gmbus(struct drm_device *dev); diff --git
> > a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index 737b239..68c2977 100644
> > --- a/d
[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, October 21, 2014 8:09 PM
> To: Cheng, Yao
> Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> Kelley,
> Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R
> Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup
> bridge for VED
>
> On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> > Setup minimum required resources during i915_driver_load:
> > 1. Create a platform device to share MMIO/IRQ resources 2. Make the
> > platform device child of i915 device for runtime PM.
> > 3. Create IRQ chip to forward the VED irqs.
> > VED driver (a standalone drm driver) probes the VED device and creates
> > a new dri card on install.
> >
> > Currently only supports VED on valleyview.
> > Kerneldoc is updated for i915_ved.c.
> >
> > Signed-off-by: Yao Cheng
>
> Please resend with a patch changelog to account for my review comments.
> And Ville's. Plus cc us both. And if there's anything you didn't address, you
> must reply to the review and we need to further discuss this.
>
Daniel, I see, thanks for the instruction.
Do you mean resending the [RFC PATCH v2] with changelog and cc list?
Or adding changelog/cc when sending [RFC PATCH v3]?
> Thanks, Daniel
> > ---
> > Documentation/DocBook/drm.tmpl | 5 +
> > drivers/gpu/drm/i915/Makefile | 3 +
> > drivers/gpu/drm/i915/i915_dma.c | 11 ++
> > drivers/gpu/drm/i915/i915_drv.h | 9 ++
> > drivers/gpu/drm/i915/i915_irq.c | 2 +
> > drivers/gpu/drm/i915/i915_reg.h | 5 +
> > drivers/gpu/drm/i915/i915_ved.c | 264
> >
> > 7 files changed, 299 insertions(+)
> > create mode 100644 drivers/gpu/drm/i915/i915_ved.c
> >
> > diff --git a/Documentation/DocBook/drm.tmpl
> > b/Documentation/DocBook/drm.tmpl index d7cfc98..f1787b4 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -3806,6 +3806,11 @@ int num_ioctls;
> > !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
> > !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
> >
> > +
> > +VED video core integration
> > +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> > +!Idrivers/gpu/drm/i915/i915_ved.c
> > +
> >
> >
> >Display Hardware Handling diff --git
> > a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index
> > 3a6bce0..a4b9252 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -80,6 +80,9 @@ i915-y += dvo_ch7017.o \ i915-y += i915_dma.o \
> > i915_ums.o
> >
> > +# VED for VLV
> > +i915-y += i915_ved.o
> > +
> > obj-$(CONFIG_DRM_I915) += i915.o
> >
> > CFLAGS_i915_trace_points.o := -I$(src) diff --git
> > a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> > index 85d14e1..47714e1 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1791,6 +1791,13 @@ int i915_driver_load(struct drm_device *dev,
> unsigned long flags)
> > if (IS_GEN5(dev))
> > intel_gpu_ips_init(dev_priv);
> >
> > + if (IS_VALLEYVIEW(dev)) {
> > + ret = vlv_setup_ved(dev);
> > + if (ret < 0) {
> > + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> > + }
> > + }
> > +
> > intel_runtime_pm_enable(dev_priv);
> >
> > return 0;
> > @@ -1833,6 +1840,10 @@ int i915_driver_unload(struct drm_device *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int ret;
> >
> > + if (IS_VALLEYVIEW(dev)) {
> > + vlv_teardown_ved(dev);
> > + }
> > +
> > ret = i915_gem_suspend(dev);
> > if (ret) {
> > DRM_ERROR("failed to idle hardware: %d\n", ret); diff --git
> > a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 821ba26..952df34 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1709,6 +1709,10 @@ struct drm_i915_private {
> >
> > uint32_t bios_vgacntr;
> >
> > + /* used for setup VED bridge */
> > + struct platform_device *ved_platdev;
> > + int ved_irq;
> > +
> > /* Old dri1 support infrastructure, beware the dragons ya fools
> entering
> > * here! */
> > struct i915_dri1_state dri1;
> > @@ -2785,6 +2789,11 @@ void i915_restore_display_reg(struct
> drm_device
> > *dev); void i915_setup_sysfs(struct drm_device *dev_priv); void
> > i915_teardown_sysfs(struct drm_device *dev_priv);
> >
> > +/* i915_ved.c */
> > +int vlv_setup_ved(struct drm_device *dev); void
> > +vlv_teardown_ved(struct drm_device *dev); void
> > +vlv_ved_irq_handler(struct drm_device *dev);
> > +
> > /* intel_i2c.c */
> > extern int intel_setup_gmbus(struct drm_device *dev); extern void
> > intel_teardown_gmbus(struct drm_device *dev); diff --
[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED
On Wed, Oct 22, 2014 at 07:09:11AM +, Cheng, Yao wrote:
> > -Original Message-
> > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com]
> > Sent: Tuesday, October 21, 2014 6:30 PM
> > To: Cheng, Yao
> > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org;
> > Kelley,
> > Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R
> > Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to
> > setup
> > bridge for VED
> >
> > On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote:
> >
> > > /* Call regardless, as some status bits might not be
> > >* signalled in iir */
> > > valleyview_pipestat_irq_handler(dev, iir); diff --git
> > > a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > > index 2ed02c3..95421ef 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -1284,6 +1284,11 @@ enum punit_power_well { #define
> > > VLV_DISPLAY_BASE 0x18 #define VLV_MIPI_BASE
> > VLV_DISPLAY_BASE
> > >
> > > +/* forwarding VED irq and sharing MMIO to the VED driver */
> > > +#define VLV_VED_BLOCK_INTERRUPT (1 << 23)
> >
> > This define should be alongside the other IxR bits.
>
> Do you mean like this:
> Rename it to VLV_VED_IRQ and put alongside VLV_IIR?
No, I think the name is fine as is, but it should be where the other "old"
IxR bits are defined. So between I915_PM_INTERRUPT and I915_ISP_INTERRUPT
looks like right spot to me.
I'm not sure why those defines are where they are. We should probably
move the lot to sit next to the IxR register defines themselves, but
that's a separate issue.
> >
> > > + if (!rsc) {
> > > + DRM_ERROR("Failed to allocate resource for VED platform
> > device\n");
> > > + ret = -ENOMEM;
> > > + goto err;
> > > + }
> > > +
> > > + WARN_ON(dev_priv->ved_irq < 0);
> > > + rsc[0].start= rsc[0].end = dev_priv->ved_irq;
> > > + rsc[0].flags= IORESOURCE_IRQ;
> > > + rsc[0].name = "ipvr-ved-vlv-irq";
> > > +
> > > + /* MMIO/REG for child's use */
> > > + rsc[1].start= pci_resource_start(dev->pdev, 0);
> > > + rsc[1].end = pci_resource_start(dev->pdev, 0) + 2*1024*1024; /*
> > gen7 */
> > > + rsc[1].flags= IORESOURCE_MEM;
> > > + rsc[1].name = "ipvr-ved-vlv-mmio";
> > > +
> > > + rsc[2].start= VLV_VED_BASE;
> > > + rsc[2].end = VLV_VED_BASE + VLV_VED_SIZE;
> > > + rsc[2].flags= IORESOURCE_REG;
> > > + rsc[2].name = "ipvr-ved-vlv-reg";
> >
> > I don't see why you need both MEM and REG resources. Just the MEM itself
> > should suffice:
> >
> > rsc[1].start= pci_resource_start(dev->pdev, 0) + VLV_VED_BASE;
> > rsc[1].end = pci_resource_start(dev->pdev, 0) + VLV_VED_BASE +
> > VLV_VED_SIZE;
> > rsc[1].flags= IORESOURCE_MEM;
> > rsc[1].name = "ipvr-ved-vlv-mmio";
> >
>
> When I write the original code on k3.10 I always got ioremap conflict by
> binding only one MMIO resource.
> I just tested this on k3.17 and no conflict. :) thanks for pointing out this
> and I will update the code.
> BTW, it's interesting, is there any update on the ioremap code from 3.10 to
> 3.17?
Not sure. But the UC vs. WC could be one explanation for the conflict.
>
> > Also in the ved driver you're mapping it with ioremap_wc() which isn't
> > generally safe to do with registers. I'm not sure the kernel would even
> > allow
> > it since i915 has already mapped it as UC.
>
> Thanks, I'll change it to UC.
--
Ville Syrj?l?
Intel OTC
[PULL] drm-intel-next
On 22 October 2014 17:05, Chris Wilson wrote: > On Wed, Oct 22, 2014 at 09:09:43AM +1000, Dave Airlie wrote: >> On 21 October 2014 23:38, Daniel Vetter wrote: >> > Hi Dave, >> > >> > drm-intel-next-2014-10-03: >> > - first batch of skl stage 1 enabling >> > - fixes from Rodrigo to the PSR, fbc and sink crc code >> > - kerneldoc for the frontbuffer tracking code, runtime pm code and the >> > basic >> > interrupt enable/disable functions >> > - smaller stuff all over >> > drm-intel-next-2014-09-19: >> > - bunch more i830M fixes from Ville >> > - full ppgtt now again enabled by default >> > - more ppgtt fixes from Michel Thierry and Chris Wilson >> > - plane config work from Gustavo Padovan >> > - spinlock clarifications >> > - piles of smaller improvements all over, as usual >> >> Chris made some noises about PPGTT being broken somewhere on irc last week, >> >> Chris, did you figure that out? > > Nope. All full-ppgtt platforms (ivb/byt/hsw) suffer from spontaneously > loosing track of the right page directories and end up executing > garbage. It correlates with load, so frequently makes igt (and a few > tests in particular) die, along with piglit, webgl conformance, > benchmarking and even eventually light loads on composited desktops. > > I've made the pd uncached, added copious flushing, forced switch_mm > every time, added noops, cacheline alignment, srm, forced the execution > of batches to be synchronous, and yet IPEHR != *ACTHD. The register and > command state looks valid. The gpu resets ok and runs fine until the > error strikes again. > > [So I need to test whether switch_mm(aliasing_ppgtt) on every batch fails > as well, and whether i915.enable_rc6=0 masks it. There is the worrying > bits in bspec that talk of non-RCS as being part of the render context > state, but only the RCS pd registers are shown in the context diagrams. > I guess I should inspect the context state and see if I can spot the other > registers. If context restore (and with rc6 that could happen at any time) > switched the pd on the other rings, that would be a nice snafu.] > > I would suggest that full-ppgtt be disabled unless someone else has had > better luck finding a hsd or figuring out the missing magic. > -Chris Thanks Chris for the report, Daniel, fill in the swear words where you like, but yeah don't think I want to pull this in this state. Either pull the enable ppgtt patch or revert it on top, Thanks, Dave.
[Intel-gfx] [PATCH] drm/mode: document path property and function to set it.
On Wed, Oct 22, 2014 at 12:11:24PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> These two didn't get documented properly, do so.
>
> Pointed out by Daniel.
>
> Signed-off-by: Dave Airlie
> ---
> Documentation/DocBook/drm.tmpl | 9 -
> drivers/gpu/drm/drm_crtc.c | 10 ++
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index bacefc5..0a5cbbb 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2509,7 +2509,7 @@ void intel_crt_init(struct drm_device *dev)
>
>
> DRM
> - Generic
> + Generic
> ?EDID?
> BLOB | IMMUTABLE
> 0
> @@ -2524,6 +2524,13 @@ void intel_crt_init(struct drm_device *dev)
> Contains DPMS operation mode value.
>
>
> + ?PATH?
> + BLOB | IMMUTABLE
> + 0
> + Connector
> + Contains topology path to a connector.
> +
> +
> Plane
> ?type?
> ENUM | IMMUTABLE
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 90e7730..363301c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3980,6 +3980,16 @@ done:
> return ret;
> }
>
> +/**
> + * drm_mode_connector_set_path_property - set tile property on connector
> + * @connector: connector to set property on.
> + * @path: path to use for property.
> + *
> + * This creates a property to expose to userspace to specify a
> + * connector path. This is mainly used for DisplayPort MST where
> + * connectors have a topology and we want to allow userspace to give
> + * them more meaningful names.
> + */
The
* Returns:
* Zero on success, error code on failure.
boilerplate is missing, with this is
Reviewed-by: Daniel Vetter
> int drm_mode_connector_set_path_property(struct drm_connector *connector,
>char *path)
> {
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/6] drm: add tile_group support. (v2)
On Wed, Oct 22, 2014 at 12:32:03PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> A tile group is an identifier shared by a single monitor,
> DisplayID topology has 8 bytes we can use for this, just
> use those for now until something else comes up in the
> future. We assign these to an idr and use the idr to
> tell userspace what connectors are in the same tile group.
>
> DisplayID v1.3 says the serial number must be unique for
> displays from the same manufacturer.
>
> v2:
> destroy idr (dvdhrm)
> add docbook (danvet)
> airlied:- not sure how to make docbook add fns to tile group section.
Either you have to extract them into a new file or you have to list them
all explicitly. The kerneldoc nano howto has the various options you can
use. Thus far we haven't documented drm-internal functions though, only
those exported to drivers or helpers as guidelines to driver writers. Not
stopping you ofc ;-) But imo just documenting the tile prop registration
function is good enough.
wrt the patch I'm not 100% sure the kref_get_unless_zero is perfectly
race-free, but that depends upon how we solve the hotplugging of
properties and stuff I think.
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Dave Airlie
> ---
> Documentation/DocBook/drm.tmpl | 4 ++
> drivers/gpu/drm/drm_crtc.c | 99
> ++
> include/drm/drm_crtc.h | 16 +++
> 3 files changed, 119 insertions(+)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 0a5cbbb..5ea6289 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2374,6 +2374,10 @@ void intel_crt_init(struct drm_device *dev)
>Plane Helper Reference
> !Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
>
> +
> + Tile group
> +!Pdrivers/gpu/drm/drm_crtc.c Tile group
> +
>
>
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 363301c..7f45fdc 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5047,6 +5047,7 @@ void drm_mode_config_init(struct drm_device *dev)
> INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
> INIT_LIST_HEAD(&dev->mode_config.plane_list);
> idr_init(&dev->mode_config.crtc_idr);
> + idr_init(&dev->mode_config.tile_idr);
>
> drm_modeset_lock_all(dev);
> drm_mode_create_standard_connector_properties(dev);
> @@ -5134,6 +5135,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
> crtc->funcs->destroy(crtc);
> }
>
> + idr_destroy(&dev->mode_config.tile_idr);
> idr_destroy(&dev->mode_config.crtc_idr);
> drm_modeset_lock_fini(&dev->mode_config.connection_mutex);
> }
> @@ -5156,3 +5158,100 @@ struct drm_property
> *drm_mode_create_rotation_property(struct drm_device *dev,
> supported_rotations);
> }
> EXPORT_SYMBOL(drm_mode_create_rotation_property);
> +
> +/**
> + * DOC: Tile group
> + *
> + * Tile groups are used to represent tiled monitors with a unique
> + * integer identifier. Tiled monitors using DisplayID v1.3 have
> + * a unique 8-byte handle, we store this in a tile group, so we
> + * have a common identifier for all tiles in a monitor group.
> + */
> +static void drm_tile_group_free(struct kref *kref)
> +{
> + struct drm_tile_group *tg = container_of(kref, struct drm_tile_group,
> refcount);
> + struct drm_device *dev = tg->dev;
> + mutex_lock(&dev->mode_config.idr_mutex);
> + idr_remove(&dev->mode_config.tile_idr, tg->id);
> + mutex_lock(&dev->mode_config.idr_mutex);
> + kfree(tg);
> +}
> +
> +/**
> + * drm_mode_put_tile_group - drop a reference to a tile group.
> + * @dev: DRM device
> + * @tg: tile group to drop reference to.
> + *
> + * drop reference to tile group and free if 0.
> + */
> +void drm_mode_put_tile_group(struct drm_device *dev,
> + struct drm_tile_group *tg)
> +{
> + kref_put(&tg->refcount, drm_tile_group_free);
> +}
> +
> +/**
> + * drm_mode_get_tile_group - get a reference to an existing tile group
> + * @dev: DRM device
> + * @topology: 8-bytes unique per monitor.
> + *
> + * Use the unique bytes to get a reference to an existing tile group.
> + *
> + * RETURNS:
> + * tile group or NULL if not found.
> + */
> +struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
> +char topology[8])
> +{
> + struct drm_tile_group *tg;
> + int id;
> + mutex_lock(&dev->mode_config.idr_mutex);
> + idr_for_each_entry(&dev->mode_config.tile_idr, tg, id) {
> + if (!memcmp(tg->group_data, topology, 8)) {
> + if (!kref_get_unless_zero(&tg->refcount))
> + tg = NULL;
> + mutex_unlock(&dev->mode_config.idr_mutex);
> + return tg;
> + }
> + }
> + mutex_unlock(&dev->mode_config.id
[PATCH] drm/crtc: Fix two typos
On Tue, Oct 21, 2014 at 05:01:41PM +0300, Ville Syrj?l? wrote:
> On Wed, Oct 08, 2014 at 11:37:20AM -0500, Chuck Ebbert wrote:
> > Fix:
> >
> > ioclt -> ioctl in comment
> > wrong variable name in debug message
> >
> > Signed-off-by: Chuck Ebbert
>
> Reviewed-by: Ville Syrj?l?
>
> > ---
> >
> > --- drivers/gpu/drm/drm_crtc.c.orig 2014-10-08 11:29:50.948406186 -0500
> > +++ drivers/gpu/drm/drm_crtc.c 2014-10-08 11:30:55.781479300 -0500
This diff was manually generated and failed to apply using the usual
tooling. Please generate patches using git format-patch and send it
using git send-email, they get all the details right.
I've fixed it up while applying.
-Daniel
> > @@ -2913,7 +2913,7 @@ EXPORT_SYMBOL(drm_mode_legacy_fb_format)
> > * @file_priv: drm file for the ioctl call
> > *
> > * Add a new FB to the specified CRTC, given a user request. This is the
> > - * original addfb ioclt which only supported RGB formats.
> > + * original addfb ioctl which only supported RGB formats.
> > *
> > * Called by the user via ioctl.
> > *
> > @@ -3033,7 +3033,7 @@ static int framebuffer_check(const struc
> > num_planes = drm_format_num_planes(r->pixel_format);
> >
> > if (r->width == 0 || r->width % hsub) {
> > - DRM_DEBUG_KMS("bad framebuffer width %u\n", r->height);
> > + DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width);
> > return -EINVAL;
> > }
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2] drm/crtc: Remove duplicated ioctl code
On Tue, Oct 21, 2014 at 05:08:10PM +0300, Ville Syrj?l? wrote: > On Wed, Oct 08, 2014 at 11:40:34AM -0500, Chuck Ebbert wrote: > > Make drm_mode_add_fb() call drm_mode_add_fb2() after converting its > > args to the new internal format, instead of duplicating code. > > > > Also picks up a lot more error checking, which the legacy modes > > should pass after being converted to the new format. > > > > Signed-off-by: Chuck Ebbert > > Looks good to me. > > Reviewed-by: Ville Syrj?l? Picked up into my drm core stuff queue. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/6] drm: add tile_group support.
On Wed, Oct 22, 2014 at 12:23:30PM +1000, Dave Airlie wrote: > > And kerneldoc for the non-exported functions please, preferrably with some > > overview DOC: section to pull it all together. > > I'm posting v2, advice on kerneldoc required, so the functions end up > in the right place, I don't really wnat to add a new C file for this. Argh sorry that was a boilerplate reply that escated ;-) I've sent the same one to pretty much all the recent i915 patch series where this is the new rule. I don't think drm internal docs make a lot of sense as long as all the driver stuff is nicely documented. Some barrier to entry for core drm might actually be useful ... Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to setup bridge for VED
On Wed, Oct 22, 2014 at 07:11:21AM +, Cheng, Yao wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, October 21, 2014 8:09 PM > > To: Cheng, Yao > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > > Kelley, > > Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R > > Subject: Re: [Intel-gfx] [RFC PATCH v2 1/4] drm/i915: add i915_ved.c to > > setup > > bridge for VED > > > > On Tue, Oct 21, 2014 at 02:36:41PM +0800, Yao Cheng wrote: > > > Setup minimum required resources during i915_driver_load: > > > 1. Create a platform device to share MMIO/IRQ resources 2. Make the > > > platform device child of i915 device for runtime PM. > > > 3. Create IRQ chip to forward the VED irqs. > > > VED driver (a standalone drm driver) probes the VED device and creates > > > a new dri card on install. > > > > > > Currently only supports VED on valleyview. > > > Kerneldoc is updated for i915_ved.c. > > > > > > Signed-off-by: Yao Cheng > > > > Please resend with a patch changelog to account for my review comments. > > And Ville's. Plus cc us both. And if there's anything you didn't address, > > you > > must reply to the review and we need to further discuss this. > > > > Daniel, I see, thanks for the instruction. > Do you mean resending the [RFC PATCH v2] with changelog and cc list? > Or adding changelog/cc when sending [RFC PATCH v3]? I think you could just add the per-patch changelog for both v2 and v3 when sending out v3. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED
On Wed, Oct 22, 2014 at 06:37:16AM +, Cheng, Yao wrote: > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, October 21, 2014 5:08 PM > > To: Cheng, Yao > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > > Kelley, > > Sean V; Vetter, Daniel; Abel, Michael J; Jiang, Fei; Rao, Ram R > > Subject: Re: [Intel-gfx] [RFC PATCH v2 2/4] drm/ipvr: drm driver for VED > > > > On Tue, Oct 21, 2014 at 02:36:42PM +0800, Yao Cheng wrote: > > > Probes VED and creates a new drm device for hardware accelerated > > > video decoding. > > > Currently support VP8 decoding on valleyview. > > > > > > Signed-off-by: Yao Cheng > > > > The in-patch changelog here is missing, and there's also no indication in > > the cover letter for what changes you've made. On a quick look you've > > incorporated some of David's feedback, but not all of it. That's not good, > > since if you only partially apply review feedback then you essentially > > force reviewers to read the entire patch again, which is a good way to > > driver them away. Also you should Cc: (in the sob section of the patch) > > all the people who have commented on your patch already. > > Oops, sorry for not following the upstreaming rules :( > I might have overlooked some of David's comment..have to learn more > about the rules. For this version, I'll add changelog by replying my > patch with cc to those commenters, I assume this is not too late > > > > > With that out of the way some high-level review: > > - I think we need the full libva implementation to review the interfaces > > properly. At least the little libdrm test program doesn't seem to fully > > exercise it all. > > The libva driver need some time to be fully open sourced, but I can > upload the code to Sean's private github repo for your access. I'll sync > with Sean and you internally. It doesn't need to be the final libva driver of course, just something so that people can look at the userspace side. So upload to some github account is perfectly ok. Or do you mean we still have legal review pending on those patches? In that case I think we need to wait for that to complete first. > > - The ioctl structs need to be cleaned up. You can't use uint32_t and > > similar typedefs since they can clash with userspace. You must use __u32 > > and friends. Also, some of the padding fields arent' really required - > > if you only have 4byte types then you don't need to align to 8 bytes. > > > > - Input validation on ioctls looks spotty at best. E.g. if you have any > > padding fields you need to check that they are 0, otherwise we can't > > ever reuse them as flags fields. And on principle _all_ input fields > > must be validated first. > > > > For some good guidelines for ioctls see > > http://blog.ffwll.ch/2013/11/botching-up-ioctls.html > > > > Thanks for pointing me to the ioctl instruction... I'll read it > carefully and update the ioctl interfaces... > > > - Locking seems to be inexistent in places, at least some of the idr > > manipulation very much looks like it's done lock-free. That doesn't work > > well. > > Yes, probably we haven't considered all the scenarios carefully, is it > possible to review them in an internal discussion? Imo no need for private review since I didn't spot anything fundamentally wrong. It's just a lot of small details, and for those I think m-l review is a good tool. But someone needs to do that, and I don't really have the time for it. > > - You implement file-descriptor based fences, but then also have the more > > gem-traditional wait ioctl working on buffer objects. That's a bit a > > funky mix of implicit and explicit fencing. Furthermore adding new > > private fence objects isn't a good idea now that everyon is talking > > about de-staging android syncpts as the official userspace interface. > > > > Also, your userspace patches don't use this, so maybe we can just rip it > > all out? > > Currently the libdrm_ipvr.so uses both the WAIT IOCTL and FD style > fence... At beginning, both drm_ipvr_gem_bo_alloc() and > drm_ipvr_gem_bo_wait() use the WAIT IOCTL. > In drm_ipvr_gem_bo_alloc(), libdrm_ipvr tries to return an existing free > BO instead of requesting kernel via IOCTL, like libdrm_intel does. > Eventually we think the status query on multiple BOs is inefficient, so > we added the FD style fence to let libdrm_ipvr call select() to do a > batch query. I'm fine to drop one and keep the other. Which one is > preferred by GEM? The WAIT_IOCTL or the FD fence? Or do you suggest > directly use the Android syncpts? The wait ioctl is the usual approach with gem drivers. Explicit fencing is still in flux like I've said, so charging ahead and locking down an interface doesn't seem like a good idea. And I'd be _really_ surprised if you can benchmark the benefits of explicit fencing, so I don't think you ca
[PATCH 5/6] drm/tile: expose the tile property to userspace (v2)
On Wed, Oct 22, 2014 at 12:32:06PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This takes the tiling info from the connector and
> exposes it to userspace, as a blob object in a
> connector property.
>
> The contents of the blob is ABI.
>
> v2: add property + function documentation.
>
> Signed-off-by: Dave Airlie
> ---
> Documentation/DocBook/drm.tmpl | 9 +++-
> drivers/gpu/drm/drm_crtc.c | 44
> +
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 ++
> include/drm/drm_crtc.h | 4
> 4 files changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 5ea6289..1f19340 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2513,7 +2513,7 @@ void intel_crt_init(struct drm_device *dev)
>
>
> DRM
> - Generic
> + Generic
> ?EDID?
> BLOB | IMMUTABLE
> 0
> @@ -2535,6 +2535,13 @@ void intel_crt_init(struct drm_device *dev)
> Contains topology path to a connector.
>
>
> + ?TILE?
> + BLOB | IMMUTABLE
> + 0
> + Connector
> + Contains tiling information for a connector.
> +
> +
> Plane
> ?type?
> ENUM | IMMUTABLE
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f3e082d..1c64f5f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1319,6 +1319,11 @@ static int
> drm_mode_create_standard_connector_properties(struct drm_device *dev)
> "PATH", 0);
> dev->mode_config.path_property = dev_path;
>
> + dev->mode_config.tile_property = drm_property_create(dev,
> + DRM_MODE_PROP_BLOB
> |
> +
> DRM_MODE_PROP_IMMUTABLE,
> + "TILE", 0);
> +
> return 0;
> }
>
> @@ -4015,6 +4020,45 @@ int drm_mode_connector_set_path_property(struct
> drm_connector *connector,
> EXPORT_SYMBOL(drm_mode_connector_set_path_property);
>
> /**
> + * drm_mode_connector_set_tile_property - set tile property on connector
> + * @connector: connector to set property on.
> + *
> + * This looks up the tile information for a connector, and creates a
> + * property for userspace to parse if it exists. The property is of
> + * the form of 8 integers using ':' as a separator.
> + */
Again return value boilerplate missing.
> +int drm_mode_connector_set_tile_property(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + int ret, size;
> + char tile[256];
> +
> + if (connector->tile_blob_ptr)
> + drm_property_destroy_blob(dev, connector->tile_blob_ptr);
> +
> + if (!connector->has_tile) {
> + connector->tile_blob_ptr = NULL;
> + ret = drm_object_property_set_value(&connector->base,
> +
> dev->mode_config.tile_property, 0);
> + return ret;
> + }
> +
> + snprintf(tile, 256, "%d:%d:%d:%d:%d:%d:%d:%d",
> connector->tile_group->id, connector->tile_is_single_monitor,
> connector->num_h_tile, connector->num_v_tile, connector->tile_h_loc,
> connector->tile_v_loc, connector->tile_h_size, connector->tile_v_size);
Long line.
With both nits fixed this is Reviewed-by: Daniel Vetter
> + size = strlen(tile) + 1;
> +
> + connector->tile_blob_ptr = drm_property_create_blob(connector->dev,
> + size, tile);
> + if (!connector->tile_blob_ptr)
> + return -EINVAL;
> +
> + ret = drm_object_property_set_value(&connector->base,
> + dev->mode_config.tile_property,
> + connector->tile_blob_ptr->base.id);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_tile_property);
> +
> +/**
> * drm_mode_connector_update_edid_property - update the edid property of a
> connector
> * @connector: drm connector
> * @edid: new value of the edid property
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index c66e73a..c5529ff 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -422,6 +422,8 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> intel_dp_add_properties(intel_dp, connector);
>
> drm_object_attach_property(&connector->base,
> dev->mode_config.path_property, 0);
> + drm_object_attach_property(&connector->base,
> dev->mode_config.tile_property, 0);
> +
> drm_mode_connector_set_path_property(connector, pathprop);
> drm_reinit_primary_mode_group(dev);
> mutex_lock(&dev->mode_config.mutex);
> diff --git a/includ
[Bug 85267] vlc crashes with vdpau (Radeon 3850HD) [r600]
https://bugs.freedesktop.org/show_bug.cgi?id=85267 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michel D?nzer --- Module: Mesa Branch: master Commit: ae879718c4086fc5905070e7f26dfa2757df0c86 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae879718c4086fc5905070e7f26dfa2757df0c86 Author: Michel D?nzer Date: Tue Oct 21 12:40:15 2014 +0900 r600g: Drop references to destroyed blend state -- 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/20141022/a819502b/attachment.html>
[Bug 84140] mplayer crashes playing some files using vdpau output
https://bugs.freedesktop.org/show_bug.cgi?id=84140 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Michel D?nzer --- Module: Mesa Branch: master Commit: ae879718c4086fc5905070e7f26dfa2757df0c86 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae879718c4086fc5905070e7f26dfa2757df0c86 Author: Michel D?nzer Date: Tue Oct 21 12:40:15 2014 +0900 r600g: Drop references to destroyed blend state -- 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/20141022/420d5b99/attachment.html>
[Intel-gfx] [PATCH 3/6] drm/mst: cached EDID for logical ports
On Wed, Oct 22, 2014 at 12:32:04PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Logical ports are never going to have EDID changes,
> they are used for the internal ports on MST monitors.
>
> We cache the EDIDs from these to save time at MST probe.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 20 ++--
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> include/drm/drm_dp_mst_helper.h | 4 +++-
> 3 files changed, 22 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..ce1113c 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -858,6 +858,8 @@ static void drm_dp_destroy_port(struct kref *kref)
> struct drm_dp_mst_topology_mgr *mgr = port->mgr;
> if (!port->input) {
> port->vcpi.num_slots = 0;
> +
> + kfree(port->cached_edid);
> if (port->connector)
> (*port->mgr->cbs->destroy_connector)(mgr,
> port->connector);
> drm_dp_port_teardown_pdt(port, port->pdt);
> @@ -1096,6 +1098,10 @@ 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);
> + }
I'm confused about how this works ... the tile property gets added in the
intel ->add_connector callback already, but that relies upon drm_get_edid
having parsed the displayid stuff. What am I missing?
-Daniel
> }
>
> /* put reference to this port */
> @@ -2149,7 +2155,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 +2175,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 +2210,12 @@ 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_mode_connector_set_tile_property(connector);
> 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 d9a7a78..c66e73a 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
[PATCH] drm/dp-helper: Move the legacy helpers to gma500
Except for gma500 all drivers are converted to the new style helpers,
which have much better abstraction of the underlying hw protocols and
already much more helper functions (including the entire mst library)
on top of them. Since no one seems to work on converting gma500 let's
just move the code away so that new drivers don't end up accidentally
using this.
Cc: Patrik Jakobsson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 192 ---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 208 ++
include/drm/drm_dp_helper.h | 20
3 files changed, 208 insertions(+), 212 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08e33b8b13a4..c088bad7e72f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -39,198 +39,6 @@
* blocks, ...
*/
-/* Run a single AUX_CH I2C transaction, writing/reading data as necessary */
-static int
-i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
- uint8_t write_byte, uint8_t *read_byte)
-{
- struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
- int ret;
-
- ret = (*algo_data->aux_ch)(adapter, mode,
- write_byte, read_byte);
- return ret;
-}
-
-/*
- * I2C over AUX CH
- */
-
-/*
- * Send the address. If the I2C link is running, this 'restarts'
- * the connection with the new address, this is used for doing
- * a write followed by a read (as needed for DDC)
- */
-static int
-i2c_algo_dp_aux_address(struct i2c_adapter *adapter, u16 address, bool reading)
-{
- struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
- int mode = MODE_I2C_START;
- int ret;
-
- if (reading)
- mode |= MODE_I2C_READ;
- else
- mode |= MODE_I2C_WRITE;
- algo_data->address = address;
- algo_data->running = true;
- ret = i2c_algo_dp_aux_transaction(adapter, mode, 0, NULL);
- return ret;
-}
-
-/*
- * Stop the I2C transaction. This closes out the link, sending
- * a bare address packet with the MOT bit turned off
- */
-static void
-i2c_algo_dp_aux_stop(struct i2c_adapter *adapter, bool reading)
-{
- struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
- int mode = MODE_I2C_STOP;
-
- if (reading)
- mode |= MODE_I2C_READ;
- else
- mode |= MODE_I2C_WRITE;
- if (algo_data->running) {
- (void) i2c_algo_dp_aux_transaction(adapter, mode, 0, NULL);
- algo_data->running = false;
- }
-}
-
-/*
- * Write a single byte to the current I2C address, the
- * the I2C link must be running or this returns -EIO
- */
-static int
-i2c_algo_dp_aux_put_byte(struct i2c_adapter *adapter, u8 byte)
-{
- struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
- int ret;
-
- if (!algo_data->running)
- return -EIO;
-
- ret = i2c_algo_dp_aux_transaction(adapter, MODE_I2C_WRITE, byte, NULL);
- return ret;
-}
-
-/*
- * Read a single byte from the current I2C address, the
- * I2C link must be running or this returns -EIO
- */
-static int
-i2c_algo_dp_aux_get_byte(struct i2c_adapter *adapter, u8 *byte_ret)
-{
- struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
- int ret;
-
- if (!algo_data->running)
- return -EIO;
-
- ret = i2c_algo_dp_aux_transaction(adapter, MODE_I2C_READ, 0, byte_ret);
- return ret;
-}
-
-static int
-i2c_algo_dp_aux_xfer(struct i2c_adapter *adapter,
-struct i2c_msg *msgs,
-int num)
-{
- int ret = 0;
- bool reading = false;
- int m;
- int b;
-
- for (m = 0; m < num; m++) {
- u16 len = msgs[m].len;
- u8 *buf = msgs[m].buf;
- reading = (msgs[m].flags & I2C_M_RD) != 0;
- ret = i2c_algo_dp_aux_address(adapter, msgs[m].addr, reading);
- if (ret < 0)
- break;
- if (reading) {
- for (b = 0; b < len; b++) {
- ret = i2c_algo_dp_aux_get_byte(adapter,
&buf[b]);
- if (ret < 0)
- break;
- }
- } else {
- for (b = 0; b < len; b++) {
- ret = i2c_algo_dp_aux_put_byte(adapter, buf[b]);
- if (ret < 0)
- break;
- }
- }
- if (ret < 0)
- break;
- }
- if (ret >= 0)
- ret = num;
- i2c_algo_dp_aux_stop(adapter, reading);
- DRM_DEBUG_KMS("dp_aux_xfer return %d\n", ret);
- return ret;
-}
-
-static u32
-i2c_algo_dp_aux_functionality(str
[PATCH] Revert "drm/i915: Enable full PPGTT on gen7"
This reverts commit 8c50f10d73b50139dcfe48bc22f2c8c7822c1983. It's not yet solid and Dave objected to pulling the tree in its current state. Cc: Michel Thierry Cc: Dave Airlie Cc: Chris Wilson References: http://mid.mail-archive.com/CAPM=9ty2r1MLE=wzC-_vNSUzXVqAyXiGgocpSV9qOp0gzpK3xA at mail.gmail.com References: http://lists.freedesktop.org/archives/intel-gfx/2014-October/053926.html Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 273dad964e1b..8ddc834f722f 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -67,7 +67,7 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) return 0; } - return has_full_ppgtt ? 2 : has_aliasing_ppgtt ? 1 : 0; + return has_aliasing_ppgtt ? 1 : 0; } -- 2.1.1
[Bug 85320] New: GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 Bug ID: 85320 Summary: GPU hangs using hardware acceleration Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: ken20001 at ukr.net With new kernel 3.18RC1 trying hardware acceleraton I discovered GPU hangs. Running 'mpv -vo vdpau --hwdec vdpau filename' starts to play movie and all it seems ok. But if we try to rewind forward/backward first it, playing, hangs. Than all system hangs. Switching to another VT in dmesg appears: [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35). [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35). Switching back to VT7 we can watch that image appears and disappears. Restarting ligtdm service allowed me to log in to account. But anyway all system switched to XRender and no OpenGL until I fully reboot. mpv --version mpv git-f5a19f6 (C) 2000-2014 mpv/MPlayer/mplayer2 projects built on 2014-10-18T11:58:42 ffmpeg library versions: libavutil 54.7.100 libavcodec 56.1.100 libavformat 56.4.101 libswscale 3.0.100 libavfilter 5.1.100 libavresample 2.1.0 vdpauinfo 0.1-1 mesa-vdpau-drivers 10.4~git1410211930.ef280c~gd~t libgl1-mesa-glx 10.4~git1410211930.ef280c~gd~t Kubuntu 14.04.1 Linux: 3.18RC1 x86_64 Graphics: Radeon HD2600 XT -- 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/20141022/e4b4dc00/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 Eugene changed: What|Removed |Added Priority|medium |high CC||ken20001 at ukr.net Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |major -- 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/20141022/8bb98c58/attachment.html>
[PATCH] Revert "drm/i915: Enable full PPGTT on gen7"
On Wed, Oct 22, 2014 at 11:23:03AM +0200, Daniel Vetter wrote: > This reverts commit 8c50f10d73b50139dcfe48bc22f2c8c7822c1983. > > It's not yet solid and Dave objected to pulling the tree in its > current state. > > Cc: Michel Thierry > Cc: Dave Airlie > Cc: Chris Wilson > References: > http://mid.mail-archive.com/CAPM=9ty2r1MLE=wzC-_vNSUzXVqAyXiGgocpSV9qOp0gzpK3xA > at mail.gmail.com > References: > http://lists.freedesktop.org/archives/intel-gfx/2014-October/053926.html > Signed-off-by: Daniel Vetter Acked-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 --- Comment #15 from Michel D?nzer --- Created attachment 108227 --> https://bugs.freedesktop.org/attachment.cgi?id=108227&action=edit Add some debugging output about why page flipping isn't possible Please let us know what output this generates while you're seeing tearing with MythTV. -- 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/20141022/3e335c8d/attachment.html>
[Bug 85323] New: Video is stuttering using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85323 Bug ID: 85323 Summary: Video is stuttering using hardware acceleration Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: ken20001 at ukr.net Using hardware acceleration in mpv (mpv -vo vdpau --hwdec vdpau) video plays not smooth but stuttering with this sample: http://www.ulozto.net/live/x2Af6ro/planet-earth-from-pole-to-pole-1080p-sample-16ref-mkv mpv --version mpv git-f5a19f6 (C) 2000-2014 mpv/MPlayer/mplayer2 projects built on 2014-10-18T11:58:42 ffmpeg library versions: libavutil 54.7.100 libavcodec 56.1.100 libavformat 56.4.101 libswscale 3.0.100 libavfilter 5.1.100 libavresample 2.1.0 vdpauinfo 0.1-1 mesa-vdpau-drivers 10.4~git1410211930.ef280c~gd~t libgl1-mesa-glx 10.4~git1410211930.ef280c~gd~t Kubuntu 14.04.1 Linux: 3.18RC1 x86_64 Graphics: Radeon HD2600 XT -- 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/20141022/03fccd13/attachment.html>
[Bug 82711] After update to kernel soft lockup (oops) and incomplete boot and shutdown fail
https://bugzilla.kernel.org/show_bug.cgi?id=82711 Christopher Crouse changed: What|Removed |Added CC||crouse.hackz at gmail.com --- Comment #13 from Christopher Crouse --- Possible related to Bug #70354 and/or #85791? Bug #85791 https://bugzilla.kernel.org/show_bug.cgi?id=85791 Bug #70354 https://bugs.freedesktop.org/show_bug.cgi?id=70354 This is bug is affecting me too, however other option is to only use the integrated (Intel) card & disable the Nvidia card in BIOS. Currently works for me. Hope it helps! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85207] agd5f drm-next-3.19-wip + Unreal Elemental sometimes = list_add corruption/hung task
https://bugs.freedesktop.org/show_bug.cgi?id=85207 --- Comment #6 from Christian K?nig --- (In reply to Andy Furniss from comment #5) > I don't know about Elemental as it's far harder to trigger, but first try > with valley produced - > > [ 156.617954] radeon :01:00.0: GPU fault detected: 146 0x02e83504 > [ 156.617960] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > 0x00010F17 > [ 156.617961] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > 0x08035004 > [ 156.617963] VM fault (0x04, vmid 4) at page 69399, read from VGT (53) Sounds like a different problem triggered by the same patchset to me. But first things first, is the original issue with the list corruption fixed? If yes we can start to look into this one as well. -- 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/20141022/88a7b672/attachment.html>
[Bug 85323] Video is stuttering using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85323 --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- 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/20141022/e09c077d/attachment.html>
[PATCH] drm/dp-helper: Move the legacy helpers to gma500
On Wed, Oct 22, 2014 at 11:16 AM, Daniel Vetter
wrote:
> Except for gma500 all drivers are converted to the new style helpers,
> which have much better abstraction of the underlying hw protocols and
> already much more helper functions (including the entire mst library)
> on top of them. Since no one seems to work on converting gma500 let's
> just move the code away so that new drivers don't end up accidentally
> using this.
Thanks for doing this! I'll CC Alan as well.
Reviewed-by: Patrik Jakobsson
> Cc: Patrik Jakobsson
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_helper.c | 192 ---
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 208
> ++
> include/drm/drm_dp_helper.h | 20
> 3 files changed, 208 insertions(+), 212 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 08e33b8b13a4..c088bad7e72f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -39,198 +39,6 @@
> * blocks, ...
> */
>
> -/* Run a single AUX_CH I2C transaction, writing/reading data as necessary */
> -static int
> -i2c_algo_dp_aux_transaction(struct i2c_adapter *adapter, int mode,
> - uint8_t write_byte, uint8_t *read_byte)
> -{
> - struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
> - int ret;
> -
> - ret = (*algo_data->aux_ch)(adapter, mode,
> - write_byte, read_byte);
> - return ret;
> -}
> -
> -/*
> - * I2C over AUX CH
> - */
> -
> -/*
> - * Send the address. If the I2C link is running, this 'restarts'
> - * the connection with the new address, this is used for doing
> - * a write followed by a read (as needed for DDC)
> - */
> -static int
> -i2c_algo_dp_aux_address(struct i2c_adapter *adapter, u16 address, bool
> reading)
> -{
> - struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
> - int mode = MODE_I2C_START;
> - int ret;
> -
> - if (reading)
> - mode |= MODE_I2C_READ;
> - else
> - mode |= MODE_I2C_WRITE;
> - algo_data->address = address;
> - algo_data->running = true;
> - ret = i2c_algo_dp_aux_transaction(adapter, mode, 0, NULL);
> - return ret;
> -}
> -
> -/*
> - * Stop the I2C transaction. This closes out the link, sending
> - * a bare address packet with the MOT bit turned off
> - */
> -static void
> -i2c_algo_dp_aux_stop(struct i2c_adapter *adapter, bool reading)
> -{
> - struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
> - int mode = MODE_I2C_STOP;
> -
> - if (reading)
> - mode |= MODE_I2C_READ;
> - else
> - mode |= MODE_I2C_WRITE;
> - if (algo_data->running) {
> - (void) i2c_algo_dp_aux_transaction(adapter, mode, 0, NULL);
> - algo_data->running = false;
> - }
> -}
> -
> -/*
> - * Write a single byte to the current I2C address, the
> - * the I2C link must be running or this returns -EIO
> - */
> -static int
> -i2c_algo_dp_aux_put_byte(struct i2c_adapter *adapter, u8 byte)
> -{
> - struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
> - int ret;
> -
> - if (!algo_data->running)
> - return -EIO;
> -
> - ret = i2c_algo_dp_aux_transaction(adapter, MODE_I2C_WRITE, byte,
> NULL);
> - return ret;
> -}
> -
> -/*
> - * Read a single byte from the current I2C address, the
> - * I2C link must be running or this returns -EIO
> - */
> -static int
> -i2c_algo_dp_aux_get_byte(struct i2c_adapter *adapter, u8 *byte_ret)
> -{
> - struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
> - int ret;
> -
> - if (!algo_data->running)
> - return -EIO;
> -
> - ret = i2c_algo_dp_aux_transaction(adapter, MODE_I2C_READ, 0,
> byte_ret);
> - return ret;
> -}
> -
> -static int
> -i2c_algo_dp_aux_xfer(struct i2c_adapter *adapter,
> -struct i2c_msg *msgs,
> -int num)
> -{
> - int ret = 0;
> - bool reading = false;
> - int m;
> - int b;
> -
> - for (m = 0; m < num; m++) {
> - u16 len = msgs[m].len;
> - u8 *buf = msgs[m].buf;
> - reading = (msgs[m].flags & I2C_M_RD) != 0;
> - ret = i2c_algo_dp_aux_address(adapter, msgs[m].addr, reading);
> - if (ret < 0)
> - break;
> - if (reading) {
> - for (b = 0; b < len; b++) {
> - ret = i2c_algo_dp_aux_get_byte(adapter,
> &buf[b]);
> - if (ret < 0)
> - break;
> - }
> - } else {
> - for (b = 0; b < len; b++) {
> - ret = i2c_algo_dp_aux_put_byte(adapter,
> buf[b]
[PATCH] drm/dp-helper: Move the legacy helpers to gma500
On Wed, Oct 22, 2014 at 04:32:52PM +0200, Patrik Jakobsson wrote: > On Wed, Oct 22, 2014 at 11:16 AM, Daniel Vetter > wrote: > > Except for gma500 all drivers are converted to the new style helpers, > > which have much better abstraction of the underlying hw protocols and > > already much more helper functions (including the entire mst library) > > on top of them. Since no one seems to work on converting gma500 let's > > just move the code away so that new drivers don't end up accidentally > > using this. > > Thanks for doing this! I'll CC Alan as well. > > Reviewed-by: Patrik Jakobsson Thanks, I've stuffed this patch into my drm patch queue to make sure it won't get lost. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFC PATCH] drm/exynos: Add DECON driver
Thanks for contribution.
It seems reasonable that you separate device drivers into FIMD and DECON
because many registers of them have many different offsets and fields.
However, there may be a good solution that we can combine common sets of
these drivers later.
Below are my comments.
Thanks,
Inki Dae
On 2014? 10? 10? 21:48, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
DECON was used since Exynos5430. And is Exynos5433 different from
Exynos7? If so, could I get the Exynos7 user manual (TRM) for review?
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/exynos-decon.txt | 68 ++
> drivers/gpu/drm/exynos/Kconfig | 11 +-
> drivers/gpu/drm/exynos/Makefile|1 +
> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086
> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 +
> include/video/samsung_decon.h | 346 +++
> 7 files changed, 1537 insertions(+), 3 deletions(-)
> create mode 100644
Documentation/devicetree/bindings/video/exynos-decon.txt
> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
> create mode 100644 include/video/samsung_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt
b/Documentation/devicetree/bindings/video/exynos-decon.txt
> new file mode 100644
> index 000..e865650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
> @@ -0,0 +1,68 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller
for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";
If exynos5433 was just renamed to exynos7 then, it should be one of the
following:
(a) "samsung,exynos5430-decon" for Display and enhancement controller
IP for Exynos5430
(b) "samsung,exynos7" for Display and enhancement controller IP for
Exynos7
Or,
(a) "samsung,exynos5430-decon" for Display and enhancement controller
IP for Exynos5430
(b) "samsung,exynos5433-decon" for Display and enhancement controller
IP for Exynos5433
(c) "samsung,exynos7" for Display and enhancement controller IP for
Exynos7
> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> + parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts
in the
> + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> + format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> + "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> + property. Must contain "pclk_decon0", "aclk_decon0",
> +"decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0",
> +"aclk_disp", "aclk_lh_disp1".
Should DECON driver really control above all clocks? I think it's enough
that DECON driver controls only lcd and bus clocks, and others could be
configured by boot-loader or by calling clk_set_rate.
> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.
You are missing many properties,
samsung,invert-vden
samsung,invert-vclk
display-timings
...
refer to below document,
Documentation/devicetree/bindings/video/samsung-fimd.txt
> +
> +Example:
> +
> +SoC specific DT entry:
> +
> + decon at 1393 {
> + compatible = "samsung,exynos7-decon";
> + interrupt-parent = <&combiner>;
> + reg = <0x1393 0x1000>;
> + interrupt-names = "lcd_sys", "vsync", "fifo";
> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> +
[RFC PATCH] drm/exynos: Add DECON driver
On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: > > Thanks for contribution. > > It seems reasonable that you separate device drivers into FIMD and DECON > because many registers of them have many different offsets and fields. > However, there may be a good solution that we can combine common sets of > these drivers later. Yes, this is the main reason behind sending this as RFC patch. I want to know what's the best way to do this. FIMD, 5433 DECON and Exynos7 DECON - all are different. Also, in Exynos7 DECON-INT is same as DECON-EXT(Mixer). So, even I am not sure how the driver layouts should be! > Below are my comments. > > Thanks, > Inki Dae > > On 2014? 10? 10? 21:48, Ajay Kumar wrote: >> This series is based on exynos-drm-next branch of Inki Dae's tree at: >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> DECON(Display and Enhancement Controller) is the new IP >> in exynos7 SOC for generating video signals using pixel data. > > DECON was used since Exynos5430. And is Exynos5433 different from > Exynos7? If so, could I get the Exynos7 user manual (TRM) for review? Yes, Exynos5433 DECON is very much different than Exynos7 DECON. I will see how manual can be arranged. >> >> DECON driver can be used to drive 2 different interfaces on Exynos7: >> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI) >> >> The existing FIMD driver code was used as a template to create >> DECON driver. Only DECON-INT is supported as of now, and >> DECON-EXT support will be added later. >> >> Signed-off-by: Akshu Agrawal >> Signed-off-by: Ajay Kumar >> --- >> .../devicetree/bindings/video/exynos-decon.txt | 68 ++ >> drivers/gpu/drm/exynos/Kconfig | 11 +- >> drivers/gpu/drm/exynos/Makefile|1 + >> drivers/gpu/drm/exynos/exynos_drm_decon.c | 1086 > >> drivers/gpu/drm/exynos/exynos_drm_drv.c| 17 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 + >> include/video/samsung_decon.h | 346 +++ >> 7 files changed, 1537 insertions(+), 3 deletions(-) >> create mode 100644 > Documentation/devicetree/bindings/video/exynos-decon.txt >> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c >> create mode 100644 include/video/samsung_decon.h >> >> diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt > b/Documentation/devicetree/bindings/video/exynos-decon.txt >> new file mode 100644 >> index 000..e865650 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/exynos-decon.txt >> @@ -0,0 +1,68 @@ >> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) >> + >> +DECON (Display and Enhancement Controller) is the Display Controller > for the >> +Exynos7 series of SoCs which transfers the image data from a video memory >> +buffer to an external LCD interface. >> + >> +Required properties: >> +- compatible: value should be "samsung,exynos7-decon"; > > If exynos5433 was just renamed to exynos7 then, it should be one of the > following: > (a) "samsung,exynos5430-decon" for Display and enhancement controller > IP for Exynos5430 > (b) "samsung,exynos7" for Display and enhancement controller IP for > Exynos7 > > Or, > (a) "samsung,exynos5430-decon" for Display and enhancement controller > IP for Exynos5430 > > (b) "samsung,exynos5433-decon" for Display and enhancement controller > IP for Exynos5433 > (c) "samsung,exynos7" for Display and enhancement controller IP for > Exynos7 Eventually, we will end up here. > >> + >> +- reg: physical base address and length of the DECON registers set. >> + >> +- interrupt-parent: should be the phandle of the decon controller's >> + parent interrupt controller. >> + >> +- interrupts: should contain a list of all DECON IP block interrupts > in the >> + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier >> + format depends on the interrupt controller used. >> + >> +- interrupt-names: should contain the interrupt names: "fifo", "vsync", >> + "lcd_sys", in the same order as they were listed in the interrupts >> +property. >> + >> +- pinctrl-0: pin control group to be used for this controller. >> + >> +- pinctrl-names: must contain a "default" entry. >> + >> +- clocks: must include clock specifiers corresponding to entries in the >> + clock-names property. >> + >> +- clock-names: list of clock names sorted in the same order as the clocks >> + property. Must contain "pclk_decon0", "aclk_decon0", >> +"decon0_eclk", "decon0_vclk", "sclk_dsd", aclk_lh_disp0", >> +"aclk_disp", "aclk_lh_disp1". > > Should DECON driver really control above all clocks? I think it's enough > that DECON driver controls only lcd and bus clocks, and others could be > configured by boot-loader or by calling clk_set_rate. Yes, even I am not sure of the clocks. I have cop
[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 --- Comment #16 from warpme at o2.pl --- (In reply to Michel D?nzer from comment #15) > Created attachment 108227 [details] > Add some debugging output about why page flipping isn't possible > > Please let us know what output this generates while you're seeing tearing > with MythTV. Pls find content of Xorg.0.0.log LOG for FE-AMDe2100 with applied patch [951037.435] X.Org X Server 1.16.1 Release Date: 2014-09-21 [951037.436] X Protocol Version 11, Revision 0 [951037.436] Build Operating System: Linux 3.16.1-custom_1-ARCH x86_64 [951037.436] Current Operating System: Linux FE-AMDe2100 3.16.5 #1 SMP Fri Oct 10 12:33:39 CEST 2014 x86_64 [951037.436] Kernel command line: kernel ro root=/dev/ram0 initrd=rootfs ramdisk_size=16 [951037.436] Build Date: 02 October 2014 09:30:58PM [951037.436] [951037.436] Current version of pixman: 0.28.2 [951037.436] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [951037.436] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [951037.436] (==) Log file: "/var/log/Xorg.0.0.log", Time: Wed Oct 22 18:27:57 2014 [951037.441] (==) Using config file: "/etc/X11/xorg.conf" [951037.442] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [951037.493] (**) Option "defaultserverlayout" "Layout1" [951037.493] (**) ServerLayout "Layout1" [951037.493] (**) |-->Screen "Screen1" (0) [951037.541] (**) | |-->Monitor "Monitor1" [951037.541] (**) | |-->Device "Device_radeon" [951037.541] (**) Option "BlankTime" "0" [951037.541] (**) Option "StandbyTime" "0" [951037.541] (**) Option "SuspendTime" "0" [951037.541] (**) Option "OffTime" "0" [951037.541] (**) Option "NoPM" "true" [951037.541] (**) Option "Xinerama" "false" [951037.541] (**) Option "AIGLX" "false" [951037.541] (==) Automatically adding devices [951037.541] (==) Automatically enabling devices [951037.541] (==) Automatically adding GPU devices [951037.543] (==) FontPath set to: /usr/share/fonts/X11/TTF, /usr/share/fonts/X11/misc [951037.543] (**) ModulePath set to "/usr/lib/xorg/modules" [951037.543] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [951037.543] (II) Loader magic: 0x8882c0 [951037.543] (II) Module ABI versions: [951037.543] X.Org ANSI C Emulation: 0.4 [951037.543] X.Org Video Driver: 18.0 [951037.543] X.Org XInput driver : 21.0 [951037.543] X.Org Server Extension : 8.0 [951037.558] (EE) systemd-logind: failed to get session: The name org.freedesktop.login1 was not provided by any .service files [951037.559] (II) xfree86: Adding drm device (/dev/dri/card0) [951037.562] (--) PCI:*(0:0:1:0) 1002:9834:1458:d000 rev 0, Mem @ 0xc000/268435456, 0xd000/8388608, 0xfeb0/262144, I/O @ 0xf000/256, BIOS @ 0x/131072 [951037.562] (II) "glx" will be loaded by default. [951037.562] (II) LoadModule: "dri2" [951037.567] (II) Module "dri2" already built-in [951037.567] (II) LoadModule: "glamoregl" [951037.570] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [951037.664] (II) Module glamoregl: vendor="X.Org Foundation" [951037.664] compiled for 1.16.1, module version = 1.0.0 [951037.664] ABI class: X.Org ANSI C Emulation, version 0.4 [951037.664] (II) LoadModule: "glx" [951037.666] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [951037.704] (II) Module glx: vendor="X.Org Foundation" [951037.704] compiled for 1.16.1, module version = 1.0.0 [951037.704] ABI class: X.Org Server Extension, version 8.0 [951037.704] (**) AIGLX disabled [951037.704] (II) LoadModule: "radeon" [951037.706] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so [951037.762] (II) Module radeon: vendor="X.Org Foundation" [951037.762] compiled for 1.16.1, module version = 7.5.0 [951037.762] Module class: X.Org Video Driver [951037.762] ABI class: X.Org Video Driver, version 18.0 [951037.762] (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI FireMV 2400 3155 (PCI), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI
[r600g] Is LLVM-compiler (--enable-r600-llvm-compiler) usable, now?
Hello Michel, subject say it all ;-) Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your latest work, but I think about what we could get if we find the right commit between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next). I do not have 3.16.x around (it is not any longer in the openSUSE kernel current tree) but with latest 3.16.4 I was faster then with all 3.17.x and 3.18/3.19-next kernels. bisect do not work right or I couldn't revert the 'right' commit. WC helped on RV730 (AGP) with some apps, here: mesa-demos e.g. vsraytrace fsraytrace objview Any ideas? -Dieter
[Bug 85334] display freeze while playing XCOM: GPU lockup (waiting for 0x00000000000aa7a6 last fence id 0x00000000000aa7a0 on ring 0)
https://bugs.freedesktop.org/show_bug.cgi?id=85334 Alex Deucher changed: What|Removed |Added Component|Driver/Radeon |Drivers/Gallium/radeonsi Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|Mesa QA Contact|xorg-team at lists.x.org | -- 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/20141022/ad5b539a/attachment.html>
[Bug 85323] Video is stuttering using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85323 Eugene changed: What|Removed |Added CC||ken20001 at ukr.net --- Comment #2 from Eugene --- Now I suspect this is the same problem with: https://bugs.freedesktop.org/show_bug.cgi?id=85320 because this time it hanged fully with this video. -- 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/20141022/6c735566/attachment.html>
[Bug 85323] Video is stuttering using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85323 --- Comment #3 from Eugene --- Created attachment 108250 --> https://bugs.freedesktop.org/attachment.cgi?id=108250&action=edit Xorg.log -- 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/20141022/72061149/attachment.html>
[Bug 85323] Video is stuttering using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85323 --- Comment #4 from Eugene --- Created attachment 108251 --> https://bugs.freedesktop.org/attachment.cgi?id=108251&action=edit dmesg -- 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/20141022/3fd18241/attachment.html>
[Mesa-dev] [r600g] Is LLVM-compiler (--enable-r600-llvm-compiler) usable, now?
On Wed, Oct 22, 2014 at 12:49 PM, Dieter N?tzel wrote: > Hello Michel, > > subject say it all ;-) The llvm support for r600g is for compute (OpenCL). The fact that is it somewhat usable for graphics is mainly for testing purposes. There are no plans to expand it to handle additional graphics features, although any interested parties are welcome to contribute to improving it. IIRC, even when you enable it, it currently only gets applied to compute shaders. > > Second, we are now nearly on par with 3.16 on RV730 (AGP) with all your > latest work, but I think about what we could get if we find the right commit > between 3.16 (.4 here) and 3.17-rc1 (the transition from 3.16 to 3.17-next). > > I do not have 3.16.x around (it is not any longer in the openSUSE kernel > current tree) but with latest 3.16.4 I was faster then with all 3.17.x and > 3.18/3.19-next kernels. > > bisect do not work right or I couldn't revert the 'right' commit. > WC helped on RV730 (AGP) with some apps, here: How are you doing the bisection? If it's purely a performance issue it should be pretty straight forward. > > mesa-demos e.g. > vsraytrace > fsraytrace > objview > > Any ideas? Can you provide some additional detail? It would probably be easier to track this in a bug report. Alex
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #1 from Alex Deucher --- If this is a regression can you narrow down which component (kernel, mesa, etc.) caused the problem and bisect? Please also attach your xorg log and dmesg output. -- 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/20141022/03e0e897/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #2 from Eugene --- I suspect this is the same as: https://bugs.freedesktop.org/show_bug.cgi?id=85323 -- 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/20141022/b48bdba2/attachment-0001.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #3 from Eugene --- (In reply to Alex Deucher from comment #1) > If this is a regression can you narrow down which component (kernel, mesa, > etc.) caused the problem and bisect? Please also attach your xorg log and > dmesg output. And yes, I would do bisect if somebody explain how to. But I don't know. -- 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/20141022/85c85b0b/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #4 from Eugene --- Created attachment 108252 --> https://bugs.freedesktop.org/attachment.cgi?id=108252&action=edit Xorg.log -- 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/20141022/e1ad6923/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #5 from Eugene --- Created attachment 108253 --> https://bugs.freedesktop.org/attachment.cgi?id=108253&action=edit dmesg -- 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/20141022/77f3a260/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #6 from Alex Deucher --- Google for "git bisect howto". There are lots of good tutorials. -- 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/20141022/4f416569/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #7 from Eugene --- (In reply to Alex Deucher from comment #6) > Google for "git bisect howto". There are lots of good tutorials. What exactly I shoud bisect, mesa ? Where to get it ? -- 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/20141022/64dd4643/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #8 from Alex Deucher --- (In reply to Eugene from comment #7) > (In reply to Alex Deucher from comment #6) > > Google for "git bisect howto". There are lots of good tutorials. > What exactly I shoud bisect, mesa ? Where to get it ? Can you narrow down whether it was a mesa update or a kernel update that caused the regression? You'll need to do that first. Once you've figured that out, you can bisect the appropriate component (mesa or kernel). Mesa git info is here: http://cgit.freedesktop.org/mesa/mesa/ kernel git info: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ -- 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/20141022/e804c15b/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #9 from Eugene --- The thing is that Linux 3.18 is the first kernel with which hardwear acceleration for HD2600 became possible. So I don't think the regression takes place. -- 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/20141022/8ff29d86/attachment.html>
[PATCH] drm/dp-helper: Move the legacy helpers to gma500
On Wed, 22 Oct 2014 16:32:52 +0200 Patrik Jakobsson wrote: > On Wed, Oct 22, 2014 at 11:16 AM, Daniel Vetter > wrote: > > Except for gma500 all drivers are converted to the new style helpers, > > which have much better abstraction of the underlying hw protocols and > > already much more helper functions (including the entire mst library) > > on top of them. Since no one seems to work on converting gma500 let's > > just move the code away so that new drivers don't end up accidentally > > using this. > > Thanks for doing this! I'll CC Alan as well. Reviewed-by: Alan Cox Please consider adding an __deprecated marker to one of the top functions so it irritates me or someone else into cleaning it up properly
[RFC] drm: Add utility function to check for edp1.4
From: Sonika Jindal
v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set
(Satheesh)
v3: Moving the utility function to drm_dp_helper (Daniel)
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/drm_dp_helper.c | 15 +++
include/drm/drm_dp_helper.h |2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 08e33b8..a54a760 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -768,3 +768,18 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux)
i2c_del_adapter(&aux->ddc);
}
EXPORT_SYMBOL(drm_dp_aux_unregister);
+
+bool drm_dp_is_edp_v1_4(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ uint8_t reg;
+
+ if (dpcd[DP_EDP_CONFIGURATION_CAP] &
+DP_DPCD_DISPLAY_CONTROL_CAPABLE) {
+
+ if (drm_dp_dpcd_read(aux, DP_EDP_REV, ®, 1))
+ if (reg == 0x03)
+ return true;
+ }
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_is_edp_v1_4);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8edeed0..b017e1e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -102,6 +102,8 @@
#define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */
#define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
+#define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3)
+#define DP_EDP_REV 0x700
/* Multiple stream transport */
#define DP_FAUX_CAP0x020 /* 1.2 */
--
1.7.10.4
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On 18/10/14 00:13, Jani Nikula wrote: > Documentation/kbuild/kconfig-language.txt warns to use select with care, > and in general use select only for non-visible symbols and for symbols > with no dependencies, because select will force a symbol to a value > without visiting the dependencies. > > Select has become particularly problematic, interdependently, with the > BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO configs. For example: > > scripts/kconfig/conf --randconfig Kconfig > KCONFIG_SEED=0x48312B00 > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > warning: (DRM_RADEON && DRM_NOUVEAU && DRM_I915 && DRM_GMA500 && > DRM_SHMOBILE && DRM_TILCDC && FB_BACKLIGHT && FB_MX3 && USB_APPLEDISPLAY > && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && > EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE > which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) > > With tristates it's possible to end up selecting FOO=y depending on > BAR=m in the config, which gets discovered at build time, not config > time, like reported in the thread referenced below. > > Do the following to fix the dependencies: > > * Depend on instead of select BACKLIGHT_CLASS_DEVICE everywhere. Drop > select BACKLIGHT_LCD_SUPPORT in such cases, as it's a dependency of > BACKLIGHT_CLASS_DEVICE. > > * Remove config FB_BACKLIGHT altogether, and replace it with a > dependency on BACKLIGHT_CLASS_DEVICE. All configs selecting > FB_BACKLIGHT select or depend on FB anyway, so we can simplify. > > * Depend on (ACPI && ACPI_VIDEO) || ACPI=n in several places instead of > selecting ACPI_VIDEO and a number of its dependencies if ACPI is > enabled. This is tied to backlight, as ACPI_VIDEO depends on > BACKLIGHT_CLASS_DEVICE. > > * Replace a couple of select INPUT/VT with depends as it seemed to be > necessary. While doing 'depends on' instead of 'select' is an "easy" fix for this, I do dislike it quite a bit. It's a major pain to go around the kernel config, trying to find all the dependencies that a particular driver wants. If I need fb-foobar, I should just be able to enable it, instead of first searching and selecting its minor dependencies individually. So, not a NACK, but a "isn't there an another way to fix this?". Looking at backlight... BACKLIGHT_LCD_SUPPORT seems to be a "meta" option, it only enables a Kconfig submenu. So I think we could just remove the whole BACKLIGHT_LCD_SUPPORT option. But if we do that, all the items in drivers/video/backlight/Kconfig with default 'y' or 'm' would get enabled by default, so I think we should remove the 'default's from that file. That makes sense in any case, as I don't see why "HP Jornada 700 series LCD Driver" should be "default y". BACKLIGHT_CLASS_DEVICE doesn't depend on anything except BACKLIGHT_LCD_SUPPORT, so after removing BACKLIGHT_LCD_SUPPORT it should be safe to 'select' BACKLIGHT_CLASS_DEVICE. BACKLIGHT_CLASS_DEVICE could be made a hidden option, and the drivers in drivers/video/backlight/Kconfig which are under BACKLIGHT_CLASS_DEVICE could be made to select BACKLIGHT_CLASS_DEVICE instead. That doesn't exactly fix anything, but I think it makes sense as BACKLIGHT_CLASS_DEVICE is something that's selected from all around the kernel, so it should be a selectable "library" instead of a Kconfig menu option. I didn't look at the ACPI_VIDEO side, so no idea how messy that is. 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/20141022/d7c563e3/attachment.sig>
[PATCH 1/1] GPU-DRM-nouveau: Deletion of unnecessary checks before two function calls
>> If you are convinced that dropping the null tests is a good idea, then you
>> can submit the patch that makes the change to the relevant maintainers and
>> mailing lists.
Would you like to integrate the following proposal into your source code
repository?
Regards,
Markus
>From 29e61d5ccc44cd5e5961acff61b6938e0705044d Mon Sep 17 00:00:00 2001
From: Markus Elfring
Date: Wed, 22 Oct 2014 15:45:22 +0200
Subject: [PATCH] GPU-DRM-nouveau: Deletion of unnecessary checks before two
function calls
A semantic patch approach was proposed with the subject "[PATCH with
Coccinelle?] Deletion of unnecessary checks before specific function calls"
on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software
"Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract
of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions
which perform input parameter validation already. It is therefore not
needed that a similar safety check is repeated at the call site.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/nouveau/core/core/handle.c | 3 +--
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/handle.c
b/drivers/gpu/drm/nouveau/core/core/handle.c
index a490b80..75d0c2c 100644
--- a/drivers/gpu/drm/nouveau/core/core/handle.c
+++ b/drivers/gpu/drm/nouveau/core/core/handle.c
@@ -219,8 +219,7 @@ nouveau_handle_get_cinst(struct nouveau_object *engctx, u32
cinst)
void
nouveau_handle_put(struct nouveau_handle *handle)
{
- if (handle)
- nouveau_namedb_put(handle);
+ nouveau_namedb_put(handle);
}
int
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 5723807..5c29079 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -512,8 +512,7 @@ nouveau_drm_unload(struct drm_device *dev)
nouveau_vga_fini(drm);
nvif_device_fini(&drm->device);
- if (drm->hdmi_device)
- pci_dev_put(drm->hdmi_device);
+ pci_dev_put(drm->hdmi_device);
nouveau_cli_destroy(&drm->client);
return 0;
}
--
2.1.2
[PATCH 1/1] GPU-DRM-GMA500: Deletion of unnecessary checks before two function calls
>> If you are convinced that dropping the null tests is a good idea, then you
>> can submit the patch that makes the change to the relevant maintainers and
>> mailing lists.
Would you like to integrate the following proposal into your source code
repository?
Regards,
Markus
>From e61965bbcb143a54696fbd468989110519e41497 Mon Sep 17 00:00:00 2001
From: Markus Elfring
Date: Wed, 22 Oct 2014 18:28:12 +0200
Subject: [PATCH] GPU-DRM-GMA500: Deletion of unnecessary checks before two
function calls
A semantic patch approach was proposed with the subject "[PATCH with
Coccinelle?] Deletion of unnecessary checks before specific function calls"
on 2014-03-05.
https://lkml.org/lkml/2014/3/5/344
http://article.gmane.org/gmane.comp.version-control.coccinelle/3513/
This patch pattern application was repeated with the help of the software
"Coccinelle 1.0.0-rc22" on the source files for Linux 3.17.1. An extract
of the automatically generated update suggestions is shown here.
It was determined that the affected source code places call functions
which perform input parameter validation already. It is therefore not
needed that a similar safety check is repeated at the call site.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +--
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 +++--
drivers/gpu/drm/gma500/oaktrail_lvds.c | 3 +--
drivers/gpu/drm/gma500/psb_drv.c| 3 +--
drivers/gpu/drm/gma500/psb_intel_lvds.c | 9 +++--
5 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 4268bf2..0d69624 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -246,8 +246,7 @@ static void cdv_hdmi_destroy(struct drm_connector
*connector)
{
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 0b77039..8f24013 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -444,8 +444,7 @@ static void cdv_intel_lvds_destroy(struct drm_connector
*connector)
{
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
@@ -780,12 +779,10 @@ out:
failed_find:
mutex_unlock(&dev->mode_config.mutex);
printk(KERN_ERR "Failed find\n");
- if (gma_encoder->ddc_bus)
- psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+ psb_intel_i2c_destroy(gma_encoder->ddc_bus);
failed_ddc:
printk(KERN_ERR "Failed DDC\n");
- if (gma_encoder->i2c_bus)
- psb_intel_i2c_destroy(gma_encoder->i2c_bus);
+ psb_intel_i2c_destroy(gma_encoder->i2c_bus);
failed_blc_i2c:
printk(KERN_ERR "Failed BLC\n");
drm_encoder_cleanup(encoder);
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 0d39da6..49c5c415 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -411,8 +411,7 @@ failed_find:
mutex_unlock(&dev->mode_config.mutex);
dev_dbg(dev->dev, "No LVDS modes found, disabling.\n");
- if (gma_encoder->ddc_bus)
- psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+ psb_intel_i2c_destroy(gma_encoder->ddc_bus);
/* failed_ddc: */
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 6ec3a90..0efe165 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -210,8 +210,7 @@ static int psb_driver_unload(struct drm_device *dev)
iounmap(dev_priv->aux_reg);
dev_priv->aux_reg = NULL;
}
- if (dev_priv->aux_pdev)
- pci_dev_put(dev_priv->aux_pdev);
+ pci_dev_put(dev_priv->aux_pdev);
/* Destroy VBT data */
psb_intel_destroy_bios(dev);
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 88aad95..e73c3f9 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -561,8 +561,7 @@ void psb_intel_lvds_destroy(struct drm_connector *connector)
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv;
- if (lvds_p
[PATCH] drm/cirrus: bind also to qemu-xen-traditional
Ping?
On Tue, Aug 26, Olaf Hering wrote:
> Ping?
>
> On Thu, Jun 12, Olaf Hering wrote:
>
> > Ping?
> >
> > On Fri, Apr 11, Olaf Hering wrote:
> >
> > > qemu as used by xend/xm toolstack uses a different subvendor id.
> > > Bind the drm driver also to this emulated card.
> > >
> > > Signed-off-by: Olaf Hering
> > > ---
> > > drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> > > b/drivers/gpu/drm/cirrus/cirrus_drv.c
> > > index 953fc8a..848 100644
> > > --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> > > +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> > > @@ -31,6 +31,8 @@ static struct drm_driver driver;
> > > static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
> > > { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
> > > 0, 0 },
> > > + { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, PCI_VENDOR_ID_XEN,
> > > + 0x0001, 0, 0, 0 },
> > > {0,}
> > > };
> > >
[Bug 85107] A10-7800: Boot problems (CPU stuck) and dpm not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=85107 --- Comment #11 from Marcel Witte --- To check if it is a hardware problem or a problematic bios setting I installed openSUSE 13.1 in parallel, there I was able to test with fglrx. And it is working well, the power management is working and the clock is getting up to the max when running glxgears (tested with aticonfig --odgc). So this has to be a driver bug... Can you give me any hint how I can debug this problem? I'm a software engineer myself (but mostly Java) and can test patches or "play" with the code if you say me where... ;) -- 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/20141022/f26bd2bb/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #64 from Paul Menzel --- (In reply to Christian A?falg from comment #63) > I think / guess that I am having the same issues. I've got the same laptop, > running Arch Linux. Mostly, I've been using the proprietary catalyst driver, > since I never got the free driver working. The proprietary is working fine. Then you had more luck than I did. What FGLRX version do you use? > What is the issue here? You've been playing with timings for the physical > link to the internal panel? Is it so frickly? What would you need to fix the > issue? How can I help? I was just told to play with the timings, but I actually have no idea anymore, sorry. Also I do not use that laptop anymore, so I have no easy way to test that. Hopefully the developers will be able to help you. What Linux kernel versions did you try? -- 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/20141022/77547d31/attachment.html>
[Bug 85107] A10-7800: Boot problems (CPU stuck) and dpm not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=85107 --- Comment #12 from Alex Deucher --- Created attachment 108260 --> https://bugs.freedesktop.org/attachment.cgi?id=108260&action=edit disable some dpm features You might try this patch. If it helps try to narrow down which specific features are causing the problem. You might also check your bios configuration and see if any of those settings make a difference. All of the relevant power management code for your asic is in kv_dpm.c and kv_smc.c. -- 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/20141022/5efc0fca/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
ENCODER_CMD_DP_VIDEO_ON, 0); } - if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) - atombios_dig_transmitter_setup(encoder, - ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0); if (ext_encoder) atombios_external_encoder_setup(encoder, ext_encoder, ATOM_ENABLE); break; @@ -1705,10 +1702,6 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, int mode) } if (ext_encoder) atombios_external_encoder_setup(encoder, ext_encoder, ATOM_DISABLE); - if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) - atombios_dig_transmitter_setup(encoder, - ATOM_TRANSMITTER_ACTION_LCD_BLOFF, 0, 0); - if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(encoder)) && connector && !travis_quirk) radeon_dp_set_rx_power_state(connector, DP_SET_POWER_D3); -- 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/20141022/2432e6ea/attachment-0001.html>
tile property contents
On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger wrote: > I assume the TILE property described below would be per-connector? > > It looks like this would handle the DP MST tiled display case. > > At the risk of trying to solve too much at once: > > There are also configurations where users configure multiple heads to > drive power walls that they want to be treated as one logical monitor, > similar to the DP MST tiled display case. Normally, those powerwall > configurations don't have any layout information from the monitors > themselves, and the layout is configured by the user. > > Would it be appropriate for users to be able to set the TILE property > in that sort of scenario? > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc > should be expressed in pixels rather than tiles? Sometimes, the tiles > in those powerwalls may not all have the same resolution, or may be > configured with overlap. I suppose that would make the TILE configuration > specific to the current modetimings on each tile... Why can't users just set that mode? And if this is about the initial configuration problem then we (at intel) are working on some way to load a dt blob as a firmware image which would contain the entire kms state, and which we'd apply in an atomic modeset at driver load. Everyone else (boot splash, X, ...) will then just inherit that config. That should give you even flicker-free screen walls if you want to ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #66 from Christian A?falg --- Well, turns out that I may have said that too soon. ;) Gnome does not work anymore (gnome-session quits right after login), that may be an issue with gnome 3.14 and catalyst, not 100% sure. For some people it's working, for some it isn't. Now I'm using KDE, which kinda works, but I don't like it. It's ugly, it's different, and none of my typical workflows do what they did any more. But that's just ranting since I'm pissed at all those small issues with KDE. And at the 3 hours I thought my catalyst installation was broken when it was actually gnome which did not start. ;) Right now I use 3.16, the tests I did with the radeon driver which led me here were with 3.16. I could test 3.14 (arch's lts kernel) with relative ease. If I get some pointers what info to provide, or what to try, I can do that. Right now, I am clueless in how to debug further, where relevant info is written to and so on. -- 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/20141022/63677c4a/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #67 from Christian A?falg --- @comment65 Thanks for those hints. Trying that will take a couple of days. I need to figure out how to compile kernel modules in arch first. Is there a dev (you?) who lives in germany by any chance? Would it help / be possible that I mail the Laptop, so some dev can try it hands on? -- 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/20141022/ae65fea2/attachment.html>
[Bug 85204] [Radeon HD 5650] return from sleep state failed
https://bugs.freedesktop.org/show_bug.cgi?id=85204 --- Comment #5 from Rafael Pereira --- After bisecting, I found the first occurence (of the bug) on the following commit: git describe --contains 43c40df2c7fedce640a6c39fcdf58764f6bbac5c v3.17-rc1~83 -- 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/20141022/cf5c799e/attachment.html>
[Bug 85320] GPU hangs using hardware acceleration
https://bugs.freedesktop.org/show_bug.cgi?id=85320 --- Comment #10 from Eugene --- Recently I checked Mesa 10.1.3 stable. The same result: system hangs, display becomes dark. No possibility to switch to any VT. So, as I understood, this is not a regression. This is just new feature (for my graphics adapter) that comes with Linux 3.18. And it is very unstable. -- 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/20141022/9ac66717/attachment.html>
[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend
https://bugs.freedesktop.org/show_bug.cgi?id=84232
--- Comment #10 from Vitaliy Filippov ---
I've managed to make a reduced test case with a recursive PHI after
StructurizeCFG !!!
int main()
{
int i, j = 0;
while (j % 2)
{
if (j > 100)
j += 3;
else if (j > 50)
break;
}
return j;
}
clang-3.5 -S -emit-llvm test3.c
opt-3.5 -S -structurizecfg test3.ll > test3cfg.ll
Simple to visualise with graphviz:
( echo 'digraph G {'; perl -ne 'if (/\%(\S+) = phi/) { my $a = $1; print "$a ->
$_;\n" for /\[ \%([^\s,]+)/g; }' test3cfg.ll; echo '}' ) > test3cfg.dot
dot -Tsvg test3cfg.dot > test3cfg.svg
%21 and %26 phi's loop in the result.
Also there is a branch on constant in the end of test3cfg.ll:
br i1 false, label %14, label %Flow2
--
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/20141022/93093f58/attachment.html>
[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend
https://bugs.freedesktop.org/show_bug.cgi?id=84232 --- Comment #11 from Vitaliy Filippov --- Created attachment 108266 --> https://bugs.freedesktop.org/attachment.cgi?id=108266&action=edit StructurizeCFG IR output for the sample from comment 10 -- 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/20141022/46dbe489/attachment-0001.html>
[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend
https://bugs.freedesktop.org/show_bug.cgi?id=84232 --- Comment #12 from Vitaliy Filippov --- Hm... Checked the test from comment 6, the result is the same - there are two PHINode loops and one branch on constant. Also checked the code, it looks like crash from comment 6 is also triggered by a branch-on-constant, the difference is that it crashes when a ConstantInt is dyn_cast<>'ed to incorrect class - Instruction (ConstantInt isn't an Instruction!!) in handleLoopCondition() and getTerminator() is called on it. -- 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/20141022/8b2459b6/attachment.html>
tile property contents
On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote: > On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger wrote: > > I assume the TILE property described below would be per-connector? > > > > It looks like this would handle the DP MST tiled display case. > > > > At the risk of trying to solve too much at once: > > > > There are also configurations where users configure multiple heads to > > drive power walls that they want to be treated as one logical monitor, > > similar to the DP MST tiled display case. Normally, those powerwall > > configurations don't have any layout information from the monitors > > themselves, and the layout is configured by the user. > > > > Would it be appropriate for users to be able to set the TILE property > > in that sort of scenario? > > > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc > > should be expressed in pixels rather than tiles? Sometimes, the tiles > > in those powerwalls may not all have the same resolution, or may be > > configured with overlap. I suppose that would make the TILE configuration > > specific to the current modetimings on each tile... > > Why can't users just set that mode? Sure, users can set the mode, but: * Part of what the TILE property conveys is how monitors should be grouped for purposes of window maximization. Users don't have a great way to express that today, that I'm aware of. * Users might configure the mode they want, but then gnome-settings-daemon may come along later and decide it knows better than the user how things should be configured. One scenario where this comes up is: (a) user meticulously configures his power wall (b) user hotplugs another monitor I've definitely seen cases where window managers will try to be clever in response to a hotplug, and clobber the user's current configuration. If the TILE property conveyed how some set of monitors was supposed to be grouped, that would hopefully give window managers additional information, such that they would know to keep that group intact. > And if this is about the initial configuration problem then we (at > intel) are working on some way to load a dt blob as a firmware image > which would contain the entire kms state, and which we'd apply in an > atomic modeset at driver load. Everyone else (boot splash, X, ...) > will then just inherit that config. That should give you even > flicker-free screen walls if you want to ;-) Neat :) > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
