dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[PATCH 00/11] [RFC] drm_for_each_* macros and list locking
by Daniel Vetter 24 Jun '15

24 Jun '15

Hi all, Dave&I have been discussing connector hotplug and unplugging around DP MST and if there's one thing that's clear it's that we don't even really know where all the problems are. Hence first step is to figure that out. One of the bigger items is walking the encoder/connector lists without appropriate locking to protect against concurrent hotadd/removal of connectors. This patch series tries to untangle things a bit here. RFC since only lightly tested and missing conversion of the radoen mst code to the new locking scheme. I think rolling out the new macros for i915 should be done as a second step, to avoid hitting too many WARN_ON ;-) Cheers, Daniel Daniel Vetter (11): drm: Simplify drm_for_each_legacy_plane arguments drm: Add modeset object iterators drm/probe-helper: Grab mode_config.mutex in poll_init/enable drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors drm: Check locking in drm_for_each_encoder/connector drm/i915: Use drm_for_each_fb in i915_debugfs.c drm: Check locking in drm_for_each_fb drm/i915: Take all modeset locks for DP MST hotplug drm: Amend connector/encoder list locking rules drm: Roll out drm_for_each_connector more drm: Roll out drm_for_each_{plane,crtc,encoder} drivers/gpu/drm/drm_atomic.c | 2 +- drivers/gpu/drm/drm_atomic_helper.c | 4 +-- drivers/gpu/drm/drm_crtc.c | 56 +++++++++++++++---------------- drivers/gpu/drm/drm_crtc_helper.c | 42 +++++++++++------------ drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 19 +++++++---- drivers/gpu/drm/drm_modeset_lock.c | 7 ++-- drivers/gpu/drm/drm_of.c | 2 +- drivers/gpu/drm/drm_plane_helper.c | 3 +- drivers/gpu/drm/drm_probe_helper.c | 45 +++++++++++++++---------- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++- drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++---- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- include/drm/drm_crtc.h | 33 ++++++++++++++++-- 16 files changed, 140 insertions(+), 97 deletions(-) -- 2.1.4

3 15

[PATCH 1/1]drm/gma500: mdfld: Remove unncessary code
by Maninder Singh 24 Jun '15

24 Jun '15

sender is dereferrenced before NULL check struct drm_device *dev = sender->dev; and due to this we get warning during static analysis: warn: variable dereferenced before check 'sender' __read_panel_data Function is called by mdfld_dsi_read_mcs and there is a same check, Thus removing the check from __read_panel_data. Signed-off-by: Maninder Singh <maninder1.s(a)samsung.com> Reviewed-by: Vaneet Narang <v.narang(a)samsung.com> --- drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c index 6b43ae3..d29b881 100644 --- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c +++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c @@ -525,11 +525,6 @@ static int __read_panel_data(struct mdfld_dsi_pkg_sender *sender, u8 data_type, u32 gen_data_reg; int retry = MDFLD_DSI_READ_MAX_COUNT; - if (!sender || !data_out || !len_out) { - DRM_ERROR("Invalid parameters\n"); - return -EINVAL; - } - /** * do reading. * 0) send out generic read request -- 1.7.1

2 1

[RFC PATCH] Trim 1204 bytes from gm204_grctx_generate_405b60 stack frame
by George Spelvin 24 Jun '15

24 Jun '15

This function keeps causing the kernel build to whine at me about its 1200 byte stack frame. (TPC_MAC = 8 * GPC_MAX = 8 * 32 = 256) The following generates the same nv_wr32() operations in the same order as the original, but without the 256-word dist[] array. (I'm not sure if 4-bit fields inside the dist bytes can accomodate priv->gpc_nr greater than 16, so the other arrays could have halved in size, too, but that's a separate issue.) I don't have the necessary hardware to test this, but would someone mind doing so? (If you want to declare *priv const while you're at it, I'm not likely to object.) Signed-off-by: George Spelvin <linux(a)horizon.com> --- drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c index ea8e6615..00aa4a8b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c @@ -946,8 +946,7 @@ gm204_grctx_generate_rop_active_fbps(struct gf100_gr_priv *priv) static void gm204_grctx_generate_405b60(struct gf100_gr_priv *priv) { - const u32 dist_nr = DIV_ROUND_UP(priv->tpc_total, 4); - u32 dist[TPC_MAX] = {}; + u32 dist = 0; u32 gpcs[GPC_MAX] = {}; u8 tpcnr[GPC_MAX]; int tpc, gpc, i; @@ -964,12 +963,16 @@ gm204_grctx_generate_405b60(struct gf100_gr_priv *priv) } while(!tpcnr[gpc]); tpc = priv->tpc_nr[gpc] - tpcnr[gpc]--; - dist[i / 4] |= ((gpc << 4) | tpc) << ((i % 4) * 8); + dist |= ((gpc << 4) | tpc) << ((i % 4) * 8); + if ((i % 4) == 3) { + nv_wr32(priv, 0x405b60 + i - 3, dist); + dist = 0; + } gpcs[gpc] |= i << (tpc * 8); } + if (i % 4) + nv_wr32(priv, 0x405b60 + round_down(i, 4), dist); - for (i = 0; i < dist_nr; i++) - nv_wr32(priv, 0x405b60 + (i * 4), dist[i]); for (i = 0; i < priv->gpc_nr; i++) nv_wr32(priv, 0x405ba0 + (i * 4), gpcs[i]); }

1 1

mx6 hdmi resolution behaviour
by Fabio Estevam 23 Jun '15

23 Jun '15

Hi, On a imx6q-cubox-i running 4.1 kernel I am getting 1920x1080 HDMI resolution if I boot the board with the HDMI cable connected. If I boot it without the HDMI cable and then connect it afterwards, the resolution goes to only 1024 x 768 and the following IPU message is seen: [ 16.310548] imx-ipuv3 2400000.ipu: videomode adapted for IPU restrictions Shouldn't we get 1920x1080 in this case as well? Regards, Fabio Estevam

3 7

[PATCH 0/5] drm/omap: various small fixes
by Tomi Valkeinen 23 Jun '15

23 Jun '15

Hi, Here are a few small fixes for omapdrm. These are based on the recent omapdrm atomic modesetting series, which is now in drm-next. Tomi Tomi Valkeinen (5): drm/omap: return error if dma_alloc_writecombine fails drm/omap: check that plane is inside crtc drm/omap: increase DMM transaction timeout drm/omap: fix omap_framebuffer_unpin() error handling drm/omap: fix omap_gem_put_paddr() error handling drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++-- drivers/gpu/drm/omapdrm/omap_fb.c | 16 ++++------------ drivers/gpu/drm/omapdrm/omap_gem.c | 20 +++++++++++++------- drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++++++++++++++++++++++++++ 5 files changed, 46 insertions(+), 22 deletions(-) -- 2.1.4

2 12

[PATCH] drm: rcar-du: Remove obsolete rcar-du-r8a779x platform_device_id entries
by Geert Uytterhoeven 23 Jun '15

23 Jun '15

Since commit a483dcbfa21f919c ("ARM: shmobile: lager: Remove legacy board support"), R-Car Gen2 SoCs are only supported in generic DT-only ARM multi-platform builds. The driver doesn't need to match platform devices by name anymore, hence remove the corresponding platform_device_id entry. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 780ca11512ba6cf1..fb6709160a591a4d 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -108,8 +108,6 @@ static const struct rcar_du_device_info rcar_du_r8a7791_info = { static const struct platform_device_id rcar_du_id_table[] = { { "rcar-du-r8a7779", (kernel_ulong_t)&rcar_du_r8a7779_info }, - { "rcar-du-r8a7790", (kernel_ulong_t)&rcar_du_r8a7790_info }, - { "rcar-du-r8a7791", (kernel_ulong_t)&rcar_du_r8a7791_info }, { } }; -- 1.9.1

2 1

[patch -next] drm/radeon: missing break statement
by Dan Carpenter 23 Jun '15

23 Jun '15

There was a merge problem in linux-next 4598d330d29e ('Merge remote-tracking branch 'drm/drm-next''). We need to add a break statement. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index b4b457d..4a119c2 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -578,6 +578,7 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file break; case RADEON_INFO_VA_UNMAP_WORKING: *value = true; + break; case RADEON_INFO_GPU_RESET_COUNTER: *value = atomic_read(&rdev->gpu_reset_counter); break;

3 2

[PATCH] drm/vgem: Set unique to "vgem"
by Daniel Vetter 23 Jun '15

23 Jun '15

Since there's only one global instance ever we don't need to have anything fancy. Stops a WARNING in the get_unique ioctl that the unique name isn't set. Cc: <stable(a)vger.kernel.org> # 4.1+ only Reportedy-and-tested-by: Fabio Coatti <fabio.coatti(a)gmail.com> Cc: Fabio Coatti <fabio.coatti(a)gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/vgem/vgem_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 7a207ca547be..6394547cf67a 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -328,6 +328,8 @@ static int __init vgem_init(void) goto out; } + drm_dev_set_unique(vgem_device, "vgem"); + ret = drm_dev_register(vgem_device, 0); if (ret) -- 2.1.4

1 0

Linux 4.1 WARNING in drm_ioctl.c
by Fabio Coatti 23 Jun '15

23 Jun '15

Hi All, just compiled 4.1 and just got this warning, twice, in my dmesg: [lun giu 22 11:43:18 2015] ------------[ cut here ]------------ [lun giu 22 11:43:18 2015] WARNING: CPU: 1 PID: 2184 at drivers/gpu/drm/drm_ioctl.c:144 drm_setversion+0xe1/0x179() [lun giu 22 11:43:18 2015] No drm_driver.set_busid() implementation provided by 0xffffffff81ec3980. Use drm_dev_set_unique() to set the unique name explicitly. [lun giu 22 11:43:18 2015] Modules linked in: [lun giu 22 11:43:18 2015] bnep algif_skcipher cdc_wdm cdc_acm uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev btusb btbcm btintel bluetooth hp_wmi sparse_keymap intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi coretemp kvm_intel kvm snd_hda_codec_generic crct10dif_pclmul crc32_pclmul snd_hda_intel iwldvm snd_hda_controller snd_hda_codec snd_hwdep psmouse snd_hda_core iwlwifi snd_pcm snd_timer snd soundcore wmi hp_accel(+) hp_wireless lis3lv02d sch_fq_codel dm_zero dm_persistent_data dm_service_time dm_round_robin dm_queue_length dm_multipath dm_delay virtio_pci virtio_blk virtio_balloon virtio_ring virtio fuse overlay linear raid0 dm_raid dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log ohci_pci ohci_hcd uhci_hcd [lun giu 22 11:43:18 2015] CPU: 1 PID: 2184 Comm: X Tainted: G W 4.1.0 #1 [lun giu 22 11:43:18 2015] Hardware name: Hewlett-Packard HP EliteBook Folio 9470m/18DF, BIOS 68IBD Ver. F.40 02/01/2013 [lun giu 22 11:43:18 2015] 0000000000000000 0000000000000009 ffffffff818d8bfd ffff8800b226fd38 [lun giu 22 11:43:18 2015] ffffffff810c5426 ffff880235437240 ffffffff8152870c ffff8800b2f16000 [lun giu 22 11:43:18 2015] ffff880234ffc000 ffff8800b226fdf0 ffff8800b2c8f300 00000000c0106407 [lun giu 22 11:43:18 2015] Call Trace: [lun giu 22 11:43:18 2015] [<ffffffff818d8bfd>] ? dump_stack+0x47/0x67 [lun giu 22 11:43:18 2015] [<ffffffff810c5426>] ? warn_slowpath_common+0x9d/0xb5 [lun giu 22 11:43:18 2015] [<ffffffff8152870c>] ? drm_setversion+0xe1/0x179 [lun giu 22 11:43:18 2015] [<ffffffff810c5488>] ? warn_slowpath_fmt+0x4a/0x4f [lun giu 22 11:43:18 2015] [<ffffffff8152870c>] ? drm_setversion+0xe1/0x179 [lun giu 22 11:43:18 2015] [<ffffffff81528465>] ? drm_ioctl+0x376/0x3dd [lun giu 22 11:43:18 2015] [<ffffffff8152862b>] ? drm_version+0x8d/0x8d [lun giu 22 11:43:18 2015] [<ffffffff811ca766>] ? do_filp_open+0x30/0x74 [lun giu 22 11:43:18 2015] [<ffffffff811cc591>] ? do_vfs_ioctl+0x379/0x431 [lun giu 22 11:43:18 2015] [<ffffffff811d4784>] ? __fd_install+0x20/0x52 [lun giu 22 11:43:18 2015] [<ffffffff811bccab>] ? do_sys_open+0x1c0/0x1d2 [lun giu 22 11:43:18 2015] [<ffffffff811cc687>] ? SyS_ioctl+0x3e/0x5a [lun giu 22 11:43:18 2015] [<ffffffff818e0d9b>] ? system_call_fastpath+0x16/0x6e [lun giu 22 11:43:18 2015] ---[ end trace 46364eedd82ef148 ]--- It does not seems to affect normal behaviour, but maybe the report could be interesting for maintainers. Sorry if this has already been reported; if more information is needed just let me know (please CC: me as I'm not subscribed to lists.) Many thanks. -- Fabio

3 7

[PATCH Resend] of: fix a build error to f_graph_get_endpoint_by_regs function
by Inki Dae 23 Jun '15

23 Jun '15

This patch fixes the below build error reported by Stephen, Stephen reported: After merging the drm-exynos tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs': adv7604.c:(.text+0x586c): multiple definition of `of_graph_get_endpoint_by_regs' drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here drivers/media/platform/soc_camera/atmel-isi.o: In function `of_graph_get_endpoint_by_regs': atmel-isi.c:(.text+0x1ec9): multiple definition of `of_graph_get_endpoint_by_regs' drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): first defined here drivers/media/platform/soc_camera/rcar_vin.o: In function `of_graph_get_endpoint_by_regs': rcar_vin.c:(.text+0x307c): multiple definition of `of_graph_get_endpoint_by_regs' drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): first defined here Caused by commit: a0f7001c18ca ("of: add helper for getting endpoint node of specific identifiers") To fix the error, this patch declares of_graph_get_endpoint_by_regs function with "static inline". Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- include/linux/of_graph.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h index 1c1d5b9..f8bcd0e 100644 --- a/include/linux/of_graph.h +++ b/include/linux/of_graph.h @@ -71,7 +71,7 @@ static inline struct device_node *of_graph_get_next_endpoint( return NULL; } -struct device_node *of_graph_get_endpoint_by_regs( +static inline struct device_node *of_graph_get_endpoint_by_regs( const struct device_node *parent, int port_reg, int reg) { return NULL; -- 1.7.9.5

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015