[Bug 53471] Radeon card occasionally locks when enabling KMS.

https://bugzilla.kernel.org/show_bug.cgi?id=53471 --- Comment #3 from Chris Rankin --- This particular intermittent problem hasn't occurred again, but I can't claim to know whether it has been fixed. -- You are receiving this mail because: You are watching the assignee of the bug.

[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/bed4ee40/attachment-0001.pgp>

[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

On 18/11/13 01:08, Keith Packard wrote: > libudev doesn't have a stable API/ABI, and if the application wants to use one > version, we'd best not load another into libGL. > > Signed-off-by: Keith Packard > --- > Hi Keith, Did you had the chance to look at src/gallium/targets/egl-static/egl.c?

[Bug 64226] python-opencl package generate segmentation fault at pipe_r600.so

|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/e8cda89d/attachment.html>

[Bug 64226] python-opencl package generate segmentation fault at pipe_r600.so

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/dea78b5f/attachment.html>

[Bug 52171] [gallium/r600/clover] Simple benchmarks failed to run

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4987a921/attachment.html>

[Bug 71753] Radeon Audio clock running wrong speed

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/0239973d/attachment.html>

[Bug 71753] Radeon Audio clock running wrong speed

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/8c4a3ca6/attachment.html>

[Bug 71753] Radeon Audio clock running wrong speed

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4411faa0/attachment-0001.html>

[Bug 71753] New: Radeon Audio clock running wrong speed

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/2316fbb7/attachment.html>

[PATCH 1/2] radeon: fix mipmap level 0 and 1 alignment for SI and CIK

On Fre, 2013-11-15 at 18:55 +0100, Marek Ol??k wrote: > From: Michel D?nzer > > Signed-off-by: Marek Ol??k [...] > @@ -1657,10 +1659,7 @@ static int si_surface_init_2d(struct > radeon_surface_manager *surf_man, > tile_mode = SI_TILE_MODE_COLOR_1D_SCANOUT; >

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/5142c525/attachment.html>

[PATCH 2/2] drm/radeon/cik: Add macrotile mode array query

From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/cik.c| 3 +++ drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- drivers/gpu/drm/radeon/radeon_kms.c | 9 + include/uapi/drm/radeon_drm.h

[PATCH 1/2] drm/radeon/cik: Return backend map information to userspace

From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index bb87105..fa42c81 100644 ---

[PATCH v3 1/7] drm: Add DSI bus infrastructure

On 11/18/2013 01:57 PM, Thierry Reding wrote: > On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote: >> Hi Thierry, >> >> On 11/13/2013 10:38 PM, Thierry Reding wrote: >>> On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote: Hi Thierry, I have already sent patch

[Mesa-dev] rules for merging patches to libdrm

libdrm equivalent can be merged, > >> > then having both release cycles in lockstep makes some sense. > >> > >> Not sure about strictly tying it to kernel releases would be ideal. > >> Not *everything* in libdrm is about new kernel APIs. It tends to be > >> the place for things needed both by xorg ddx and mesa driver, which I > >> suppose is why it ends up a bit of a free-for-all. > > > > I didn't mean that every release would need to be tied to the Linux > > kernel. But whenever a new Linux kernel release was made, relevant > > changes from the public headers could be pulled into libdrm and a > > release be made. I could even imagine a matching of version numbers. > > libdrm releases could be numbered using the same major and minor as > > Linux kernels that they support. Micro version numbers could be used > > in intermediate releases. > > maybe an update-kernel-headers.sh script to grab the headers from > drm-next and update libdrm wouldn't be a bad idea? Perhaps. But I think it could even be a manual step. It's not something that one person should be doing alone, but rather something that driver maintainers should be doing, since they know best what will be needed in a new version of libdrm. Like I mentioned in another subthread, I think a subtree-oriented model could work well. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/5df0bde5/attachment-0001.pgp>

[Mesa-dev] rules for merging patches to libdrm

rably wait until it appears in torvalds/linux.git, but it seems airlied > has a > lower standard. :) > > Sometimes software bugs might warrant a release too, so this middle area is > needed. Having a different development model doesn't exclude the possibility for bugfix releases. Neither does explicit control of what patches are merged. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1db723ca/attachment.pgp>

[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers

On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding wrote: >> Note that there's already a bit of abstraction for i2c over dp aux, but >> imo that's at the wrong level. At least reading through i915, gma500 and >> radeon code there's a lot more we could share with just a dp aux helper >> library

[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers

e to duplicate the training in every new driver. I was half expecting to be required to come up with the generic code again, but if everyone is okay with this I won't bother with it for now. > Note that there's already a bit of abstraction for i2c over dp aux, but > imo that's at the wrong level. At least reading through i915, gma500 and > radeon code there's a lot more we could share with just a dp aux helper > library (which then implements useful stuff on top of it). I have some difficulty envisioning how the helper code can work without some sort of driver-specific ops implementation. Currently the helpers only use a snapshot of the DPCD to extract information. Eventually we'll be bound to modify the DPCD, so some method of writing it back (or a subset of it) will be needed. Otherwise the scope of the helper library will be somewhat limited. Once we have the callbacks, the current helpers could be reworked to not use a buffer, but rather an "AUX channel object" and access the registers directly. If there are concerns about performance, it could possibly be implemented as a sort of cache, too. That would make it fast to query the status. I don't think it'll be worth the added complexity, though. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/9fc2248c/attachment.pgp>

[Mesa-dev] rules for merging patches to libdrm

op 09-11-13 22:26, Ian Romanick schreef: > On 11/09/2013 12:11 AM, Dave Airlie wrote: How does this interact with the rule that kernel interfaces require an open source userspace? Is "here are the mesa/libdrm patches that use it" sufficient to get the kernel interface merged? >>>

[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

MIPI DSI bus allows to model DSI hosts and DSI devices using Linux bus. Signed-off-by: Andrzej Hajda Signed-off-by: Kyungmin Park --- Hi, This is my implementation of mipi dsi bus. The first time it was posted as a part of CDF infrastructure [1], but if it can be merged independently I will be

[PATCH 0/5] R-Car DU fixes and support for R8A7791

Hi Laurent, I am wondering if you have any patches to wire up this driver for the Koelsch board so that I might test it. On Wed, Nov 13, 2013 at 02:52:10PM +0100, Laurent Pinchart wrote: > Hello, > > This patch series adds support for the DU found in the R8A7791 SoC. It starts > by a cleanup

[Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers

On Mon, Nov 18, 2013 at 04:26:17PM +0100, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 10:09:56AM -0500, Alex Deucher wrote: > > On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding > > wrote: > > > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote: > > >> Debug print the capabilities,

[Bug 53471] Radeon card occasionally locks when enabling KMS.

https://bugzilla.kernel.org/show_bug.cgi?id=53471 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2

[PATCH 2/2] drm/i915/dp: check eDP display control capability registers

be made to work. The tricky part would be > hw specific ordering in the training sequence. At the very minimum, > you need driver callbacks to set up the source side: > > set_training_pattern() > set_vs_emph() > > And probably some flags to indicate whether the the hw supports > sp

[Mesa-dev] rules for merging patches to libdrm

a matching of version numbers. libdrm releases could be numbered using the same major and minor as Linux kernels that they support. Micro version numbers could be used in intermediate releases. > Maybe limiting who does releases would be sufficient. Unless there is > someone with enough free time and energy to volunteer to be libdrm > maintainer. > > But tbh I don't think it has been too much of a problem in the past. > I'm not sure if I actually read somewhere the rule about not updating > kernel headers until the interface is locked in (ie. drm-next), but it > seemed like common sense to me. Could be enough just to document this > a bit more explicitly. It's not something I feel very strongly about. People seemed unhappy about the current state of affairs, so I thought I'd dump a few ideas. =) Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/436769ea/attachment.pgp>

[Bug 53111] vgaswitcheroo not working anymore

https://bugzilla.kernel.org/show_bug.cgi?id=53111 Alan changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because:

[Bug 53111] vgaswitcheroo not working anymore

https://bugzilla.kernel.org/show_bug.cgi?id=53111 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC|

[PATCH] drm/ttm: Remove set_need_resched from the ttm fault handler

On Thu, Nov 14, 2013 at 7:49 PM, Thomas Hellstrom wrote: > Addresses > "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE". > > In the first occurence it was used to try to be nice while releasing the > mmap_sem and retrying the fault to work around a locking inversion. > The

[Bug 53471] Radeon card occasionally locks when enabling KMS.

https://bugzilla.kernel.org/show_bug.cgi?id=53471 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk

[PATCH] radeon: don't overallocate stencil by 4 on SI and CIK

From: Michel D?nzer Signed-off-by: Marek Ol??k --- radeon/radeon_surface.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 927a21e..cd5cbd6 100644 --- a/radeon/radeon_surface.c +++

[PATCH 2/2] drm/i915/dp: check eDP display control capability registers

Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/e9a02036/attachment.pgp>

[PATCH 1/2] drm/dp: add eDP 1.2 display control DPCD register definitions

next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/e18e0f22/attachment.pgp>

[Mesa-dev] rules for merging patches to libdrm

ndency. I wonder if perhaps tying the libdrm releases more tightly to Linux kernel releases would help. Since there already is a requirement for new kernel APIs to be merged before the libdrm equivalent can be merged, then having both release cycles in lockstep makes some sense. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/d3912c84/attachment.pgp>

[Bug 71681] some artefacts on X1250 with desktop elements drawn badly and screen blinks

l/attachments/20131118/59d34eb2/attachment-0001.html>

[Bug 71681] some artefacts on X1250 with desktop elements drawn badly and screen blinks

e assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/031f29cc/attachment.html>

[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings

This patch adds dt support to hdmiphy config settings as it is board specific and depends on the signal pattern of board. Signed-off-by: Shirish S --- .../devicetree/bindings/video/exynos_hdmi.txt | 33 + drivers/gpu/drm/exynos/exynos_hdmi.c | 77

[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/cros5250-common.dtsi | 74 1 file changed, 74 insertions(+)

[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-arndale.dts | 74 ++ 1 file changed, 74 insertions(+)

[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings

This patch moves the hdmi phy setting to smdk5250 dts,as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-smdk5250.dts | 74 + 1 file changed, 74 insertions(+)

[PATCH 0/4] Add dt support for exynos hdmiphy settings

For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values

[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2013 06:43 PM, Keith Packard wrote: > Emil Velikov writes: > >> On 18/11/13 01:08, Keith Packard wrote: >>> libudev doesn't have a stable API/ABI, and if the application >>> wants to use one version, we'd best not load another into >>>

[PATCH v3 1/7] drm: Add DSI bus infrastructure

and data type. Thierry -- next part ------ A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/4647e53c/attachment.pgp>

[PATCH v3 1/7] drm: Add DSI bus infrastructure

in-kernel API, therefore can change easily if needed. The less we require of it now the easier it will be to extend when the need arises. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/ccbecb2d/attachment-0001.pgp>

[Mesa-dev] rules for merging patches to libdrm

On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote: > > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding > > wrote: > > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > > >> On Mon, Nov 18, 2013 at 8:29 AM,

[Bug 71723] Sampler arrays indexed with non-constant expressions

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/d541f6a9/attachment.html>

[PATCH v3 1/7] drm: Add DSI bus infrastructure

ve no use-case where this is required, I think having a struct dsi_msg makes it easier to extend the featureset on an as-needed basis. Thierry ------ next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/94e107dd/attachment.pgp>

[PATCH 0/5] R-Car DU fixes and support for R8A7791

Hi Simon, On Monday 18 November 2013 17:23:11 Simon Horman wrote: > Hi Laurent, > > I am wondering if you have any patches to wire up this driver > for the Koelsch board so that I might test it. Here you go. git://linuxtv.org/pinchartl/fbdev.git drm/du/koelsch Only the LVDS output is

[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings

This patch adds dt support to hdmiphy config settings as it is board specific and depends on the signal pattern of board. Signed-off-by: Shirish S --- .../devicetree/bindings/video/exynos_hdmi.txt | 33 + drivers/gpu/drm/exynos/exynos_hdmi.c | 77

[PATCH 3/4] ARM: exynos: dts: cros5250: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/cros5250-common.dtsi | 75 1 file changed, 75 insertions(+)

[PATCH 2/4] ARM: dts: arndale: Add hdmi phy settings

This patch moves the hdmi phy setting to arndale dts, as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-arndale.dts | 75 ++ 1 file changed, 75 insertions(+)

[PATCH 1/4] ARM: dts: smdk5250: Add hdmi phy settings

This patch moves the hdmi phy setting to smdk5250 dts,as its more of a per board configuration and also shall be easier for supporting future chipsets. Signed-off-by: Shirish S --- arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 + 1 file changed, 75 insertions(+)

[PATCH 0/4] Add dt support for exynos hdmiphy settings

For various revisions of a chipset if the signal pattern is changed for every revision, then the phy setting need to be updated correspondingly by measuring the signal. For getting correct signals the clock level and data de-emphasis levels needs to be adjusted. Since only these 2 values

[PATCH v3 1/7] drm: Add DSI bus infrastructure

On 11/18/2013 11:22, Thierry Reding wrote: > On Thu, Nov 14, 2013 at 03:04:19PM +, Bert Kenward wrote: > > #define DSI_WINDOW_VFP (1 << 0) > > #define DSI_WINDOW_ACT (1 << 1) > > #define DSI_WINDOW_VBP (1 << 2) > > #define DSI_WINDOW_VSY (1 << 3) > > > > /** > > * struct dsi_msg - DSI

[PATCH] drm: Don't split up debug output

roperly verified for correctness. I guess we leave it up to the compiler to do that verification using the __printf() annotation, so I think it should be fine to use it here: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available T

[Bug 71488] RadeonSI :Regression: Massive Desktop corruption observed on starting the X server

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c643902b/attachment.html>

[PATCH 4/4] drm: exynos: hdmi: Add dt support for hdmiphy settings

Hi, On Fri, Nov 15, 2013 at 9:47 PM, Mark Rutland wrote: > On Tue, Oct 29, 2013 at 08:12:32AM +, Shirish S wrote: >> This patch adds dt support to hdmiphy config settings >> as it is board specific and depends on the signal pattern >> of board. >> >> Signed-off-by: Shirish S >> --- >>

[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

rates. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/510216fe/attachment.html>

[Mesa-dev] rules for merging patches to libdrm

On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding >> wrote: >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >>

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

On 15.11.2013 22:53, Stephen Warren wrote: > From: Stephen Warren > > This series implements a common reset framework driver for Tegra, and > updates all relevant Tegra drivers to use it. It also removes the custom > DMA bindings and replaced them with the standard DMA DT bindings. > >

[Mesa-dev] rules for merging patches to libdrm

On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding wrote: > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >>> How does this interact with the rule that kernel interfaces require an >> >>> open source userspace? Is "here are the

DRM_TEGRA not buildable as a module

lable URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/1ba23072/attachment.pgp>

[PATCH 2/2] drm/i915/dp: check eDP display control capability registers

On Mon, Nov 18, 2013 at 9:27 AM, Thierry Reding wrote: > On Fri, Nov 15, 2013 at 03:01:51PM +0200, Jani Nikula wrote: >> Debug print the capabilities, and flag an error if the panel does not >> support adjusting backlight through the BL_PWM_DIM pin, requiring >> backlight control through DPCD. >>

[Bug 65141] Blank screen after resume with radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=65141 Takashi Iwai changed: What|Removed |Added URL||https://bugzilla.novell.com

[Bug 65141] New: Blank screen after resume with radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=65141 Bug ID: 65141 Summary: Blank screen after resume with radeon driver Product: Drivers Version: 2.5 Kernel Version: 3.7,3.11,3.12 Hardware: All OS: Linux Tree:

[PATCH 1/2] drm/radeon/cik: Return backend map information to userspace

On Mon, Nov 18, 2013 at 4:25 AM, Michel D?nzer wrote: > From: Michel D?nzer > > Signed-off-by: Michel D?nzer Both patches applied to my tree. Thanks! Alex > --- > drivers/gpu/drm/radeon/radeon_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

DRM_TEGRA not buildable as a module

On Mon, Nov 18, 2013 at 4:10 AM, Thierry Reding wrote: > On Sat, Nov 16, 2013 at 03:25:09PM +0100, Josh Boyer wrote: >> Hi All, >> >> The commit below seems to have made the Tegra DRM driver a bool option >> instead of tristate: >> >> commit dee8268f8fb218c9e9b604a40f7dbdd395e910f9 >> Author:

[Bug 71723] New: [GLSL] Sampler arrays indexed with non-constant expressions

he assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/798dd658/attachment.html>

[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)

rder. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/b3ece3f5/attachment-0001.html>

[Bug 71239] Metro Last Light quits(?) on r600g

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c20ce164/attachment.html>

[Bug 71516] [SOLVED] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/af56e1c1/attachment.html>

[Bug 71285] Xonotic LLVM ERROR

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131118/c6077170/attachment.html>

[PATCH] drm/ttm: Don't move non-existing data

- Original Message - > If ttm_bo_move_memcpy was instructed to move a non-populated ttm to > io memory, it would first populate the ttm, then move the data and then > destroy the ttm. That's stupid. However, some drivers might have relied on > this to clear io memory from old stuff. So

[Mesa-dev] [PATCH] Don't use libudev for glx/dri3

On 18/11/13 01:08, Keith Packard wrote: > libudev doesn't have a stable API/ABI, and if the application wants to use one > version, we'd best not load another into libGL. > > Signed-off-by: Keith Packard > --- > Hi Keith, Firstly, I would like to apologise for the rather daft questions. With

[Bug 71697] [radeonsi] gtkperf hangs the system

ing this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/f0b7a8f7/attachment.html>

[Bug 71285] Xonotic LLVM ERROR

or the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131118/3b36a255/attachment.html>