[PATCH] dma-buf: add vmap interface (v3)
From: Dave Airlie The main requirement I have for this interface is for scanning out using the USB gpu devices. Since these devices have to read the framebuffer on updates and linearly compress it, using kmaps is a major overhead for every update. v2: fix warn issues pointed out by Sylwester Nawrocki. v3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now Signed-off-by: Dave Airlie --- drivers/base/dma-buf.c | 34 ++ include/linux/dma-buf.h | 14 ++ 2 files changed, 48 insertions(+), 0 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 07cbbc6..0d8197e 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, dmabuf->ops->kunmap(dmabuf, page_num, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_kunmap); + +/** + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel address space. The same restrictions as for vmap and friends apply. + * @dma_buf: [in]buffer to vmap + * + * This call may fail due to lack of virtual mapping address space. + * These calls are optional in drivers. The intended use for them + * is for mapping objects linear in kernel space for high use objects. + * Please attempt to use kmap/kunmap before thinking about these interfaces. + */ +void *dma_buf_vmap(struct dma_buf *dmabuf) +{ + if (WARN_ON(!dmabuf)) + return NULL; + + if (dmabuf->ops->vmap) + return dmabuf->ops->vmap(dmabuf); + return NULL; +} +EXPORT_SYMBOL_GPL(dma_buf_vmap); + +/** + * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap. + * @dma_buf: [in]buffer to vmap + */ +void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) +{ + if (WARN_ON(!dmabuf)) + return; + + if (dmabuf->ops->vunmap) + dmabuf->ops->vunmap(dmabuf, vaddr); +} +EXPORT_SYMBOL_GPL(dma_buf_vunmap); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 3efbfc2..d8c2865 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -92,6 +92,9 @@ struct dma_buf_ops { void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *); void *(*kmap)(struct dma_buf *, unsigned long); void (*kunmap)(struct dma_buf *, unsigned long, void *); + + void *(*vmap)(struct dma_buf *); + void (*vunmap)(struct dma_buf *, void *vaddr); }; /** @@ -167,6 +170,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); void *dma_buf_kmap(struct dma_buf *, unsigned long); void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); + +void *dma_buf_vmap(struct dma_buf *); +void dma_buf_vunmap(struct dma_buf *, void *vaddr); #else static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, @@ -248,6 +254,14 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long pnum, void *vaddr) { } + +static inline void *dma_buf_vmap(struct dma_buf *dmabuf) +{ +} + +static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) +{ +} #endif /* CONFIG_DMA_SHARED_BUFFER */ #endif /* __DMA_BUF_H__ */ -- 1.7.6
Re: linux-next: Tree for May 18 (drm drivers and vgacon)
On 05/18/2012 01:49 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201205017: When CONFIG_VGA_CONSOLE is not enabled: drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of function 'vgacon_text_force' drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 'vgacon_text_force' drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of function 'vgacon_text_force' -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Tree for May 18 (drm drivers and vgacon)
On 05/18/2012 01:49 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 201205017: When CONFIG_VGA_CONSOLE is not enabled: drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of function 'vgacon_text_force' drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 'vgacon_text_force' drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of function 'vgacon_text_force' -- ~Randy
[PATCH 2/2] pcm038 lcdc support
On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote: > On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote: > > > + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b > > + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 > > + 11 50 54 > > + > > + /* est timings */ > > + 00 00 00 > > + > > + /* std timings */ > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + > > + /* detailed timings */ > > + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 > > 00 1E > > + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 > > 20 20 > > + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a > > 20 20 > > + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a > > 20 20 > > + 00 20]; > > This EDID block claims to be a Samsung SyncMaster, which isn't really > the right thing to do. The question is what to call it instead. Red > Hat has a PNP ID we can use for virtual EDID blocks like this if we > want, I'd want to set up a little database to keep track of them but > that's pretty trivial. Sorry, should have mentioned this in the commit log. This in fact is a hacked version of my office monitor. This patch is more meant as a usage example and not for upstream. I don't know yet if it's even acceptable to put edid data into the devicetree. I saw some discussion about it, but also about some generic display description, which I would prefer. BTW is there a more convenient tool than a hex editor around to generate edid data? I only found some windows tools > > Also, empty standard timing fields are 01 01, not 00 00. Good to know Thanks Sascha -- 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- |
dce crtc mem req and atombios
Hi, On radeon hardware (I have an evergreen based board): Must stopping/resuming the DCE to access the memory controller be done with the EnableCRTCMemReq atombios table? (from DCE3 in dpm code). Because, in evergreen.c, evergreen_mc_stop and evergreen_mc_resume functions do not make use of that table (register direct access). regards, -- Sylvain
[PATCH] nouveau: nouveau_set_bo_placement takes TTM flags
From: Dave Airlie This seems to be wrong to me, spotted while thinking about dma-buf. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_bo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 7d15a77..12ce044 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1030,7 +1030,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) nvbo->placement.fpfn = 0; nvbo->placement.lpfn = dev_priv->fb_mappable_pages; - nouveau_bo_placement_set(nvbo, TTM_PL_VRAM, 0); + nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0); return nouveau_bo_validate(nvbo, false, true, false); } -- 1.7.7.6
[PATCH 2/2] pcm038 lcdc support
Signed-off-by: Sascha Hauer --- arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 arch/arm/boot/dts/imx27.dtsi |7 + arch/arm/mach-imx/clock-imx27.c|1 + 3 files changed, 47 insertions(+) diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dts b/arch/arm/boot/dts/imx27-phytec-phycore.dts index a51a08f..bdb7547 100644 --- a/arch/arm/boot/dts/imx27-phytec-phycore.dts +++ b/arch/arm/boot/dts/imx27-phytec-phycore.dts @@ -20,6 +20,41 @@ reg = <0x0 0x0>; }; + baseboard { + compatible = "simple-bus"; + #address-cells = <2>; +#size-cells = <1>; + + display { + compatible = "fsl,imx-parallel-display"; + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 + 11 50 54 + + /* est timings */ + 00 00 00 + + /* std timings */ + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + + /* detailed timings */ + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 00 1E + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 20 20 + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 20 20 + 00 20]; + + crtc = <&lcdc 0>; + }; + }; + soc { aipi at 1000 { /* aipi */ @@ -46,6 +81,10 @@ status = "okay"; }; + lcdc at 10021000 { + status = "okay"; + }; + i2c at 1001d000 { clock-frequency = <40>; status = "okay"; diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi index bc5e7d5..eab9095 100644 --- a/arch/arm/boot/dts/imx27.dtsi +++ b/arch/arm/boot/dts/imx27.dtsi @@ -206,6 +206,13 @@ status = "disabled"; }; + lcdc: lcdc at 10021000 { + compatible = "fsl,imx27-lcdc", "fsl,imx21-lcdc"; + reg = <0x10021000 0x4000>; + interrupts = <61>; + status = "enabled"; + }; + fec: fec at 1002b000 { compatible = "fsl,imx27-fec"; reg = <0x1002b000 0x4000>; diff --git a/arch/arm/mach-imx/clock-imx27.c b/arch/arm/mach-imx/clock-imx27.c index 98e04f5..a393483 100644 --- a/arch/arm/mach-imx/clock-imx27.c +++ b/arch/arm/mach-imx/clock-imx27.c @@ -646,6 +646,7 @@ static struct clk_lookup lookups[] = { _REGISTER_CLOCK("imx27-cspi.1", NULL, cspi2_clk) _REGISTER_CLOCK("imx27-cspi.2", NULL, cspi3_clk) _REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk) + _REGISTER_CLOCK("10021000.lcdc", NULL, lcdc_clk) _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk) _REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk) _REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk1) -- 1.7.10
[PATCH 1/2] DRM: add Freescale i.MX LCDC driver
Signed-off-by: Sascha Hauer --- drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/imx/Kconfig| 18 + drivers/gpu/drm/imx/Makefile |8 + drivers/gpu/drm/imx/imx-drm-core.c | 745 drivers/gpu/drm/imx/imx-fb.c | 179 +++ drivers/gpu/drm/imx/imx-fbdev.c| 275 ++ drivers/gpu/drm/imx/imx-gem.c | 343 + drivers/gpu/drm/imx/imx-lcdc-crtc.c| 517 +++ drivers/gpu/drm/imx/imx-parallel-display.c | 228 + 10 files changed, 2316 insertions(+) create mode 100644 drivers/gpu/drm/imx/Kconfig create mode 100644 drivers/gpu/drm/imx/Makefile create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c create mode 100644 drivers/gpu/drm/imx/imx-fb.c create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c create mode 100644 drivers/gpu/drm/imx/imx-gem.c create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index e354bc0..759502c 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -186,3 +186,5 @@ source "drivers/gpu/drm/vmwgfx/Kconfig" source "drivers/gpu/drm/gma500/Kconfig" source "drivers/gpu/drm/udl/Kconfig" + +source "drivers/gpu/drm/imx/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index c20da5b..6569d8d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -42,4 +42,5 @@ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ +obj-$(CONFIG_DRM_IMX) += imx/ obj-y += i2c/ diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig new file mode 100644 index 000..5fc3a44 --- /dev/null +++ b/drivers/gpu/drm/imx/Kconfig @@ -0,0 +1,18 @@ +config DRM_IMX + tristate "DRM Support for Freescale i.MX" + select DRM_KMS_HELPER + depends on DRM && ARCH_MXC + +config DRM_IMX_FB_HELPER + tristate "provide legacy framebuffer /dev/fb0" + depends on DRM_IMX + +config DRM_IMX_LCDC + tristate "DRM Support for Freescale i.MX1 and i.MX2" + depends on DRM_IMX + help + Choose this if you have a i.MX1, i.MX21, i.MX25 or i.MX27 processor. + +config DRM_IMX_PARALLEL_DISPLAY + tristate "Support for parallel displays" + depends on DRM_IMX diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile new file mode 100644 index 000..0f7c038 --- /dev/null +++ b/drivers/gpu/drm/imx/Makefile @@ -0,0 +1,8 @@ + +imxdrm-objs := imx-drm-core.o imx-fb.o imx-gem.o + +obj-$(CONFIG_DRM_IMX) += imxdrm.o + +obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += imx-parallel-display.o +obj-$(CONFIG_DRM_IMX_LCDC) += imx-lcdc-crtc.o +obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o diff --git a/drivers/gpu/drm/imx/imx-drm-core.c b/drivers/gpu/drm/imx/imx-drm-core.c new file mode 100644 index 000..29f5f10 --- /dev/null +++ b/drivers/gpu/drm/imx/imx-drm-core.c @@ -0,0 +1,745 @@ +/* + * simple drm driver + * + * Copyright (C) 2011 Sascha Hauer, Pengutronix + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "imx-drm.h" + +#define MAX_CRTC 4 + +struct imx_drm_device { + struct drm_device *drm; + struct device *dev; + struct list_headcrtc_list; + struct list_headencoder_list; + struct list_headconnector_list; + struct mutexmutex; + int references; +}; + +struct imx_drm_crtc { + struct drm_crtc *crtc; + struct list_headlist; + struct imx_drm_device *imxdrm; + int pipe; + struct drm_crtc_helper_funcscrtc_helper_funcs; + struct drm_crtc_funcs crtc_funcs; + struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs; + struct module *owner; +}; + +struct imx_drm_encoder { + struct drm_encoder *encoder; + struct list_head
No subject
Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is now devicetree based. For now I took the easy way out and only put an edid blob into the devicetree. I haven't documented the binding yet, I would add that when the rest is considered ok. Comments very welcome. Thanks Sascha Sascha Hauer (2): DRM: add Freescale i.MX LCDC driver pcm038 lcdc support arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 ++ arch/arm/boot/dts/imx27.dtsi |7 + arch/arm/mach-imx/clock-imx27.c|1 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/imx/Kconfig| 18 + drivers/gpu/drm/imx/Makefile |8 + drivers/gpu/drm/imx/imx-drm-core.c | 745 drivers/gpu/drm/imx/imx-fb.c | 179 +++ drivers/gpu/drm/imx/imx-fbdev.c| 275 ++ drivers/gpu/drm/imx/imx-gem.c | 343 + drivers/gpu/drm/imx/imx-lcdc-crtc.c| 517 +++ drivers/gpu/drm/imx/imx-parallel-display.c | 228 + 13 files changed, 2363 insertions(+) create mode 100644 drivers/gpu/drm/imx/Kconfig create mode 100644 drivers/gpu/drm/imx/Makefile create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c create mode 100644 drivers/gpu/drm/imx/imx-fb.c create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c create mode 100644 drivers/gpu/drm/imx/imx-gem.c create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
[Bug 49943] radeon/drm: Hotplug udev events stop working
https://bugs.freedesktop.org/show_bug.cgi?id=49943 --- Comment #2 from Harald Judt 2012-05-18 06:45:13 PDT --- BTW: Connecting HDMI again shows the following values: HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff012 (-15732718) HDMI disconnected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff000 (-15732736) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 49943] radeon/drm: Hotplug udev events stop working
https://bugs.freedesktop.org/show_bug.cgi?id=49943 --- Comment #1 from Harald Judt 2012-05-18 06:35:44 PDT --- Ok, I've run radeonreg, here is the output: Before HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0x (0) HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff12 (-16777198) HDMI disconnected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff000 (-15732736) The value of reg 0x6058 changes (HDMI-0). As you can see, after HDMI has been disconnected, it is different from the original value (0). I suspect that there is some problem with this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #1 from C?dric Legrand 2012-05-18 06:16:00 PDT --- Same here : creating 2 SFML canvas in a wxWidgets application results in the same problem. Each canvas shows when alone, but the second does not when together. It seems not to refresh, as it sometimes shows other parts of the application in the canvas (title, the other canvas, menus...). In Windows 7, the same code works well. * Application output : lots of : radeon: The kernel rejected CS, see dmesg for more information. * dmesg output : lots of : radeon :01:00.0: texture bo too small (384 480 26 0 -> 737280 have 4096) radeon :01:00.0: alignments 384 1 1 1 [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! * uname -a : Linux perfection 3.3.5-gentoo #1 SMP Wed May 16 19:54:18 CEST 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T6500 @ 2.10GHz GenuineIntel GNU/Linux * glxinfo | grep OpenGL : OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV710 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions: * latest libdrm in testing portage tree (2.4.33) * SFML-2.0rc I'm sorry for my english -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm_edid: support CEA video modes
Joakim Plate wrote: > Joakim Plate ecce.se> writes: > >> >> Christian Schmidt digadd.de> writes: >> >>> >>> TFT/plasma televisions and projectors have become commonplace, and so >>> has the use of PCs to drive them. Add the video modes specified by an >>> EDID's CEA extension to the mode database for a connector. >> >> /Joakim >> > > Shameless bump on the subject. Would be nice if we could > get this list complete when connecting to HDTV's. Yea, it would be nice. UK bluray seems to use 24/1.001 - not that it's that bad watching with TV at 24Hz. I do have issues with interlaced modes on my TV. I don't know how DRM handles interlaced, but CEA says that the number of vblank lines alternates per field. If that isn't happening then I guess that's why.
[PATCH] dma-buf: add vmap interface (v3)
From: Dave Airlie The main requirement I have for this interface is for scanning out using the USB gpu devices. Since these devices have to read the framebuffer on updates and linearly compress it, using kmaps is a major overhead for every update. v2: fix warn issues pointed out by Sylwester Nawrocki. v3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now Signed-off-by: Dave Airlie --- drivers/base/dma-buf.c | 34 ++ include/linux/dma-buf.h | 14 ++ 2 files changed, 48 insertions(+), 0 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index 07cbbc6..0d8197e 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num, dmabuf->ops->kunmap(dmabuf, page_num, vaddr); } EXPORT_SYMBOL_GPL(dma_buf_kunmap); + +/** + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel address space. The same restrictions as for vmap and friends apply. + * @dma_buf: [in]buffer to vmap + * + * This call may fail due to lack of virtual mapping address space. + * These calls are optional in drivers. The intended use for them + * is for mapping objects linear in kernel space for high use objects. + * Please attempt to use kmap/kunmap before thinking about these interfaces. + */ +void *dma_buf_vmap(struct dma_buf *dmabuf) +{ + if (WARN_ON(!dmabuf)) + return NULL; + + if (dmabuf->ops->vmap) + return dmabuf->ops->vmap(dmabuf); + return NULL; +} +EXPORT_SYMBOL_GPL(dma_buf_vmap); + +/** + * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap. + * @dma_buf: [in]buffer to vmap + */ +void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) +{ + if (WARN_ON(!dmabuf)) + return; + + if (dmabuf->ops->vunmap) + dmabuf->ops->vunmap(dmabuf, vaddr); +} +EXPORT_SYMBOL_GPL(dma_buf_vunmap); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 3efbfc2..d8c2865 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -92,6 +92,9 @@ struct dma_buf_ops { void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *); void *(*kmap)(struct dma_buf *, unsigned long); void (*kunmap)(struct dma_buf *, unsigned long, void *); + + void *(*vmap)(struct dma_buf *); + void (*vunmap)(struct dma_buf *, void *vaddr); }; /** @@ -167,6 +170,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); void *dma_buf_kmap(struct dma_buf *, unsigned long); void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); + +void *dma_buf_vmap(struct dma_buf *); +void dma_buf_vunmap(struct dma_buf *, void *vaddr); #else static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, @@ -248,6 +254,14 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long pnum, void *vaddr) { } + +static inline void *dma_buf_vmap(struct dma_buf *dmabuf) +{ +} + +static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) +{ +} #endif /* CONFIG_DMA_SHARED_BUFFER */ #endif /* __DMA_BUF_H__ */ -- 1.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm_edid: support CEA video modes
Joakim Plate ecce.se> writes: > > Christian Schmidt digadd.de> writes: > > > > > TFT/plasma televisions and projectors have become commonplace, and so > > has the use of PCs to drive them. Add the video modes specified by an > > EDID's CEA extension to the mode database for a connector. > > /Joakim > Shameless bump on the subject. Would be nice if we could get this list complete when connecting to HDTV's.
[PATCH 2/2] pcm038 lcdc support
On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote: > + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b > + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 > + 11 50 54 > + > + /* est timings */ > + 00 00 00 > + > + /* std timings */ > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + > + /* detailed timings */ > + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 > 00 1E > + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 > 20 20 > + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a > 20 20 > + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a > 20 20 > + 00 20]; This EDID block claims to be a Samsung SyncMaster, which isn't really the right thing to do. The question is what to call it instead. Red Hat has a PNP ID we can use for virtual EDID blocks like this if we want, I'd want to set up a little database to keep track of them but that's pretty trivial. Also, empty standard timing fields are 01 01, not 00 00. - ajax -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120518/70b0e903/attachment.pgp>
[PATCH] dma-buf: mmap support
Hi Daniel, Rob, On 11 May 2012 21:00, Rob Clark wrote: > On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter > wrote: >> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks >> >> Cc: Rob Clark >> Cc: Rebecca Schultz Zavin >> Signed-Off-by: Daniel Vetter > > Acked-by: Rob Clark Thanks, applied to my for-next. Sorry, I was away due to some medical reasons for some time, hence the delay. > Best regards, ~Sumit.
[Linaro-mm-sig] [PATCH] dma-buf: add vmap interface (v2)
Hi Dave, On 17 May 2012 16:01, Dave Airlie wrote: > From: Dave Airlie > > The main requirement I have for this interface is for scanning out > using the USB gpu devices. Since these devices have to read the > framebuffer on updates and linearly compress it, using kmaps > is a major overhead for every update. > > v2: fix warn issues pointed out by Sylwester Nawrocki. > > Signed-off-by: Dave Airlie > --- > ?drivers/base/dma-buf.c ?| ? 34 ++ > ?include/linux/dma-buf.h | ? 14 ++ > ?2 files changed, 48 insertions(+), 0 deletions(-) > > diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c > index 07cbbc6..750f92c 100644 > --- a/drivers/base/dma-buf.c > +++ b/drivers/base/dma-buf.c > @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned > long page_num, > ? ? ? ? ? ? ? ?dmabuf->ops->kunmap(dmabuf, page_num, vaddr); > ?} > ?EXPORT_SYMBOL_GPL(dma_buf_kunmap); > + > +/** > + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel > address space. The same restrictions as for vmap and friends apply. > + * @dma_buf: ? [in] ? ?buffer to vmap > + * > + * This call may fail due to lack of virtual mapping address space. > + * These calls are optional in drivers. The intended use for them > + * is for mapping objects linear in kernel space for high use objects. > + * Please attempt to use kmap/kunmap before thinking about these interfaces. > + */ > +void *dma_buf_vmap(struct dma_buf *dmabuf) > +{ > + ? ? ? if (WARN_ON(!dmabuf)) > + ? ? ? ? ? ? ? return NULL; > + > + ? ? ? if (dmabuf->ops->vmap) > + ? ? ? ? ? ? ? return dmabuf->ops->vmap(dmabuf); > + ? ? ? return NULL; > +} > +EXPORT_SYMBOL(dma_buf_vmap); I am afraid we don't yet have a clear consensus on the usage of EXPORT_SYMBOL - till it is done, I would prefer that we use EXPORT_SYMBOL_GPL for consistency. Once we reach agreement, we can change them all in one go if required. > + -- Thanks and regards, ~Sumit.
dce crtc mem req and atombios
Hi, On radeon hardware (I have an evergreen based board): Must stopping/resuming the DCE to access the memory controller be done with the EnableCRTCMemReq atombios table? (from DCE3 in dpm code). Because, in evergreen.c, evergreen_mc_stop and evergreen_mc_resume functions do not make use of that table (register direct access). regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] pcm038 lcdc support
On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote: > On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote: > > > + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b > > + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 > > + 11 50 54 > > + > > + /* est timings */ > > + 00 00 00 > > + > > + /* std timings */ > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + 00 00 > > + > > + /* detailed timings */ > > + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 > > 00 1E > > + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 > > 20 20 > > + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a > > 20 20 > > + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a > > 20 20 > > + 00 20]; > > This EDID block claims to be a Samsung SyncMaster, which isn't really > the right thing to do. The question is what to call it instead. Red > Hat has a PNP ID we can use for virtual EDID blocks like this if we > want, I'd want to set up a little database to keep track of them but > that's pretty trivial. Sorry, should have mentioned this in the commit log. This in fact is a hacked version of my office monitor. This patch is more meant as a usage example and not for upstream. I don't know yet if it's even acceptable to put edid data into the devicetree. I saw some discussion about it, but also about some generic display description, which I would prefer. BTW is there a more convenient tool than a hex editor around to generate edid data? I only found some windows tools > > Also, empty standard timing fields are 01 01, not 00 00. Good to know Thanks Sascha -- 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- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: nouveau_set_bo_placement takes TTM flags
From: Dave Airlie This seems to be wrong to me, spotted while thinking about dma-buf. Signed-off-by: Dave Airlie --- drivers/gpu/drm/nouveau/nouveau_bo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 7d15a77..12ce044 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -1030,7 +1030,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object *bo) nvbo->placement.fpfn = 0; nvbo->placement.lpfn = dev_priv->fb_mappable_pages; - nouveau_bo_placement_set(nvbo, TTM_PL_VRAM, 0); + nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0); return nouveau_bo_validate(nvbo, false, true, false); } -- 1.7.7.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] pcm038 lcdc support
On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote: > + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b > + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 > + 11 50 54 > + > + /* est timings */ > + 00 00 00 > + > + /* std timings */ > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + 00 00 > + > + /* detailed timings */ > + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 > 00 1E > + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 > 20 20 > + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a > 20 20 > + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a > 20 20 > + 00 20]; This EDID block claims to be a Samsung SyncMaster, which isn't really the right thing to do. The question is what to call it instead. Red Hat has a PNP ID we can use for virtual EDID blocks like this if we want, I'd want to set up a little database to keep track of them but that's pretty trivial. Also, empty standard timing fields are 01 01, not 00 00. - ajax signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49943] radeon/drm: Hotplug udev events stop working
https://bugs.freedesktop.org/show_bug.cgi?id=49943 --- Comment #2 from Harald Judt 2012-05-18 06:45:13 PDT --- BTW: Connecting HDMI again shows the following values: HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff012 (-15732718) HDMI disconnected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff000 (-15732736) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49943] radeon/drm: Hotplug udev events stop working
https://bugs.freedesktop.org/show_bug.cgi?id=49943 --- Comment #1 from Harald Judt 2012-05-18 06:35:44 PDT --- Ok, I've run radeonreg, here is the output: Before HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0x (0) HDMI connected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff12 (-16777198) HDMI disconnected: 0x601c 0x (0) 0x6028 0x0612 (100663314) 0x6034 0x0012 (18) 0x6040 0x (0) 0x604c 0x (0) 0x6058 0xff0ff000 (-15732736) The value of reg 0x6058 changes (HDMI-0). As you can see, after HDMI has been disconnected, it is different from the original value (0). I suspect that there is some problem with this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #1 from Cédric Legrand 2012-05-18 06:16:00 PDT --- Same here : creating 2 SFML canvas in a wxWidgets application results in the same problem. Each canvas shows when alone, but the second does not when together. It seems not to refresh, as it sometimes shows other parts of the application in the canvas (title, the other canvas, menus...). In Windows 7, the same code works well. * Application output : lots of : radeon: The kernel rejected CS, see dmesg for more information. * dmesg output : lots of : radeon :01:00.0: texture bo too small (384 480 26 0 -> 737280 have 4096) radeon :01:00.0: alignments 384 1 1 1 [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! * uname -a : Linux perfection 3.3.5-gentoo #1 SMP Wed May 16 19:54:18 CEST 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T6500 @ 2.10GHz GenuineIntel GNU/Linux * glxinfo | grep OpenGL : OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RV710 OpenGL version string: 2.1 Mesa 8.0.2 OpenGL shading language version string: 1.20 OpenGL extensions: * latest libdrm in testing portage tree (2.4.33) * SFML-2.0rc I'm sorry for my english -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] pcm038 lcdc support
Signed-off-by: Sascha Hauer --- arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 arch/arm/boot/dts/imx27.dtsi |7 + arch/arm/mach-imx/clock-imx27.c|1 + 3 files changed, 47 insertions(+) diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dts b/arch/arm/boot/dts/imx27-phytec-phycore.dts index a51a08f..bdb7547 100644 --- a/arch/arm/boot/dts/imx27-phytec-phycore.dts +++ b/arch/arm/boot/dts/imx27-phytec-phycore.dts @@ -20,6 +20,41 @@ reg = <0x0 0x0>; }; + baseboard { + compatible = "simple-bus"; + #address-cells = <2>; +#size-cells = <1>; + + display { + compatible = "fsl,imx-parallel-display"; + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24 + 11 50 54 + + /* est timings */ + 00 00 00 + + /* std timings */ + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + 00 00 + + /* detailed timings */ + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 00 1E + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 20 20 + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 20 20 + 00 20]; + + crtc = <&lcdc 0>; + }; + }; + soc { aipi@1000 { /* aipi */ @@ -46,6 +81,10 @@ status = "okay"; }; + lcdc@10021000 { + status = "okay"; + }; + i2c@1001d000 { clock-frequency = <40>; status = "okay"; diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi index bc5e7d5..eab9095 100644 --- a/arch/arm/boot/dts/imx27.dtsi +++ b/arch/arm/boot/dts/imx27.dtsi @@ -206,6 +206,13 @@ status = "disabled"; }; + lcdc: lcdc@10021000 { + compatible = "fsl,imx27-lcdc", "fsl,imx21-lcdc"; + reg = <0x10021000 0x4000>; + interrupts = <61>; + status = "enabled"; + }; + fec: fec@1002b000 { compatible = "fsl,imx27-fec"; reg = <0x1002b000 0x4000>; diff --git a/arch/arm/mach-imx/clock-imx27.c b/arch/arm/mach-imx/clock-imx27.c index 98e04f5..a393483 100644 --- a/arch/arm/mach-imx/clock-imx27.c +++ b/arch/arm/mach-imx/clock-imx27.c @@ -646,6 +646,7 @@ static struct clk_lookup lookups[] = { _REGISTER_CLOCK("imx27-cspi.1", NULL, cspi2_clk) _REGISTER_CLOCK("imx27-cspi.2", NULL, cspi3_clk) _REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk) + _REGISTER_CLOCK("10021000.lcdc", NULL, lcdc_clk) _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk) _REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk) _REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk1) -- 1.7.10 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[no subject]
Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is now devicetree based. For now I took the easy way out and only put an edid blob into the devicetree. I haven't documented the binding yet, I would add that when the rest is considered ok. Comments very welcome. Thanks Sascha Sascha Hauer (2): DRM: add Freescale i.MX LCDC driver pcm038 lcdc support arch/arm/boot/dts/imx27-phytec-phycore.dts | 39 ++ arch/arm/boot/dts/imx27.dtsi |7 + arch/arm/mach-imx/clock-imx27.c|1 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/imx/Kconfig| 18 + drivers/gpu/drm/imx/Makefile |8 + drivers/gpu/drm/imx/imx-drm-core.c | 745 drivers/gpu/drm/imx/imx-fb.c | 179 +++ drivers/gpu/drm/imx/imx-fbdev.c| 275 ++ drivers/gpu/drm/imx/imx-gem.c | 343 + drivers/gpu/drm/imx/imx-lcdc-crtc.c| 517 +++ drivers/gpu/drm/imx/imx-parallel-display.c | 228 + 13 files changed, 2363 insertions(+) create mode 100644 drivers/gpu/drm/imx/Kconfig create mode 100644 drivers/gpu/drm/imx/Makefile create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c create mode 100644 drivers/gpu/drm/imx/imx-fb.c create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c create mode 100644 drivers/gpu/drm/imx/imx-gem.c create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm_edid: support CEA video modes
Joakim Plate wrote: Joakim Plate ecce.se> writes: Christian Schmidt digadd.de> writes: TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by an EDID's CEA extension to the mode database for a connector. /Joakim Shameless bump on the subject. Would be nice if we could get this list complete when connecting to HDTV's. Yea, it would be nice. UK bluray seems to use 24/1.001 - not that it's that bad watching with TV@24Hz. I do have issues with interlaced modes on my TV. I don't know how DRM handles interlaced, but CEA says that the number of vblank lines alternates per field. If that isn't happening then I guess that's why. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm_edid: support CEA video modes
Joakim Plate ecce.se> writes: > > Christian Schmidt digadd.de> writes: > > > > > TFT/plasma televisions and projectors have become commonplace, and so > > has the use of PCs to drive them. Add the video modes specified by an > > EDID's CEA extension to the mode database for a connector. > > /Joakim > Shameless bump on the subject. Would be nice if we could get this list complete when connecting to HDTV's. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PCI resources above 4GB
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu wrote: > On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote: >> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Strange, the busn branch is merged with for-pci-res-alloc, but for >>> some reason it isn't working. Only the bridge is detected, not the >>> devices behind it. >> >> Can you post the boot log ? maybe recently reordering patches applying >> sequence break it. > > Never mind, found the problem. updated for-pci-res-alloc branch. please check it. Thanks Yinghai ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PCI resources above 4GB
On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu wrote: > On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote: >> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury >> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Strange, the busn branch is merged with for-pci-res-alloc, but for >>> some reason it isn't working. ?Only the bridge is detected, not the >>> devices behind it. >> >> Can you post the boot log ? maybe recently reordering patches applying >> sequence break it. > > Never mind, found the problem. updated for-pci-res-alloc branch. please check it. Thanks Yinghai
Re: PCI resources above 4GB
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote: > On Thu, May 17, 2012 at 5:34 AM, Steven Newbury wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Strange, the busn branch is merged with for-pci-res-alloc, but for >> some reason it isn't working. Only the bridge is detected, not the >> devices behind it. > > Can you post the boot log ? maybe recently reordering patches applying > sequence break it. Never mind, found the problem. will check if i could fix it tomorrow. Yinghai ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PCI resources above 4GB
On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu wrote: > On Thu, May 17, 2012 at 5:34 AM, Steven Newbury > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Strange, the busn branch is merged with for-pci-res-alloc, but for >> some reason it isn't working. ?Only the bridge is detected, not the >> devices behind it. > > Can you post the boot log ? maybe recently reordering patches applying > sequence break it. Never mind, found the problem. will check if i could fix it tomorrow. Yinghai