[PATCH] drm/radeon/kms: do not force DVI mode on DCE4 if audio is on

2011/12/7 Alex Deucher : > 2011/12/7 Rafa? Mi?ecki : >> >> Signed-off-by: Rafa? Mi?ecki >> --- >> ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?6 +++--- >> ?1 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c >>

[PATCH] drm/radeon/kms: do not force DVI mode on DCE4 if audio is on

Signed-off-by: Rafa? Mi?ecki --- drivers/gpu/drm/radeon/atombios_encoders.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c index 39c04c1..63e5426 100644 ---

[PATCH 3/3] drm/radeon/kms: enable HDMI mode on Evergreen encoders

Signed-off-by: Rafa? Mi?ecki --- drivers/gpu/drm/radeon/evergreen_reg.h | 10 +++ drivers/gpu/drm/radeon/r600_hdmi.c | 44 ++-- 2 files changed, 46 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_reg.h

[PATCH 2/3] drm/radeon/kms: support for audio on Evergreen

Signed-off-by: Rafa? Mi?ecki --- drivers/gpu/drm/radeon/evergreen.c | 14 ++ drivers/gpu/drm/radeon/evergreen_reg.h |8 drivers/gpu/drm/radeon/r600_audio.c| 22 +++--- 3 files changed, 41 insertions(+), 3 deletions(-) diff --git

[PATCH 1/3] drm/radeon/kms: one more HDMI cleanup (in disabling code)

Signed-off-by: Rafa? Mi?ecki --- drivers/gpu/drm/radeon/r600_hdmi.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index 5021372..06f923e 100644 --- a/drivers/gpu/drm/radeon/r600_hdmi.c

[Bug 43395] Game running in wine stops rendering

https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #13 from Tomas Schlosser 2011-12-07 13:33:53 PST --- (In reply to comment #12) > Does setting the environment variable vblank_mode=0 for the Wine process using > OpenGL work around the problem? There should be a message > >

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

When "MC timeout" happens at GPU reset, we found the 12th and 13th bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these two bits are like this: #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1) #define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1)

[PATCH 9/9] gma500: SDVO DDC bus guessing isn't working so hardcode it instead

We currently don't have support for parsing SDVO mappings from BIOS so we're guessing the bus switch parameter. This isn't working so hardcode it to a configuration known to work on most poulsbo hardware. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/psb_intel_sdvo.c |8

[PATCH 8/9] gma500: Convert Moorestown to work with new output handling

Replace psb_intel_output with psb_intel_encoder and psb_intel_connector Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/oaktrail_crtc.c | 18 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 29 +++ drivers/gpu/drm/gma500/oaktrail_lvds.c | 79

[PATCH 7/9] gma500: Convert Cedarview to work with new output handling

Replace psb_intel_output with psb_intel_encoder and psb_intel_connector. Things will need to be cleaned up and tested so consider this an initial patch for Cedarview. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/cdv_intel_crt.c | 47 +++-

[PATCH 6/9] gma500: Replace SDVO code with slightly modified version from i915

Our current SDVO implementation is not working properly, so replace it with a modified version of the i915. Further testing and debugging is needed to make sure we can handle the different SDVO setups and wiring. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/psb_drv.h |

[PATCH 5/9] gma500: Add support for Intel GMBUS

Before we integrate the new SDVO code we need GMBUS support Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/Makefile|1 + drivers/gpu/drm/gma500/intel_gmbus.c | 493 drivers/gpu/drm/gma500/psb_device.c|7 +

[PATCH 4/9] gma500: Convert PSB LVDS to new output handling

LVDS for PSB now uses psb_intel_encoder and psb_intel_connectors instead of psb_intel_output. i2c_bus and ddc_bus are moved to lvds_priv. There was also a pointer to mode_dev (for no obvious reason) that we now get directly from dev_priv. Signed-off-by: Patrik Jakobsson ---

[PATCH 3/9] gma500: Fix encoder type checking for connectors

Fix cases where we need to know what encoder type is behind a given connector. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/framebuffer.c |8 drivers/gpu/drm/gma500/psb_drv.c |6 +++--- drivers/gpu/drm/gma500/psb_intel_display.c | 24

[PATCH 2/9] gma500: Remove psb_intel_output from ddc_probe and ddc_get_modes

Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/psb_intel_drv.h |5 +++-- drivers/gpu/drm/gma500/psb_intel_modes.c | 16 +++- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h

[PATCH 1/9] gma500: Initial support for our encoder and connector structs

First step towards adding i915 alike encoder and connector abstractions. This will make life easier when adding i915 output code into our driver. It also removes the old psb_intel_output struct. Signed-off-by: Patrik Jakobsson --- drivers/gpu/drm/gma500/psb_intel_display.c |7 +

[PATCH 0/9] gma500: Fix SDVO DDC probing on Poulsbo

This set of patches removes psb_intel_output and replaces it with psb_intel_encoder and psb_intel_connector. It also replaces the SDVO code with a slightly modified version from i915. i915 SDVO needs Intel gmbus so this is added along with a SDVO DDC bus guessing fix for Poulsbo. Patrik Jakobsson

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Daniel, Rob, On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark wrote: > On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter wrote: >> On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote: >>> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote: >>> > In the patch 2, you have a section about

[PATCH] drm/edid: Try harder to fix up broken headers

There's no reason to force the first byte to be correct if we're already scoring how correct the header is. See also: https://bugzilla.redhat.com/show_bug.cgi?id=722909 Signed-off-by: Adam Jackson --- drivers/gpu/drm/drm_edid.c | 18 -- 1 files changed, 8 insertions(+), 10

[PATCH 3/3] drm/radeon/kms: enable HDMI mode on Evergreen encoders

2011/12/7 Rafa? Mi?ecki : > > Signed-off-by: Rafa? Mi?ecki > --- > ?drivers/gpu/drm/radeon/evergreen_reg.h | ? 10 +++ > ?drivers/gpu/drm/radeon/r600_hdmi.c ? ? | ? 44 > ++-- > ?2 files changed, 46 insertions(+), 8 deletions(-) > > diff --git

[PATCH] drm/radeon/kms: do not force DVI mode on DCE4 if audio is on

2011/12/7 Rafa? Mi?ecki : > > Signed-off-by: Rafa? Mi?ecki > --- > ?drivers/gpu/drm/radeon/atombios_encoders.c | ? ?6 +++--- > ?1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c > b/drivers/gpu/drm/radeon/atombios_encoders.c > index

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann wrote: > On Wednesday 07 December 2011, Semwal, Sumit wrote: >> > >> > Do you have a use case for making the interface compile-time disabled? >> > I had assumed that any code using it would make no sense if it's not >> > available so you don't

[PATCH 08/23] drm/via: use drm_mm instead of drm_sman

> Chris Wilson rightly complained that this doesn't explain the list_del > magic going on. New commit msg reads: > > To make the transition in a piece-wise and bisectable way possible, > I've hijacked the ->owner_list from drm_sman. While transitioning, the > list_add was done by the

[PATCH 10/23] drm: kill drm_sman

> No longer used. > > Signed-off-by: Daniel Vetter Acked-by: James Simmons > --- > drivers/gpu/drm/Makefile |2 +- > drivers/gpu/drm/drm_sman.c | 210 > > include/drm/drm_sman.h | 151 --- > 3 files

[PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

> Signed-off-by: Daniel Vetter Can't test on SiS but does nothing to my VIA hardware. Acked-by: James Simmons > --- > drivers/gpu/drm/sis/sis_drv.c |4 - > drivers/gpu/drm/sis/sis_drv.h |5 +- > drivers/gpu/drm/sis/sis_mm.c | 137 +++- > 3 files

[PATCH 08/23] drm/via: use drm_mm instead of drm_sman

> Now that we are again in proper control of owner_list, we need to > properly list_del it on free. > > Signed-off-by: Daniel Vetter Acked-by: James Simmons > --- > drivers/gpu/drm/via/via_drv.h |5 ++- > drivers/gpu/drm/via/via_map.c |7 > drivers/gpu/drm/via/via_mm.c | 72

[PATCH 07/23] drm/sman: kill user_hash_tab

> No longer used. > > Signed-off-by: Daniel Vetter Acked-by: James Simmons > --- > drivers/gpu/drm/drm_sman.c | 36 ++-- > include/drm/drm_sman.h |5 - > 2 files changed, 2 insertions(+), 39 deletions(-) > > diff --git

[PATCH 06/23] drm/sis: track user->memblock mapping with idr

> Signed-off-by: Daniel Vetter Acked-by: James Simmons > --- > drivers/gpu/drm/sis/sis_drv.c |4 +++ > drivers/gpu/drm/sis/sis_drv.h |2 + > drivers/gpu/drm/sis/sis_mm.c | 60 ++-- > drivers/gpu/drm/via/via_map.c |2 + > 4 files changed, 53

[PATCH 05/23] drm/via: track user->memblock mapping with idr

> Massive indirection through a hashtable for a simple key->pointer > look-up actually just adds bloat. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/via/via_drv.h |2 + > drivers/gpu/drm/via/via_map.c |1 + > drivers/gpu/drm/via/via_mm.c | 61 >

[PATCH 04/23] drm/sman: rip out owner tracking

> In contrast to kms drivers, sis/via _always_ associated a buffer with > a drm fd. So by the time we reach lastclose, all open drm fds are gone > and with them their associated objects. > > So when sis/via call drm_sman_cleanup in their lastclose funcs, that > will free 0 objects. > > The

[PATCH 03/23] drm/sman: kill owner tracking interface functions

> These are now unused. > > Signed-off-by: Daniel Vetter Acked-by: James Simmons > --- > drivers/gpu/drm/drm_sman.c | 38 -- > include/drm/drm_sman.h | 19 --- > 2 files changed, 0 insertions(+), 57 deletions(-) > > diff --git

[PATCH 02/23] drm/via: track obj->drm_fd relations in the driver

> Exactly like the previous patch for sis. > > Signed-off-by: Daniel Vetter Acked-by: James Simmons Same goes for PATCH 01 which I'm missing in my inbox. > --- > drivers/gpu/drm/via/via_drv.c | 25 + > drivers/gpu/drm/via/via_mm.c | 22 ++ >

Request for fixing atombios_get_encoder_mode

W dniu 7 grudnia 2011 15:53 u?ytkownik Alex Deucher napisa?: > 2011/12/7 Rafa? Mi?ecki : >> W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher >> napisa?: >>> 2011/12/7 Rafa? Mi?ecki : In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

On 2011.12.07 at 15:32 +0100, Robert Richter wrote: > On 02.12.11 21:48:20, Markus Trippelsdorf wrote: > > BTW I always see (mostly only on screen, sometimes in the logs): > > > > [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector > > 0x10400, but the register is already in use

Request for fixing atombios_get_encoder_mode

W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher napisa?: > 2011/12/7 Rafa? Mi?ecki : >> In theory function atombios_get_encoder_mode should report >> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report >> ATOM_ENCODER_MODE_DVI if card is DCE4. >> >> Is there any reason for it?

WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

On 02.12.11 21:48:20, Markus Trippelsdorf wrote: > BTW I always see (mostly only on screen, sometimes in the logs): > > [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400, > but the register is already in use for vector 0xf9 on another cpu > [Firmware Bug]: cpu 2, IBS

[PATCH] drm/edid: Add support for extension blocks beyond the first

When 2 or more EDID extension blocks are present, segment must be selected prior to reading the extended EDID block over the DDC channel. Add support for this. Signed-off-by: Jean Delvare Cc: Adam Jackson --- This needs testing by someone with access to such a display.

[PATCH] This patch enables the reading of the 3D capabilities of t=

he connected HDMI monitor. Currently only the 3D format support fields are read. Later this could be extended. This information is expected to be sent to the user space which then sets the format on the monitor. This patch also handles DIP register signaling to the HDMI connected 3D monitor

[PATCH 00/23] kill drm cruft with fire

> > >> Testing this on via would be awesome! Iirc I haven't changed anything in > > >> the via specific patches, but if it's more convenient you can also > > >> directly test my branch: > > >> > > >> http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > > > > > Okay I tried the

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: > Thanks for the excellent discussion - it indeed is very good learning > for the relatively-inexperienced me :) > > So, for the purpose of dma-buf framework, could I summarize the > following and rework accordingly?: > 1. remove mmap()

Request for fixing atombios_get_encoder_mode

In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is there any reason for it? Can we just drop that DCE4 condition? This fixme seems to be here since ever. -- Rafa?

Request for fixing atombios_get_encoder_mode

In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is there any reason for it? Can we just drop that DCE4 condition? This fixme seems to be here since ever. -- Rafa?

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Arnd, Thanks for your review! On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann wrote: > On Friday 02 December 2011, Sumit Semwal wrote: >> This is the first step in defining a dma buffer sharing mechanism. > > This looks very nice, but there are a few things I don't understand yet > and a bunch

drm/ttm: callback move_notify any time bo placement

change v4 Hello Jerome Glisse, This is a semi-automatic email about new static checker warnings. The patch dc97b3409a79: "drm/ttm: callback move_notify any time bo placement change v4" from Nov 18, 2011, leads to the following Smatch complaint: drivers/gpu/drm/nouveau/nouveau_bo.c +818

Request for fixing atombios_get_encoder_mode

2011/12/7 Rafa? Mi?ecki : > W dniu 7 grudnia 2011 15:53 u?ytkownik Alex Deucher > napisa?: >> 2011/12/7 Rafa? Mi?ecki : >>> W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher >>> napisa?: 2011/12/7 Rafa? Mi?ecki : > In theory function atombios_get_encoder_mode should report >

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: > Right; that would be ideal, but we may not be able to ask each user to > do so - especially when the sharing part might be interspersed in > existing buffer handling code. So for now, I would like to keep it as > it-is. Ok, fair enough. It

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

ext attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/b21a02a6/attachment.pgp>

[PATCH] libdrm: plane & addfb2 support

uint32_t src_w, uint32_t src_h); + #if defined(__cplusplus) || defined(c_plusplus) } #endif -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/773a9eb1/attachment-0001.pgp>

[git pull] drm fixes the reduced version

Hi Linus, Okay the 2 non-kexec fixes + one of the calloc changes as by looking at it, there was nothing stopping userspace for abusing the integer overflow on these ioctls. The other calloc changes either were kernel internal or had other things stopping userspace from exploiting them. Dave.

Noise in games on Intel HD Graphics 2000

-- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111207/151f7820/attachment.pgp>

[PATCH] drm/radeon/benchmark: common modes sweep ignores 640x480@32

From: Chen Jie Sweep common_modes array should start with index 0. Signed-off-by: Chen Jie --- drivers/gpu/drm/radeon/radeon_benchmark.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c

[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: > > > > Do you have a use case for making the interface compile-time disabled? > > I had assumed that any code using it would make no sense if it's not > > available so you don't actually need this. > > Ok. Though if we keep the interface

Request for fixing atombios_get_encoder_mode

2011/12/7 Rafa? Mi?ecki : > W dniu 7 grudnia 2011 14:53 u?ytkownik Alex Deucher > napisa?: >> 2011/12/7 Rafa? Mi?ecki : >>> In theory function atombios_get_encoder_mode should report >>> ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report >>> ATOM_ENCODER_MODE_DVI if card is DCE4.

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

2011/12/7 : > When "MC timeout" happens at GPU reset, we found the 12th and 13th > bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these > two bits are like this: > #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1) > #define G_000E50_MCDW_BUSY(x)

Request for fixing atombios_get_encoder_mode

2011/12/7 Rafa? Mi?ecki : > In theory function atombios_get_encoder_mode should report > ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report > ATOM_ENCODER_MODE_DVI if card is DCE4. > > Is there any reason for it? Can we just drop that DCE4 condition? This > fixme seems to be here

[git pull] drm fixes

> So having looked at the patch itself, I don't dislike the notion of > making sure certain fields are nicely initialized. So I don't hate the > patch itself, but quite frankly, to me it doesn't smell even > *remotely* like "regression fix". I don't think this is something that > has ever worked.

[PATCH] drm/radeon/benchmark: common modes sweep ignores 640x480@32

Right. The goof is a consequence of me doing copy-and-paste style edits. I first added powers-of-two benchmark which intentionally start from index 1 but and then copied and edited that into comon-modes benchmark, and missed to correct the starting index of the loop. Reviewed-by: Ilija Hadzic

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

On Wed, Dec 7, 2011 at 3:31 AM, Tomi Valkeinen wrote: > Hi, > > On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote: >> From: Rob Clark >> >> Support for DMM and tiled buffers. ?The DMM/TILER block in omap4+ SoC >> provides support for remapping physically discontiguous buffers for >> various DMA

[Bug 43395] Game running in wine stops rendering

https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #12 from Michel D?nzer 2011-12-07 03:17:11 UTC --- Does setting the environment variable vblank_mode=0 for the Wine process using OpenGL work around the problem? There should be a message ATTENTION: default value of option

Re: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]

On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: Add Cc. to platform-driver-x86 and linux-acpi Hi Baptiste 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到： Hi, I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't have a keyboard, but two displays with

Noise in games on Intel HD Graphics 2000

Hi, I'm running on Intel i3 2100 integrated graphics, I'm getting some strange noise particles in games like Minecraft and Speed Dreams (mostly noticeable in Minecraft) after playing a while, like half an hour. After that restarting game doesn't help, only computer restart have the effect

Re: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]

Hi Baptiste, On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez bapti...@jonglez.org wrote: On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: Add Cc. to platform-driver-x86 and linux-acpi Hi Baptiste 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到： Hi, I've got a lot of troubles

Re: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]

On Tue, Dec 06, 2011 at 11:12:26PM +0100, Benjamin Tissoires wrote: Hi Baptiste, Hi, On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez bapti...@jonglez.org wrote: The second screen works fine with the attached patch. It actually is 6 months old but seems to have been lost in the wild...

Re: [git pull] drm fixes

So having looked at the patch itself, I don't dislike the notion of making sure certain fields are nicely initialized. So I don't hate the patch itself, but quite frankly, to me it doesn't smell even *remotely* like regression fix. I don't think this is something that has ever worked. Well

Re: [PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers

Hi, On Mon, 2011-12-05 at 19:19 -0600, Rob Clark wrote: From: Rob Clark r...@ti.com Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC provides support for remapping physically discontiguous buffers for various DMA initiators (DSS, IVAHD, etc) which do not otherwise

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: Do you have a use case for making the interface compile-time disabled? I had assumed that any code using it would make no sense if it's not available so you don't actually need this. Ok. Though if we keep the interface compile-time

[git pull] drm fixes the reduced version

Hi Linus, Okay the 2 non-kexec fixes + one of the calloc changes as by looking at it, there was nothing stopping userspace for abusing the integer overflow on these ioctls. The other calloc changes either were kernel internal or had other things stopping userspace from exploiting them. Dave.

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 07 December 2011, Semwal, Sumit wrote: Do you have a use case for making the interface compile-time disabled? I had assumed that any code using it would make no sense if it's not available so you don't

[Bug 43395] Game running in wine stops rendering

https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #12 from Michel Dänzer mic...@daenzer.net 2011-12-07 03:17:11 UTC --- Does setting the environment variable vblank_mode=0 for the Wine process using OpenGL work around the problem? There should be a message ATTENTION: default value

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: Right; that would be ideal, but we may not be able to ask each user to do so - especially when the sharing part might be interspersed in existing buffer handling code. So for now, I would like to keep it as it-is. Ok, fair enough. It

Request for fixing atombios_get_encoder_mode

In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is there any reason for it? Can we just drop that DCE4 condition? This fixme seems to be here since ever. -- Rafał

Request for fixing atombios_get_encoder_mode

In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is there any reason for it? Can we just drop that DCE4 condition? This fixme seems to be here since ever. -- Rafał

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Daniel, Rob, On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark r...@ti.com wrote: On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote: On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote: In the patch 2,

re: drm/ttm: callback move_notify any time bo placement

change v4 Hello Jerome Glisse, This is a semi-automatic email about new static checker warnings. The patch dc97b3409a79: drm/ttm: callback move_notify any time bo placement change v4 from Nov 18, 2011, leads to the following Smatch complaint: drivers/gpu/drm/nouveau/nouveau_bo.c +818

Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Wednesday 07 December 2011, Semwal, Sumit wrote: Thanks for the excellent discussion - it indeed is very good learning for the relatively-inexperienced me :) So, for the purpose of dma-buf framework, could I summarize the following and rework accordingly?: 1. remove mmap() dma_buf_op

Re: [PATCH] drm/radeon/benchmark: common modes sweep ignores 640x480@32

Right. The goof is a consequence of me doing copy-and-paste style edits. I first added powers-of-two benchmark which intentionally start from index 1 but and then copied and edited that into comon-modes benchmark, and missed to correct the starting index of the loop. Reviewed-by: Ilija

Re: Request for fixing atombios_get_encoder_mode

2011/12/7 Rafał Miłecki zaj...@gmail.com: In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is there any reason for it? Can we just drop that DCE4 condition? This fixme seems to

Re: [PATCH 00/23] kill drm cruft with fire

Testing this on via would be awesome! Iirc I haven't changed anything in the via specific patches, but if it's more convenient you can also directly test my branch: http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire Okay I tried the patches and it locked up the

Re: Request for fixing atombios_get_encoder_mode

W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com: In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report ATOM_ENCODER_MODE_DVI if card is DCE4. Is

Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413

On 2011.12.07 at 15:32 +0100, Robert Richter wrote: On 02.12.11 21:48:20, Markus Trippelsdorf wrote: BTW I always see (mostly only on screen, sometimes in the logs): [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x10400, but the register is already in use for

Re: Request for fixing atombios_get_encoder_mode

2011/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com: In theory function atombios_get_encoder_mode should report ATOM_ENCODER_MODE_HDMI when TV supports audio. Current we report

Re: Request for fixing atombios_get_encoder_mode

W dniu 7 grudnia 2011 15:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com: In theory function

Re: [PATCH 02/23] drm/via: track obj-drm_fd relations in the driver

Exactly like the previous patch for sis. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org Same goes for PATCH 01 which I'm missing in my inbox. --- drivers/gpu/drm/via/via_drv.c | 25 +

Re: [PATCH 03/23] drm/sman: kill owner tracking interface functions

These are now unused. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/drm_sman.c | 38 -- include/drm/drm_sman.h | 19 --- 2 files changed, 0

Re: [PATCH 04/23] drm/sman: rip out owner tracking

In contrast to kms drivers, sis/via _always_ associated a buffer with a drm fd. So by the time we reach lastclose, all open drm fds are gone and with them their associated objects. So when sis/via call drm_sman_cleanup in their lastclose funcs, that will free 0 objects. The owner

Re: [PATCH 05/23] drm/via: track user-memblock mapping with idr

Massive indirection through a hashtable for a simple key-pointer look-up actually just adds bloat. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/via/via_drv.h |2 + drivers/gpu/drm/via/via_map.c |1 + drivers/gpu/drm/via/via_mm.c | 61

Re: [PATCH 06/23] drm/sis: track user-memblock mapping with idr

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/sis/sis_drv.c |4 +++ drivers/gpu/drm/sis/sis_drv.h |2 + drivers/gpu/drm/sis/sis_mm.c | 60 ++--

Re: [PATCH 07/23] drm/sman: kill user_hash_tab

No longer used. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/drm_sman.c | 36 ++-- include/drm/drm_sman.h |5 - 2 files changed, 2 insertions(+), 39 deletions(-)

Re: [PATCH 08/23] drm/via: use drm_mm instead of drm_sman

Now that we are again in proper control of owner_list, we need to properly list_del it on free. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/via/via_drv.h |5 ++- drivers/gpu/drm/via/via_map.c |7

Re: [PATCH 09/23] drm/sis: use drm_mm instead of drm_sman

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Can't test on SiS but does nothing to my VIA hardware. Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/sis/sis_drv.c |4 - drivers/gpu/drm/sis/sis_drv.h |5 +- drivers/gpu/drm/sis/sis_mm.c | 137

Re: [PATCH 10/23] drm: kill drm_sman

No longer used. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: James Simmons jsimm...@infradead.org --- drivers/gpu/drm/Makefile |2 +- drivers/gpu/drm/drm_sman.c | 210 include/drm/drm_sman.h | 151

Re: [PATCH 08/23] drm/via: use drm_mm instead of drm_sman

Chris Wilson rightly complained that this doesn't explain the list_del magic going on. New commit msg reads: To make the transition in a piece-wise and bisectable way possible, I've hijacked the -owner_list from drm_sman. While transitioning, the list_add was done by the

Re: Request for fixing atombios_get_encoder_mode

2011/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 7 grudnia 2011 15:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 7 grudnia 2011 14:53 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2011/12/7 Rafał Miłecki zaj...@gmail.com:

[PATCH 0/9] gma500: Fix SDVO DDC probing on Poulsbo

This set of patches removes psb_intel_output and replaces it with psb_intel_encoder and psb_intel_connector. It also replaces the SDVO code with a slightly modified version from i915. i915 SDVO needs Intel gmbus so this is added along with a SDVO DDC bus guessing fix for Poulsbo. Patrik Jakobsson

[PATCH 1/9] gma500: Initial support for our encoder and connector structs

First step towards adding i915 alike encoder and connector abstractions. This will make life easier when adding i915 output code into our driver. It also removes the old psb_intel_output struct. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com ---

[PATCH 2/9] gma500: Remove psb_intel_output from ddc_probe and ddc_get_modes

Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/gma500/psb_intel_drv.h |5 +++-- drivers/gpu/drm/gma500/psb_intel_modes.c | 16 +++- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h

[PATCH 3/9] gma500: Fix encoder type checking for connectors

Fix cases where we need to know what encoder type is behind a given connector. Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/gma500/framebuffer.c |8 drivers/gpu/drm/gma500/psb_drv.c |6 +++---

[PATCH 4/9] gma500: Convert PSB LVDS to new output handling

LVDS for PSB now uses psb_intel_encoder and psb_intel_connectors instead of psb_intel_output. i2c_bus and ddc_bus are moved to lvds_priv. There was also a pointer to mode_dev (for no obvious reason) that we now get directly from dev_priv. Signed-off-by: Patrik Jakobsson

[PATCH 5/9] gma500: Add support for Intel GMBUS

Before we integrate the new SDVO code we need GMBUS support Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/gma500/Makefile|1 + drivers/gpu/drm/gma500/intel_gmbus.c | 493 drivers/gpu/drm/gma500/psb_device.c|

[PATCH 8/9] gma500: Convert Moorestown to work with new output handling

Replace psb_intel_output with psb_intel_encoder and psb_intel_connector Signed-off-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com --- drivers/gpu/drm/gma500/oaktrail_crtc.c | 18 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 29 +++ drivers/gpu/drm/gma500/oaktrail_lvds.c |

  1   2   >