dri-devel February 2012

dri-devel@lists.freedesktop.org

114 participants
627 discussions

[Bug 45825] Displayport output unusable on Llano
by bugzilla-daemon＠freedesktop.org 19 Feb '12

19 Feb '12

https://bugs.freedesktop.org/show_bug.cgi?id=45825 Tomi Pieviläinen <tomi.pievilainen+freedesktop(a)iki.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #9 from Tomi Pieviläinen <tomi.pievilainen+freedesktop(a)iki.fi> 2012-02-19 01:49:35 PST --- After the latest update, it works now fine. -- 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 46213] [865G] Low framerate with glxgears and general low performance
by bugzilla-daemon＠freedesktop.org 18 Feb '12

18 Feb '12

https://bugs.freedesktop.org/show_bug.cgi?id=46213 --- Comment #1 from Chris Wilson <chris(a)chris-wilson.co.uk> 2012-02-18 11:39:17 UTC --- To put your results in context, my 855gm achieves 470fps and 55fps fullscreen (1024x768). So I judge yours to be in line with what to expect from the hardware, if a little subpar. The secret with these gen2 devices is not to use GL at all! For instance, with video use the video overlay (by using Xv). And compiz is just going to be a waste of time and energy. -- 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

[PATCH 1/2] omap2+: add drm device
by Rob Clark 17 Feb '12

17 Feb '12

From: Rob Clark <rob(a)ti.com> Register OMAP DRM/KMS platform device, and reserve a CMA region for the device to use for buffer allocation. v1: initial patch v2: move platform data structs into plat-omap to avoid having to #include headers from drivers/staging and cleanups Signed-off-by: Rob Clark <rob(a)ti.com> --- Note: after applying this patch there will be duplicate copies of the platform data structs (until the 2nd patch is applied). But I tested to ensure this does not cause build breaks. So the 2nd patch which should go thru staging tree is safe to be held until this patch hits Linus's master branch. arch/arm/plat-omap/Makefile | 2 +- arch/arm/plat-omap/common.c | 3 +- arch/arm/plat-omap/drm.c | 83 +++++++++++++++++++++++++++++++++ arch/arm/plat-omap/include/plat/drm.h | 70 +++++++++++++++++++++++++++ 4 files changed, 156 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-omap/drm.c create mode 100644 arch/arm/plat-omap/include/plat/drm.h diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 9a58461..b86e6cb 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -4,7 +4,7 @@ # Common support obj-y := common.o sram.o clock.o devices.o dma.o mux.o \ - usb.o fb.o counter_32k.o + usb.o fb.o counter_32k.o drm.o obj-m := obj-n := obj- := diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c index 06383b5..0d87dab 100644 --- a/arch/arm/plat-omap/common.c +++ b/arch/arm/plat-omap/common.c @@ -21,10 +21,10 @@ #include <plat/board.h> #include <plat/vram.h> #include <plat/dsp.h> +#include <plat/drm.h> #include <plat/omap-secure.h> - #define NO_LENGTH_CHECK 0xffffffff struct omap_board_config_kernel *omap_board_config __initdata; @@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len) void __init omap_reserve(void) { + omapdrm_reserve_vram(); omapfb_reserve_sdram_memblock(); omap_vram_reserve_sdram_memblock(); omap_dsp_reserve_sdram_memblock(); diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c new file mode 100644 index 0000000..aa0ba69 --- /dev/null +++ b/arch/arm/plat-omap/drm.c @@ -0,0 +1,83 @@ +/* + * DRM/KMS device registration for TI OMAP platforms + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark <rob.clark(a)linaro.org> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * 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. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see <http://www.gnu.org/licenses/>. + */ + +#include <linux/module.h> +#include <linux/kernel.h> +#include <linux/mm.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#ifdef CONFIG_CMA +# include <linux/dma-contiguous.h> +#endif + +#include <plat/omap_device.h> +#include <plat/omap_hwmod.h> + +#include <plat/drm.h> + +#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE) + +static struct omap_drm_platform_data omapdrm_platdata; +static struct omap_dmm_platform_data dmm_platdata; + +static struct platform_device omap_drm_device = { + .dev = { + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &omapdrm_platdata, + }, + .name = "omapdrm", + .id = 0, +}; + +static int __init omap_init_gpu(void) +{ + struct omap_hwmod *oh = NULL; + + /* lookup and populate the DMM information, if present - OMAP4+ */ + oh = omap_hwmod_lookup("dmm"); + + if (oh) { + dmm_platdata.base = omap_hwmod_get_mpu_rt_va(oh); + dmm_platdata.irq = oh->mpu_irqs[0].irq; + + if (dmm_platdata.base) + omapdrm_platdata.dmm_pdata = &dmm_platdata; + } + + return platform_device_register(&omap_drm_device); +} + +arch_initcall(omap_init_gpu); + +void omapdrm_reserve_vram(void) +{ +#ifdef CONFIG_CMA + /* + * Create private 32MiB contiguous memory area for omapdrm.0 device + * TODO revisit size.. if uc/wc buffers are allocated from CMA pages + * then the amount of memory we need goes up.. + */ + dma_declare_contiguous(&omap_drm_device.dev, 32 * SZ_1M, 0, 0); +#else +# warning "CMA is not enabled, there may be limitations about scanout buffer allocations on OMAP3 and earlier" +#endif +} + +#endif diff --git a/arch/arm/plat-omap/include/plat/drm.h b/arch/arm/plat-omap/include/plat/drm.h new file mode 100644 index 0000000..e29be29 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/drm.h @@ -0,0 +1,70 @@ +/* + * DRM/KMS device registration for TI OMAP platforms + * + * Copyright (C) 2012 Texas Instruments + * Author: Rob Clark <rob.clark(a)linaro.org> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * 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. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see <http://www.gnu.org/licenses/>. + */ + +#ifndef __PLAT_OMAP_DRM_H__ +#define __PLAT_OMAP_DRM_H__ + +/* + * Optional platform data to configure the default configuration of which + * pipes/overlays/CRTCs are used.. if this is not provided, then instead the + * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to + * one manager, with priority given to managers that are connected to + * detected devices. Remaining overlays are used as video planes. This + * should be a good default behavior for most cases, but yet there still + * might be times when you wish to do something different. + */ +struct omap_kms_platform_data { + /* overlays to use as CRTCs: */ + int ovl_cnt; + const int *ovl_ids; + + /* overlays to use as video planes: */ + int pln_cnt; + const int *pln_ids; + + int mgr_cnt; + const int *mgr_ids; + + int dev_cnt; + const char **dev_names; +}; + +struct omap_drm_platform_data { + struct omap_kms_platform_data *kms_pdata; + struct omap_dmm_platform_data *dmm_pdata; +}; + +struct omap_dmm_platform_data { + void __iomem *base; + int irq; +}; + +#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE) + +void omapdrm_reserve_vram(void); + +#else + +static inline void omapdrm_reserve_vram(void) +{ +} + +#endif + +#endif /* __PLAT_OMAP_DRM_H__ */ -- 1.7.5.4

5 20

[Bug 46213] [865G] Low framerate with glxgears and general low performance
by bugzilla-daemon＠freedesktop.org 17 Feb '12

17 Feb '12

https://bugs.freedesktop.org/show_bug.cgi?id=46213 Chris Wilson <chris(a)chris-wilson.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|idr(a)freedesktop.org |dri-devel(a)lists.freedesktop | |.org Component|Drivers/DRI/i915 |Drivers/DRI/i830 -- 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 42611] [865g] webgl enabled pages crash Firefox and mesa
by bugzilla-daemon＠freedesktop.org 17 Feb '12

17 Feb '12

https://bugs.freedesktop.org/show_bug.cgi?id=42611 Eugeni Dodonov <eugeni(a)dodonov.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eugeni(a)dodonov.net --- Comment #6 from Eugeni Dodonov <eugeni(a)dodonov.net> 2012-02-17 08:41:44 PST --- > I haven't yet found the time to file a new bug to Mesa, as they suggested, but i will do. I'm scared to upgrade to Mesa 8, because reading gen2 upstream > changelogs entry i suspect i'll have more breakage, since it talks about features removed... You don't have to upgrade mesa entirely just for this testing. You can compile and install it into any other directory (for example, with ./configure --prefix=/home/myuser/mesa; make; make install), and then use 'export LD_LIBRARY_PATH=/home/myuser/mesa/lib' to tell applications to use this mesa version for testing. This way, you'll still have your old mesa around in case 8.0.x is broken for you.. -- 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 39832] HDA ATI HDMI: no sound with 3.0 - 2.6.39.3 works
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '12

17 Feb '12

https://bugzilla.kernel.org/show_bug.cgi?id=39832 --- Comment #19 from Jonathan Nieder <jrnieder(a)gmail.com> 2012-02-17 05:38:13 --- (In reply to comment #18) > Is this still a problem in 3.2 / 3.3-rc1? Here's a report using 3.0 and 3.2.4: http://bugs.debian.org/659673 -- 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

Re: Business proposal
by Laurent Pinchart 16 Feb '12

16 Feb '12

Hi Koen, On Thursday 16 February 2012 23:46:51 Beel, Koen wrote: > Hi Laurent, > > Would it be possible to give us your number on which you can be reached next > Monday? I prefer to init the call from our side as we will join the call > with two people and we will be in a meeting room... (so not available on > our desk phone) Sure. You can call me at +32477410753. -- Regards, Laurent Pinchart

1 0

Mode validation outside of connector or encoder (i.e. at CRTC or drm_driver level)
by Matt Sealey 16 Feb '12

16 Feb '12

Quick question; if I want to validate a mode given to me by a connector/encoder as workable or not before I am going through the code to actually set that mode, how would I do this? I expected to see a mode_valid callback in crtc or somewhere similar. What I've got right now is a drm connector and encoder, which are describing a silicon image hdmi transmitter, and an embedded crtc connected to it. While the transmitter is fairly capable the crtc in the SoC is not (it has a maximum pixel clock limitation of 133MHz which means I have to kill off modes above that like 1080p@60. There are other things I may need to limit too). How do I coordinate such things from the drm_driver or crtc level up to the connector/encoder without making the connector/encoder intimately knowledgeable about the underlying crtc? Currently my only resort is to put the limits in platform data for the connector/encoder and use the mode_valid I already have to parse and discard modes which are plainly not going to be able to be clocked. -- Matt Sealey <matt(a)genesi-usa.com> Product Development Analyst, Genesi USA, Inc.

2 2

[RFC] drm: atomic mode set API
by Jesse Barnes 16 Feb '12

16 Feb '12

Many of us really want (and need) a way to set the whole display configuration atomically, as well as test a global config. In talking with Rob and Alex here at ELC a bit, I think this may be enough: diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h index 2a2acda..2864b02 100644 --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -157,6 +157,26 @@ struct drm_mode_get_plane_res { __u32 count_planes; }; +#define DRM_SET_CONFIG_TEST (1<<0) /* don't change the config, just test it for validity */ + +struct drm_mode_set_config { + __u64 crtcs; + __u64 crtc_fbs; + __u64 crtc_xpos; /* array of x coords for crtcs */ + __u64 crtc_ypos; /* array of y coords for crtcs */ + __u32 count_crtcs; + + __u64 plane_sets; /* array of set_plane structs */ + + __u32 count_planes; + + __u64 connectors; + __u64 connector_modes; + __u32 count_connectors; + + __u32 flags; +}; + #define DRM_MODE_ENCODER_NONE 0 #define DRM_MODE_ENCODER_DAC 1 #define DRM_MODE_ENCODER_TMDS 2 This allows you to bind a bunch of fbs to crtcs with independent positions, as well as set a bunch of planes to specific fbs and layouts. Finally, it lets you change the connector config at the same time, with a flag to simply test a config instead of actually setting it. Any comments? Do we also need to set gamma or other properties as part of this? What about cursors? Thanks, Jesse

6 8

[Bug 42611] [865g] webgl enabled pages crash Firefox and mesa
by bugzilla-daemon＠freedesktop.org 16 Feb '12

16 Feb '12

https://bugs.freedesktop.org/show_bug.cgi?id=42611 --- Comment #5 from Cesare Leonardi <celeonar(a)gmail.com> 2012-02-16 15:54:01 UTC --- Will, have you already upgraded to Mesa 8 from experimental? The problem is not resolved for me (i855) and i do not reopen this bug only because your bug is specific to Drivers/DRI/i830. I've renamed my mozilla profile and then created a fresh new user as you suggested: Firefox still crashes with about:support and other sites with the same Mesa error you reported. This Mozilla bug seems to prove that there is an Intel/Mesa bug somewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=696636 I haven't yet found the time to file a new bug to Mesa, as they suggested, but i will do. I'm scared to upgrade to Mesa 8, because reading gen2 upstream changelogs entry i suspect i'll have more breakage, since it talks about features removed... Cesare. -- 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

← Newer
1
...
47
48
49
50
51
52
53
...
63
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2012