dri-devel April 2012

dri-devel@lists.freedesktop.org

119 participants
668 discussions

[PATCH 1/2] drm: exynos: Use DRM_FORMAT_{NV12, YUV420} instead of DRM_FORMAT_{NV12M, YUV420M}
by ville.syrjala＠linux.intel.com 21 Apr '12

21 Apr '12

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> The NV12M/YUV420M formats are identical to the already existing standard NV12/YUV420 formats. The M variants will be removed, so convert the driver to use the standard names. Cc: Inki Dae <inki.dae(a)samsung.com> Cc: Joonyoung Shim <jy0922.shim(a)samsung.com> Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- Extra note: Based on a quick look, the driver appears to lack sufficient sanity checks wrt. the framebuffer layout. I guess it just assumes that handles[0] != handles[1] and offsets[] = { 0 }. drivers/gpu/drm/exynos/exynos_drm_fb.h | 4 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h b/drivers/gpu/drm/exynos/exynos_drm_fb.h index 3ecb30d..5082375 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h @@ -31,10 +31,10 @@ static inline int exynos_drm_format_num_buffers(uint32_t format) { switch (format) { - case DRM_FORMAT_NV12M: + case DRM_FORMAT_NV12: case DRM_FORMAT_NV12MT: return 2; - case DRM_FORMAT_YUV420M: + case DRM_FORMAT_YUV420: return 3; default: return 1; diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 4d5f41e..f1e2369 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -370,7 +370,7 @@ static void vp_video_buffer(struct mixer_context *ctx, int win) switch (win_data->pixel_format) { case DRM_FORMAT_NV12MT: tiled_mode = true; - case DRM_FORMAT_NV12M: + case DRM_FORMAT_NV12: crcb_mode = false; buf_num = 2; break; -- 1.7.3.4

2 2

[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c
by ville.syrjala＠linux.intel.com 21 Apr '12

21 Apr '12

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> There will be a need for this function in drm_crtc.c later. This avoids making drm_crtc.c depend on drm_crtc_helper.c. Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/drm_crtc.c | 32 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_crtc_helper.c | 33 --------------------------------- include/drm/drm_crtc.h | 2 ++ include/drm/drm_crtc_helper.h | 2 -- 4 files changed, 34 insertions(+), 35 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index d2d9dc5..a99558e 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -3454,3 +3454,35 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, } } EXPORT_SYMBOL(drm_fb_get_bpp_depth); + +/** + * drm_format_num_planes - get the number of planes for format + * @format: pixel format (DRM_FORMAT_*) + * + * RETURNS: + * The number of planes used by the specified pixel format. + */ +int drm_format_num_planes(uint32_t format) +{ + switch (format) { + case DRM_FORMAT_YUV410: + case DRM_FORMAT_YVU410: + case DRM_FORMAT_YUV411: + case DRM_FORMAT_YVU411: + case DRM_FORMAT_YUV420: + case DRM_FORMAT_YVU420: + case DRM_FORMAT_YUV422: + case DRM_FORMAT_YVU422: + case DRM_FORMAT_YUV444: + case DRM_FORMAT_YVU444: + return 3; + case DRM_FORMAT_NV12: + case DRM_FORMAT_NV21: + case DRM_FORMAT_NV16: + case DRM_FORMAT_NV61: + return 2; + default: + return 1; + } +} +EXPORT_SYMBOL(drm_format_num_planes); diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index d9d6684..dc65e81 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -1017,36 +1017,3 @@ void drm_helper_hpd_irq_event(struct drm_device *dev) queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, 0); } EXPORT_SYMBOL(drm_helper_hpd_irq_event); - - -/** - * drm_format_num_planes - get the number of planes for format - * @format: pixel format (DRM_FORMAT_*) - * - * RETURNS: - * The number of planes used by the specified pixel format. - */ -int drm_format_num_planes(uint32_t format) -{ - switch (format) { - case DRM_FORMAT_YUV410: - case DRM_FORMAT_YVU410: - case DRM_FORMAT_YUV411: - case DRM_FORMAT_YVU411: - case DRM_FORMAT_YUV420: - case DRM_FORMAT_YVU420: - case DRM_FORMAT_YUV422: - case DRM_FORMAT_YVU422: - case DRM_FORMAT_YUV444: - case DRM_FORMAT_YVU444: - return 3; - case DRM_FORMAT_NV12: - case DRM_FORMAT_NV21: - case DRM_FORMAT_NV16: - case DRM_FORMAT_NV61: - return 2; - default: - return 1; - } -} -EXPORT_SYMBOL(drm_format_num_planes); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 9595c2c..697c072 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -1023,4 +1023,6 @@ extern int drm_mode_destroy_dumb_ioctl(struct drm_device *dev, extern void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, int *bpp); +extern int drm_format_num_planes(uint32_t format); + #endif /* __DRM_CRTC_H__ */ diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h index 37515d1..3add00e 100644 --- a/include/drm/drm_crtc_helper.h +++ b/include/drm/drm_crtc_helper.h @@ -145,6 +145,4 @@ extern void drm_helper_hpd_irq_event(struct drm_device *dev); extern void drm_kms_helper_poll_disable(struct drm_device *dev); extern void drm_kms_helper_poll_enable(struct drm_device *dev); -extern int drm_format_num_planes(uint32_t format); - #endif -- 1.7.3.4

6 14

[Bug 17902] [830M] need support for DVO-LVDS via na2501
by bugzilla-daemon＠freedesktop.org 20 Apr '12

20 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=17902 --- Comment #69 from Gilles Dartiguelongue <gilles.dartiguelongue(a)esiee.org> 2012-04-20 16:41:09 PDT --- I pushed the current state of the code here: https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f… I commented out dpms code for testing, but given the power of the machine it was quite long to get that out already so I'll fix that later. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[gma500] Fix screen blackouts
by Guillaume Clément 20 Apr '12

20 Apr '12

Hello, Since linux-3.3 I have been experiencing screen "blackouts" with the gma500_gfx driver. My laptop display would turn off and on again frequently. After activating the drm.debug=255 kernel option, the logs showed this during the blackout : [ 166.940676] [drm:psb_intel_sdvo_read_response], SDVOB: R: (Target not specified)... failed It appears that, for some reason, psb_intel_sdvo_read_reponse fails with status "Target not specified" during the polling for outputs. The driver then assumes the DPMS output is to be turned off and does so. Then the DPMS display is turned on again at the next poll. The staging driver (which worked with my card) called psb_intel_sdvo_read_byte until the status is successful. Now the driver fails if one of the returned status is neither pending nor success. It looks my card can return "target not specified" instead of pending. By considering "target not specified" like pending and waiting for another byte, everything works fine again. To sum things up : Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING which causes the display to be turned off. Signed-by: Guillaume Clement <gclement(a)baobob.org> Acked-by: Alan Cox <alan(a)linux.intel.com> --- diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c b/drivers/gpu/drm/gma500/psb_intel_sdvo.c index 36330ca..b3858bc 100644 --- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c +++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c @@ -498,7 +498,9 @@ static bool psb_intel_sdvo_read_response(struct psb_intel_sdvo *psb_intel_sdvo, &status)) goto log_fail; - while (status == SDVO_CMD_STATUS_PENDING && retry--) { + while ((status == SDVO_CMD_STATUS_PENDING + || status == SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED) + && retry--) { udelay(15); if (!psb_intel_sdvo_read_byte(psb_intel_sdvo, SDVO_I2C_CMD_STATUS,

1 0

[RFC 0/4] Add NVIDIA Tegra DRM support
by Thierry Reding 20 Apr '12

20 Apr '12

This series adds a basic DRM driver for NVIDIA Tegra 2 processors. It currently only supports the RGB output and I've successfully tested it against the fbcon kernel module and the xf86-video-modesetting driver. The code uses the Tegra's IOMMU/GART to remap non-contiguous memory. This means that currently video memory is limited to 32 MB, the size of the GART aperture. Note that this is very early work-in-progress and there is a lot of room for improvement and cleanup. You'll also note that there is still a whole lot of debugging output, most of which is disabled by default. However I explicitly wanted to post this early to get feedback and to discuss options on how to get this included in the mainline kernel. I have been in contact with some people at NVIDIA and they seem to be willing to work together on a solution that satisfies both their requirements and those of the community. Thierry Thierry Reding (3): iommu: tegra/gart: Add device tree support drm: fixed: Add dfixed_frac() macro drm: Add NVIDIA Tegra support Vandana Salve (1): iommu: tegra/gart: use correct gart_device .../devicetree/bindings/gpu/drm/tegra.txt | 24 + arch/arm/boot/dts/tegra20.dtsi | 6 + arch/arm/mach-tegra/board-dt-tegra20.c | 4 + arch/arm/mach-tegra/tegra2_clocks.c | 8 +- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/tegra/Kconfig | 10 + drivers/gpu/drm/tegra/Makefile | 5 + drivers/gpu/drm/tegra/tegra_drv.c | 2241 ++++++++++++++++++++ drivers/gpu/drm/tegra/tegra_drv.h | 184 ++ drivers/iommu/tegra-gart.c | 12 +- include/drm/drm_fixed.h | 1 + include/drm/tegra_drm.h | 44 + 13 files changed, 2537 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/drm/tegra.txt create mode 100644 drivers/gpu/drm/tegra/Kconfig create mode 100644 drivers/gpu/drm/tegra/Makefile create mode 100644 drivers/gpu/drm/tegra/tegra_drv.c create mode 100644 drivers/gpu/drm/tegra/tegra_drv.h create mode 100644 include/drm/tegra_drm.h -- 1.7.10

13 63

[PATCH 0/1] [RFC] DRM locking issues during early open
by Andy Whitcroft 20 Apr '12

20 Apr '12

We have been carrying a (rather poor) patch for an issue we identified in the DRM driver. This issue is triggered when a DRM device is initialising and userspace attempts to open it, typically in response to the sysfs device added event. Basically we allocate the minor numbers making the device available, and then call the drm load callback. Until this completes the device is really not ready and these early opens typically lead to oopses. We have been using the following patch to avoid this by marking the minors as in error until the load method has completed. This avoids the early open by simply erroring out the opens with EAGAIN. Obviously we should be delaying the open until the load method complete. I include the existing patch for completness (it is not really ready for merging) to illustrate the issue. I think it is logical that the wait should simply be delayed until the load has completed. I am proposing to include a wait queue associated with the idr cache for the drm minors which we can use to allow open callers to wait_event_interruptible() on. I'll be putting together a prototype shortly and will follow up with it. Thoughts? -apw Andy Whitcroft (1): drm -- stop early access to drm devices drivers/gpu/drm/drm_fops.c | 8 ++++++-- drivers/gpu/drm/drm_pci.c | 4 ++++ drivers/gpu/drm/drm_platform.c | 4 ++++ drivers/gpu/drm/drm_stub.c | 2 +- 4 files changed, 15 insertions(+), 3 deletions(-) -- 1.7.9.5

4 13

[Bug 27541] [830M] [KMS] internal display goes nuts during boot
by bugzilla-daemon＠freedesktop.org 20 Apr '12

20 Apr '12

https://bugs.freedesktop.org/show_bug.cgi?id=27541 Chris Wilson <chris(a)chris-wilson.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Chris Wilson <chris(a)chris-wilson.co.uk> 2012-04-20 08:38:31 PDT --- I believe this was the missing drm_mode_set_crtcinfo() bug. Please try a recent kernel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 42729] New: Monitor EDID handling causes system freezes every few seconds.
by bugzilla-daemon＠bugzilla.kernel.org 20 Apr '12

20 Apr '12

https://bugzilla.kernel.org/show_bug.cgi?id=42729 Summary: Monitor EDID handling causes system freezes every few seconds. Product: Drivers Version: 2.5 Kernel Version: 3.2.1-3.2.2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: subscription.discussion(a)gmail.com Regression: No Created an attachment (id=72281) --> (https://bugzilla.kernel.org/attachment.cgi?id=72281) dmesg Whenever my Compaq S9500 monitor is connected, the kernel outputs errors about invalid EDID checksum. The system also freezes for a couple of seconds every 5-10 seconds or so, possibly around the same time the errors are reported to the terminal. The problem can be circumvented by adding nomodeset to the kernel line, or disconnecting the monitor. However, using nomodeset seems to disable accelerated graphics, so neither of the fixes are very usable. The first time the problem occurred was when my Nvidia GPU (with proprietary drivers) broke and I had to switch to my old ATI Radeon GPU (with the open-source radeon driver). I have tried using two monitors and using only a single monitor, but the problem goes away only if the "broken" monitor is disconnected. I think the driver should just ignore the parts of the EDID that are invalid, instead of repeatedly doing something that makes the system unresponsive. I'm using a x86_64 Arch Linux, kernel 3.2.2-1-ARCH. GPU: Radeon X8xx (X800XL if I recall correctly, but lspci reports it as an "ATI Technologies Inc Radeon R423 UK [Radeon X800SE (PCIE)]. The X800XL, however, is R430 according to Wikipedia.) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 3

[PATCHv5 00/13] Integration of videobuf2 with dmabuf
by Tomasz Stanislawski 20 Apr '12

20 Apr '12

Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296… [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635… [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Andrzej Pietrasiewicz (1): v4l: vb2-dma-contig: add support for scatterlist in userptr mode Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (4): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: Remove unneeded allocation context structure v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation/DocBook/media/v4l/compat.xml | 4 + Documentation/DocBook/media/v4l/io.xml | 179 +++++++ .../DocBook/media/v4l/vidioc-create-bufs.xml | 1 + Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +- drivers/media/video/Kconfig | 1 + drivers/media/video/s5p-fimc/fimc-capture.c | 2 +- drivers/media/video/s5p-tv/Kconfig | 1 + drivers/media/video/s5p-tv/mixer_video.c | 2 +- drivers/media/video/videobuf-core.c | 4 + drivers/media/video/videobuf2-core.c | 207 ++++++++- drivers/media/video/videobuf2-dma-contig.c | 529 +++++++++++++++++--- include/linux/videodev2.h | 7 + include/media/videobuf2-core.h | 34 ++ 14 files changed, 932 insertions(+), 101 deletions(-) -- 1.7.5.4

1 1

[PATCH 1/2] drm/i915/tv: fix open-coded ARRAY_SIZE.
by Dave Airlie 20 Apr '12

20 Apr '12

From: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/i915/intel_tv.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index ca12c70..67f444d 100644 --- a/drivers/gpu/drm/i915/intel_tv.c +++ b/drivers/gpu/drm/i915/intel_tv.c @@ -811,7 +811,7 @@ intel_tv_mode_lookup(const char *tv_format) { int i; - for (i = 0; i < sizeof(tv_modes) / sizeof(tv_modes[0]); i++) { + for (i = 0; i < ARRAY_SIZE(tv_modes); i++) { const struct tv_mode *tv_mode = &tv_modes[i]; if (!strcmp(tv_format, tv_mode->name)) -- 1.7.7.6

3 3

← Newer
1
...
50
51
52
53
54
55
56
...
67
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2012