dri-devel June 2012

dri-devel@lists.freedesktop.org

125 participants
696 discussions

[PATCH 00/25] i915 HW context support
by Ben Widawsky 14 Jun '12

14 Jun '12

Setting myself up for a late night crying session once again. Most of the people reading this probably know the history and reasons for the patches. If not, you can search the intel-gfx mailing list to try to learn more. I won't recap the whole thing here, and instead let the patches speak for themselves. Instead a brief review of what's here, and what's happened. Mostly, these badly need testing and review. I've carried these around for so long now, and seen so many different failures, I'm quite paranoid they still aren't perfect. Also, I've spent almost all of the time working on this in the kernel, so there is bound to be simple errors in the other stuff. I've run these on various workloads and saw nothing worth mentioning. 0-16: kernel patches 17-21: libdrm patches (wait render patch is temporary) 22-24: inetl-gpu-tools 25: mesa kernel git://people.freedesktop.org/~bwidawsk/drm-intel context_support_rev2 libdrm git://people.freedesktop.org/~bwidawsk/drm context_support_rev2 i-g-t git://people.freedesktop.org/~bwidawsk/intel-gpu-tools context_support -- 1.7.10.2

5 14

[RFC] i.MX DRM devicetree binding
by Sascha Hauer 14 Jun '12

14 Jun '12

Hi All, The following is an attempt to come up with a devicetree binding for DRM graphics on i.MX SoCs. I'm posting this seperate from the actual code to not bury this in big patches. The bindings should cover most of the problems we had while implementing the possible IPU <-> (LVDS, HDMI, parallel) Display connections. Contrary to some other devicetree bindings I have seen we decided not to make the displays subnodes of the graphics unit because the (LVDS, HDMI) encoders are outside the graphics units and also on i.MX6 there are 2 IPUs and displays can be muxed between these IPUs. Comments and suggestions welcome. Sascha 8<-------------------------------------- DRM i.MX: Add devicetree binding documentation Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- .../devicetree/bindings/drm/fsl-imx-drm.txt | 126 ++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/fsl-imx-drm.txt diff --git a/Documentation/devicetree/bindings/drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/drm/fsl-imx-drm.txt new file mode 100644 index 0000000..6766e03 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/fsl-imx-drm.txt @@ -0,0 +1,126 @@ +Freescale i.MX IPUv3 +==================== + +Required properties: +- compatible: Should be "fsl,<chip>-ipu" +- reg: should be register base and length as documented in the + datasheet +- interrupts: Should contain sync interrupt and error interrupt, + in this order. +- #crtc-cells: 1, See below + +example: + +ipu: ipu@18000000 { + #crtc-cells = <1>; + compatible = "fsl,imx53-ipu"; + reg = <0x18000000 0x080000000>; + interrupts = <11 10>; +}; + +Freescale i.MX LCDC controller +============================== + +Required properties: +- compatible: Should be "fsl,<chip>-lcdc" +- reg: should be register base and length as documented in the + datasheet +- interrupts: Should contain interrupt +- #crtc-cells: 0, See below + +example: + +lcdc: lcdc@10021000 { + #crtc-cells = <0>; + compatible = "fsl,imx27-lcdc", "fsl,imx21-lcdc"; + reg = <0x10021000 0x4000>; + interrupts = <61>; +}; + +Parallel display support +======================== + +Required properties: +- compatible: Should be "fsl,imx-parallel-display" +- crtc: the crtc this display is connected to, see below +Optional properties: +- interface_pix_fmt: How this display is connected to the + crtc. Currently supported types: "rgb24", "rgb565" +- edid: verbatim EDID data block describing attached display. +- ddc: phandle describing the i2c bus handling the display data + channel + +example: + +display@di0 { + compatible = "fsl,imx-parallel-display"; + edid = [edid-data]; + crtc = <&ipu 0>; + interface_pix_fmt = "rgb24"; +}; + +LVDS display bridge (LDB) +========================= + +Required properties: +- compatible: Should be "fsl,<chip>-ldb" +- channel0-crtcs, channel1-crtcs: the crtcs the ldb is connected to, see + below +Optional properties: +- channel0-edid, channel1-edid: verbatim EDID data blocks describing the + displays attached to channel0 and channel1. +- channel0-ddc, channel1-ddc: phandles describing the i2c busses handling + the display data channels for channel0 and channel1. + +lvds@53fa8008 { + compatible = "fsl,imx6q-ldb"; + channel0-edid = [edid-data]; + channel1-ddc = <&i2c0>; + channel0-crtcs = <&ipu0 0>, <&ipu0 1>, <&ipu1 0>, <&ipu1 1>; + channel1-crtcs = <&ipu0 0>, <&ipu0 1>, <&ipu1 0>, <&ipu1 1>; +}; + +Specifying CRTCs connected to display output devices +==================================================== + +Display output device nodes should specify which CRTCs they can be +connected to in their crtcs property, containing a 'crtc-list': + + crtc-list ::= <single-crtc> [crtc-list] + single-crtc ::= <crtc-phandle> <crtc-specifier> + crtc-phandle : phandle to device node providing the crtc + crtc-specifier : Array of #crtc-cells specifying specific crtc + (controller specific, 1 on imx-ipuv3) + +In the following example, two image processing units ipu0 and ipu1 +provide two CRTCs each, indexed with a single cell. The hdmi connector +can be connected to either CRTC of ipu1, and the lvds connector is +fixed to the second CRTC of ipu0. + + ipu0: ipu0 { + #crtc-cells = <1>; + }; + ipu1: ipu1 { + #crtc-cells = <1>; + }; + [...] + hdmi: hdmi { + ddc = <&i2c2>; + crtcs = <&ipu1 0 &ipu1 1>; + }; + lvds: lvds { + edid = [edid-data]; + crtcs = <&ipu0 1>; + }; + +Note that the crtc-specifier length is controller dependent. A simple +lcdc controller with a single CRTC should use #crtc-cells = <0>: + + lcdc: lcdc { + #crtc-cells = <0>; + }; + [...] + parallel-display { + crtcs = <&lcdc> + }; + -- 1.7.10 -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 3

about_radeon_dma
by llittle了了 14 Jun '12

14 Jun '12

HI,all Now, my lab is using radeon_ati card。And, I need ati_card dma function。But, I do not clear that how the ati card know the dma address which alloced by kernel?? Can any kernel drivers for radeon card give me some advise or explain the answer? I have read the radeon driver in kernel (/driver/gpu/drm/randeon/xxx ）and the TTM manager. So, as I know, If I use GFP_KERNEL sign to alloc memory, the radeon_card work right, but any other palce ,it failed. Why and how this happened? Is there any way to tell the dma address and ring buffer address in kernel to the radeon_card ? It`s so confused! Hope for your answer! Thanks so much! zhiyig Si

4 5

[PATCH v4] scatterlist: add sg_alloc_table_from_pages function
by Tomasz Stanislawski 14 Jun '12

14 Jun '12

This patch adds a new constructor for an sg table. The table is constructed from an array of struct pages. All contiguous chunks of the pages are merged into a single sg nodes. A user may provide an offset and a size of a buffer if the buffer is not page-aligned. The function is dedicated for DMABUF exporters which often perform conversion from an page array to a scatterlist. Moreover the scatterlist should be squashed in order to save memory and to speed-up the process of DMA mapping using dma_map_sg. The code is based on the patch 'v4l: vb2-dma-contig: add support for scatterlist in userptr mode' and hints from Laurent Pinchart. Signed-off-by: Tomasz Stanislawski <t.stanislaws(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> CC: Andrew Morton <akpm(a)linux-foundation.org> --- v4: - fix typos - add Changelog v3: - use PFNs instead of page pointers to check contiguity v2: - rename sg_table_alloc_by_pages to sg_table_alloc_from_pages - add some comments about error value v1: - initial version --- include/linux/scatterlist.h | 4 +++ lib/scatterlist.c | 64 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index ac9586d..7b600da 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h @@ -214,6 +214,10 @@ void sg_free_table(struct sg_table *); int __sg_alloc_table(struct sg_table *, unsigned int, unsigned int, gfp_t, sg_alloc_fn *); int sg_alloc_table(struct sg_table *, unsigned int, gfp_t); +int sg_alloc_table_from_pages(struct sg_table *sgt, + struct page **pages, unsigned int n_pages, + unsigned long offset, unsigned long size, + gfp_t gfp_mask); size_t sg_copy_from_buffer(struct scatterlist *sgl, unsigned int nents, void *buf, size_t buflen); diff --git a/lib/scatterlist.c b/lib/scatterlist.c index 6096e89..e719adf 100644 --- a/lib/scatterlist.c +++ b/lib/scatterlist.c @@ -319,6 +319,70 @@ int sg_alloc_table(struct sg_table *table, unsigned int nents, gfp_t gfp_mask) EXPORT_SYMBOL(sg_alloc_table); /** + * sg_alloc_table_from_pages - Allocate and initialize an sg table from + * an array of pages + * @sgt: The sg table header to use + * @pages: Pointer to an array of page pointers + * @n_pages: Number of pages in the pages array + * @offset: Offset from start of the first page to the start of a buffer + * @size: Number of valid bytes in the buffer (after offset) + * @gfp_mask: GFP allocation mask + * + * Description: + * Allocate and initialize an sg table from a list of pages. Contiguous + * ranges of the pages are squashed into a single scatterlist node. A user + * may provide an offset at a start and a size of valid data in a buffer + * specified by the page array. The returned sg table is released by + * sg_free_table. + * + * Returns: + * 0 on success, negative error on failure + */ +int sg_alloc_table_from_pages(struct sg_table *sgt, + struct page **pages, unsigned int n_pages, + unsigned long offset, unsigned long size, + gfp_t gfp_mask) +{ + unsigned int chunks; + unsigned int i; + unsigned int cur_page; + int ret; + struct scatterlist *s; + + /* compute number of contiguous chunks */ + chunks = 1; + for (i = 1; i < n_pages; ++i) + if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) + 1) + ++chunks; + + ret = sg_alloc_table(sgt, chunks, gfp_mask); + if (unlikely(ret)) + return ret; + + /* merging chunks and putting them into the scatterlist */ + cur_page = 0; + for_each_sg(sgt->sgl, s, sgt->orig_nents, i) { + unsigned long chunk_size; + unsigned int j; + + /* look for the end of the current chunk */ + for (j = cur_page + 1; j < n_pages; ++j) + if (page_to_pfn(pages[j]) != + page_to_pfn(pages[j - 1]) + 1) + break; + + chunk_size = ((j - cur_page) << PAGE_SHIFT) - offset; + sg_set_page(s, pages[cur_page], min(size, chunk_size), offset); + size -= chunk_size; + offset = 0; + cur_page = j; + } + + return 0; +} +EXPORT_SYMBOL(sg_alloc_table_from_pages); + +/** * sg_miter_start - start mapping iteration over a sg list * @miter: sg mapping iter to be started * @sgl: sg list to iterate over -- 1.7.9.5

1 0

[Bug 51065] New: [Regression] : Acceleration initialization failed
by bugzilla-daemon＠freedesktop.org 14 Jun '12

14 Jun '12

https://bugs.freedesktop.org/show_bug.cgi?id=51065 Bug #: 51065 Summary: [Regression] : Acceleration initialization failed Classification: Unclassified Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: All Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hysvats(a)gmail.com Created attachment 63013 --> https://bugs.freedesktop.org/attachment.cgi?id=63013 Xorg.log Driver Stack Details: ========================= 1) Kernel-3.0.0-12-generice-pae 2) drm-2.4.34 3) Mesa-8.1-devel 4) Xorg-server-1.11.4 5) xf86-video-ati- master System Environment: =================== Asic : EG CedarPro O.S. : Ubuntu-11.10 (32 bit) Processor : Intel(R) Xeon(R) @ 2.4 GHz Memory : 2 GB Observation: ============ Acceleration initialization fails with 6.14.99 but works fine with 6.14.4 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[Bug 14500] Kernel 2.6.31-14.48 froze during regular use (kref.c with warn_slowpath_common)
by bugzilla-daemon＠bugzilla.kernel.org 14 Jun '12

14 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=14500 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED -- 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 0

[Bug 14500] Kernel 2.6.31-14.48 froze during regular use (kref.c with warn_slowpath_common)
by bugzilla-daemon＠bugzilla.kernel.org 14 Jun '12

14 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=14500 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |alan(a)lxorguk.ukuu.org.uk Component|Other |Video(DRI - non Intel) Resolution| |OBSOLETE AssignedTo|drivers_other(a)kernel-bugs.o |drivers_video-dri@kernel-bu |sdl.org |gs.osdl.org --- Comment #3 from Alan <alan(a)lxorguk.ukuu.org.uk> 2012-06-14 10:06:31 --- Reassigning to the DRI layer I'll also close this as it doesn't provide any useful replication info and it is versus an old kernel so it doesn't really have any obvious use to us any more. Tnanks for reporting it. Alan -- 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 0

i915: lvds panel always blank when booted with lid closed
by Seth Forshee 14 Jun '12

14 Jun '12

When I boot my Thinkpad T410 in a docking station with the lid closed, the lvds panel remains blank even when this output is active. This happens up to and including 3.5-rc2. I've determined that this happens because lvds isn't being initialized by the bios when I boot this way, and booting with lvds_channel_mode=2 fixes the issue. I see that there's logic in is_dual_link_lvds() intended to detect this situation, but it's failing because the T410 has the LVDS_PIPEB_SELECT bit set. The simple patch below fixes my machine by masking off this bit when determining whether or not lvds was initialized by the bios. I'm not sure though whether or not it's correct to expect that this bit might be set when lvds hasn't been initialized. The alternative seems to be quirking this machine as is done for some Macbooks. What is the correct solution? Thanks, Seth >From 250904ac95cda7630cdd8339724e3c8feceeb586 Mon Sep 17 00:00:00 2001 From: Seth Forshee <seth.forshee(a)canonical.com> Date: Tue, 12 Jun 2012 16:52:14 -0500 Subject: [PATCH] drm/i915: ignore LVDS_PIPEB_SELECT when checking for LVDS register initialization The Lenovo Thinkpad T410 has this bit set in the LVDS register when booted with the lid closed, even though the LVDS hasn't really been initialized. Ignore this bit so that the VBT value will be used instead. Signed-off-by: Seth Forshee <seth.forshee(a)canonical.com> --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e0aa064..f81f249 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -434,7 +434,7 @@ static bool is_dual_link_lvds(struct drm_i915_private *dev_priv, * register is uninitialized. */ val = I915_READ(reg); - if (!(val & ~LVDS_DETECTED)) + if (!(val & ~(LVDS_PIPEB_SELECT | LVDS_DETECTED))) val = dev_priv->bios_lvds_val; dev_priv->lvds_val = val; }

2 5

[Bug 14274] radeon KMS unusable on RadeonHD 3650
by bugzilla-daemon＠bugzilla.kernel.org 13 Jun '12

13 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=14274 --- Comment #29 from Shawn Starr <shawn.starr(a)rogers.com> 2012-06-13 21:49:02 --- None, been using Composite Window managers for awhile now and no issues related to this. Please close. -- 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 0

[Bug 14274] radeon KMS unusable on RadeonHD 3650
by bugzilla-daemon＠bugzilla.kernel.org 13 Jun '12

13 Jun '12

https://bugzilla.kernel.org/show_bug.cgi?id=14274 Alan <alan(a)lxorguk.ukuu.org.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |alan(a)lxorguk.ukuu.org.uk --- Comment #28 from Alan <alan(a)lxorguk.ukuu.org.uk> 2012-06-13 18:53:04 --- Is this still seen with modern kernels ? -- 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 0

← Newer
1
...
56
57
58
59
60
61
62
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2012