dri-devel April 2014

dri-devel@lists.freedesktop.org

153 participants
962 discussions

[PATCH] drm/nouveau/clk: fix possible NULL pointer dereference
by Daeseok Youn 15 Apr '14

15 Apr '14

It need to be checking NULL before dereferencing. Signed-off-by: Daeseok Youn <daeseok.youn(a)gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/clock/base.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c index dd62bae..a586d030 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/clock/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/clock/base.c @@ -290,9 +290,9 @@ nouveau_pstate_new(struct nouveau_clock *clk, int idx) return 0; pstate = kzalloc(sizeof(*pstate), GFP_KERNEL); - cstate = &pstate->base; if (!pstate) return -ENOMEM; + cstate = &pstate->base; INIT_LIST_HEAD(&pstate->list); -- 1.7.4.4

3 2

[PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit
by Andrzej Hajda 15 Apr '14

15 Apr '14

Hi Inki, This patchset refactors drm device initialization. Details are described in respective patches. It is an alternative to DT supernode concept. The first patch uses linker sections to get rid of ifdef macros, it is not essential for 2nd patch but it makes code more readable. Similar approach is used by irqchip, clks and clk_sources. The patchset is based on exynos-drm-next branch. Regards Andrzej Andrzej Hajda (2): drm/exynos: refactor drm drivers registration code drm/exynos: initialize drm master only when all exynos drm devices are ready drivers/gpu/drm/exynos/Makefile | 2 + drivers/gpu/drm/exynos/exynos_dp_core.c | 37 ++-- drivers/gpu/drm/exynos/exynos_drm.lds.S | 9 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 +++++++++++++--------------- drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 +- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 42 +++-- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 35 ++-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 38 ++-- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 17 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 30 +-- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 18 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 27 ++- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 18 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 53 ++++-- drivers/gpu/drm/exynos/exynos_mixer.c | 14 +- 15 files changed, 360 insertions(+), 279 deletions(-) create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S -- 1.8.3.2

3 9

linux-next: manual merge of the drm-intel tree with the tree
by Stephen Rothwell 15 Apr '14

15 Apr '14

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/i915_gem_context.c between commit 691e6415c891 ("drm/i915: Always use kref tracking for all contexts") from the drm-intel-fixes tree and commit ad2ac08bf34b ("drm/i915: Make contexts non-snooped on non-LLC platforms") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwell sfr(a)canb.auug.org.au diff --cc drivers/gpu/drm/i915/i915_gem_context.c index d72db15afa02,30b355afb362..000000000000 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@@ -231,32 -232,40 +231,40 @@@ __create_hw_context(struct drm_device * return ERR_PTR(-ENOMEM); kref_init(&ctx->ref); - ctx->obj = i915_gem_alloc_object(dev, dev_priv->hw_context_size); - INIT_LIST_HEAD(&ctx->link); - if (ctx->obj == NULL) { - kfree(ctx); - DRM_DEBUG_DRIVER("Context object allocated failed\n"); - return ERR_PTR(-ENOMEM); - } + list_add_tail(&ctx->link, &dev_priv->context_list); - /* - * Try to make the context utilize L3 as well as LLC. - * - * On VLV we don't have L3 controls in the PTEs so we - * shouldn't touch the cache level, especially as that - * would make the object snooped which might have a - * negative performance impact. - */ - if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev)) { - ret = i915_gem_object_set_cache_level(ctx->obj, - I915_CACHE_L3_LLC); - /* Failure shouldn't ever happen this early */ - if (WARN_ON(ret)) + if (dev_priv->hw_context_size) { + ctx->obj = i915_gem_alloc_object(dev, dev_priv->hw_context_size); + if (ctx->obj == NULL) { + ret = -ENOMEM; goto err_out; - } + } - if (INTEL_INFO(dev)->gen >= 7) { - list_add_tail(&ctx->link, &dev_priv->context_list); ++ /* ++ * Try to make the context utilize L3 as well as LLC. ++ * ++ * On VLV we don't have L3 controls in the PTEs so we ++ * shouldn't touch the cache level, especially as that ++ * would make the object snooped which might have a ++ * negative performance impact. ++ */ ++ if (INTEL_INFO(dev)->gen >= 7 && !IS_VALLEYVIEW(dev)) { + ret = i915_gem_object_set_cache_level(ctx->obj, + I915_CACHE_L3_LLC); + /* Failure shouldn't ever happen this early */ + if (WARN_ON(ret)) + goto err_out; + } + } /* Default context will never have a file_priv */ - if (file_priv == NULL) - return ctx; - - ret = idr_alloc(&file_priv->context_idr, ctx, DEFAULT_CONTEXT_ID, 0, - GFP_KERNEL); - if (ret < 0) - goto err_out; + if (file_priv != NULL) { + ret = idr_alloc(&file_priv->context_idr, ctx, + DEFAULT_CONTEXT_ID, 0, GFP_KERNEL); + if (ret < 0) + goto err_out; + } else + ret = DEFAULT_CONTEXT_ID; ctx->file_priv = file_priv; ctx->id = ret;

1 0

[PATCH 0/4] drm: exynos: update/fixes to HDMI driver
by Tomasz Stanislawski 15 Apr '14

15 Apr '14

Hi everyone, This patchset adds 4 fixes/updates to EXYNOS DRM driver for HDMI subsystem. All comments are welcome. Regards, Tomasz Stanislawski Tomasz Stanislawski (4): drm: exynos: hdmi: simplify extracting hpd-gpio from DT drm: exynos: mixer: fix using usleep() in atomic context drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC drm: exynos: hdmi: add support for pixel clock limitation .../devicetree/bindings/video/exynos_hdmi.txt | 4 +++ drivers/gpu/drm/exynos/exynos_hdmi.c | 26 ++++++++++++++------ drivers/gpu/drm/exynos/exynos_mixer.c | 5 +++- include/media/s5p_hdmi.h | 1 + 4 files changed, 27 insertions(+), 9 deletions(-) -- 1.7.9.5

2 6

[PATCH 0/7] Reorder i.MX IPU display enable/disable sequence
by Philipp Zabel 14 Apr '14

14 Apr '14

Repeatedly enabling and disabling the display currently can lead to a state in which the IPU doesn't produce a valid signal anymore because we disable IPU submodules before they can finish their interaction. This series reorders the enable/disable sequence so that we first wait for the DC/DP to finish processing the current frame, then stop the DI and IDMAC, and only then disable clocks to the submodules. Also from now on we disable the DC when it is not in use. regards Philipp Philipp Zabel (7): imx-drm: ipu-common: add ipu_map_irq to request non-IDMAC interrupts imx-drm: ipu-common: Add helpers to check for a busy IDMAC channel and to busywait for an interrupt imx-drm: ipu-dmfc: Wait for FIFOs to run empty before disabling imx-drm: ipu-dc: Wait for DC_FC_1 / DP_SF_END interrupt imx-drm: ipu-dp: Split disabling the DP foreground channel from disabling the DP module imx-drm: imx-dp: When disabling the DP foreground channel, wait until the DP background channel is finished before disabling the IDMAC channel imx-drm: ipuv3-crtc: Change display enable/disable order drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 3 ++ drivers/staging/imx-drm/ipu-v3/ipu-common.c | 41 ++++++++++++++--- drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 71 ++++++++++++++++++++--------- drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c | 25 +++++++++- drivers/staging/imx-drm/ipu-v3/ipu-dp.c | 71 +++++++++++++++++++---------- drivers/staging/imx-drm/ipu-v3/ipu-prv.h | 3 ++ drivers/staging/imx-drm/ipuv3-crtc.c | 10 ++-- drivers/staging/imx-drm/ipuv3-plane.c | 4 ++ 8 files changed, 173 insertions(+), 55 deletions(-) -- 1.9.1

2 10

Re: [PATCH 2/4] staging: imx-hdmi: correct connector detect and hotplug
by Russell King - ARM Linux 14 Apr '14

14 Apr '14

On Mon, Apr 14, 2014 at 10:42:32AM +0200, Lucas Stach wrote: > Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM > Linux: > > On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote: > > > Make sure that we probe for a display on detect regardless > > > of previous hotplug events. Don't handle connector > > > hotplug state ourselves, but let DRM do the right thing > > > for us. This brings our hotplug handling in line with > > > what other DRM drivers do. > > > > Why should working setups have to pay the price for faulty setups when we > > can adequately detect the hotplug signal on iMX SoCs when it's correctly > > wired? > > > > By "price" I mean - if we end up having to poll the connector, we end up > > calling the i2c functions, and the i2c functions on iMX use a fixed > > timeout of 100ms. That means the context which runs the > > imx_hdmi_connector_detect() function is forced to sleep for 100ms. If > > that's being run as part of a softirq (eg, via a work struct), that's > > bad news because that could be any thread in the system. > > > > The "price" should only be paid by those implementations where the hotplug > > signal is not correctly wired. > > > This change is not related to broken systems. It just uses the DRM > framework as intended. The detect() callback, which triggers the EDID > fetch will only be called by DRM when a hotplug event was received, or > if someone (e.g. kms_fb_helper, or userspace) explicitly requests to > poll the connector. > > Not doing so is working around the DRM framework, not using it. So as > mentioned this change just brings us in line with what other DRM drivers > do to handle hotplug and connector detect. I totally disagree with that. What we're doing today using HPD to detect connection is entirely in keeping with DRM and the HDMI spec, and is more correct than your solution using EDID to detect the presence of a connection. HPD in HDMI indicates that the EDID is available for reading. There is no need what so ever to try reading the EDID to detect whether a device is present. Moreover, the HDMI spec does not say what state the DDC signals will be when the sink is powered off - it seems to me that it is entirely reasonable when HPD is lowered due to the sink being powered off that the DDC signals may be clamped to logic zero by ESD diodes in the sink, which would cause problems when trying to detect by reading the EDID. Moreover, it is quite legal for a sink to modify the contents of its EEPROM - and it can do this by manipulating the DDC signals itself. Polling the EDID would open the possibilities of races, reading the EDID before the sink had finished updating it. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.

2 4

DRM security flaws and security levels.
by Thomas Hellstrom 14 Apr '14

14 Apr '14

Hi, as was discussed a while ago, there are some serious security flaws with the current drm master model, that allows a user that had previous access or current access to an X server terminal to access the GPU memory of the active X server, without being authenticated to the X server and thereby also access other user's secret information Scenario 1a) User 1 uses the X server, then locks the screen. User 2 then VT switches, perhaps using fast user-switching, opens a DRM connection and becomes authenticated with itself. It then starts to guess GEM names used by the switched-away X server and open the corresponding objects. Then mmaps those objects and dumps data. Scenario 1b) As in 1, but instead of mmaping the GEM objects, crafts a command buffer that dumps all GPU memory to a local buffer and copies it out. Scenario 2 User 1 logs in on X. Starts a daemon that authenticates with X. Then logs out. User 2 logs in. User 1's daemon can now access data in a similar fashion to what's done in 1a and 1b. I don't think any driver is immune against all these scenarios. I think all GEM drivers are vulnerable to 1a) and 2a), but that could be easily fixed by only allowing GEM open of shared buffers from the same master. I'm not sure about 1b) and 2b) but according to the driver developers, radeon and noveau should be safe. vmwgfx should be safe against 1) but not currently against 2 because the DRM fd is being kept open across X server generations. I think these flaws can be fixed in all modern drivers. For a) type scenarios, refuse open of shared buffers that belong to other masters, and on new X server generations, release the old master completely by closing the FD or a special ioctl that releases master instead of drops master. For b) type scenarios, either provide a command verifier, per fd virtual GPU memory or for simpler hardware: throw out all GPU memory on master drop and block ioctls requiring authentication until master becomes active again. In any case, before enabling render nodes for drm we discussed a sysfs attribute that stated the security level of the device, so that udev could set up permissions accordingly. My suggestion is: -1: The driver allows an authenticated client to craft command streams that could access any part of system memory. These drivers should be kept in staging until they are fixed. 0: Drivers that are vulnerable to any of the above scenarios. 1: Drivers that are immune against all above scenarios but allows any authenticated client with *active* master to access all GPU memory. Any enabled render nodes will be insecure, while primary nodes are secure. 2: Drivers that are immune against all above scenarios and can protect clients from accessing eachother's gpu memory: Render nodes will be secure. Thoughts? Thomas

5 7

[PATCH] drm: fix memory leak in msm_gem when no iommu is present
by Micah Richert 14 Apr '14

14 Apr '14

Signed-off-by: Micah Richert <richert(a)braincorporation.com> --- drivers/gpu/drm/msm/msm_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index e8458bc..c818a06 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -118,8 +118,10 @@ static void put_pages(struct drm_gem_object *obj) if (iommu_present(&platform_bus_type)) drm_gem_put_pages(obj, msm_obj->pages, true, false); - else + else { drm_mm_remove_node(msm_obj->vram_node); + drm_free_large(msm_obj->pages); + } msm_obj->pages = NULL; } -- 1.8.3.2

2 1

[PATCH] drm: exynos: hdmi: simplify extracting hpd-gpio from DT
by Tomasz Stanislawski 14 Apr '14

14 Apr '14

This patch eliminates redundant checks while retrieving HPD gpio from DT during HDMI's probe(). Signed-off-by: Tomasz Stanislawski <t.stanislaws(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_hdmi.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index e1a2e88..300c2af 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2011,23 +2011,18 @@ static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata { struct device_node *np = dev->of_node; struct s5p_hdmi_platform_data *pd; - u32 value; pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL); if (!pd) - goto err_data; + return NULL; - if (!of_find_property(np, "hpd-gpio", &value)) { + pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, NULL); + if (pd->hpd_gpio < 0) { DRM_ERROR("no hpd gpio property found\n"); - goto err_data; + return NULL; } - pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0); - return pd; - -err_data: - return NULL; } static struct of_device_id hdmi_match_types[] = {

2 1

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen
by bugzilla-daemon＠bugzilla.kernel.org 14 Apr '14

14 Apr '14

https://bugzilla.kernel.org/show_bug.cgi?id=50091 --- Comment #34 from Dzianis Kahanovich <mahatma(a)bspu.unibel.by> --- OOPS! Crushed now. No fix ;( -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

← Newer
1
...
77
78
79
80
81
82
83
...
97
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2014