Hi
On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
wrote:
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/1e295df7/attachment.html>
it was being used
before suspend)
--
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/20140410/cdcc65ea/attachment.html>
nts/20140410/a804cf38/attachment.html>
Setting higher mclks seems to cause stability issues
on some R7 260X boards. Disable it for now for stability
until we find a proper fix.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 4
As per internal recommendations.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index cad89a9..f92ac5e 100644
---
Don't try and runtime suspend the APU in PX systems. We
only want to power down the dGPU.
v2: fix harder
v3: fix stupid typo
v4: consolidate runpm enablement to a single flag
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=75127
https://bugzilla.kernel.org/show_bug.cgi?id=72701
own? E.g., change 157500
to:
15
10
8
5
3
etc.
--
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/20140
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b516a0c3/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2099034b/attachment.html>
On Thu, 10 Apr 2014 12:19:10 -0400
Ilia Mirkin wrote:
> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
> > reg,
> > + bool always_indirect)
> > +{
> > + if (reg < rdev->rmmio_size && !always_indirect)
> > +
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/20140410/5e37ae02/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/4e91cc30/attachment.html>
Am 10.04.2014 20:52, schrieb Ilia Mirkin:
> On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
>> On Thu, 10 Apr 2014 12:19:10 -0400
>> Ilia Mirkin wrote:
>>
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
reg,
+ bool
stable?
--
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/20140410/23121b65/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Libdrm 2.4.53 has been released.
Emil Velikov (1):
freedreno: do not leak drmVersion
Fran?ois Tigeot (1):
Enable libkms by default on DragonFly
Lucas Stach (1):
modeprint: pretty print connector names
Marek Ol??k (2):
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ba04cd3a/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/a33e09af/attachment.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3d170444/attachment.html>
ame play over time.
That symptom at least is still present.
--
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/20140410/2a
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/77837bf9/attachment.html>
t bug does it, you can mark this as a duplicate.
--
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/20140410/d409cff6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140410/133f3d50/attachment.html>
vel/attachments/20140410/0f83b096/attachment.html>
Recently, Exynos DP driver was moved from drivers/video/exynos/
directory to drivers/gpu/drm/exynos/ directory. So, I update
and add maintainer entry for Exynos DP driver.
Signed-off-by: Jingoo Han
---
MAINTAINERS |6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c52ec9b9/attachment-0001.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/813ab94c/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3528cc3c/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2e188999/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ce997ce6/attachment.html>
On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski
wrote:
>
>
> COW links can do this already, I think. Of course, you'll have to
> use a
> filesystem that supports them.
COW is nice if the filesystem supports them, but my userspace code
needs to be filesystem agnostic. Because of that, the
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/29e573e2/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/7df7cc73/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ff779190/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/d424c842/attachment-0001.html>
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This library provides helpers for common functionality needed by test
> programs.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - fix a couple of memory leaks and get rid of some unneeded code
>
>
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c
> new file mode 100644
> index ..b6ba35a9d668
> --- /dev/null
> +++ b/tests/tegra/gr2d-fill.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> +
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This test opens a device, dumps the version information and checks that
> a Tegra DRM context can be opened on it.
>
> Signed-off-by: Thierry Reding
Looks good!
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Add the libdrm_tegra helper library to encapsulate Tegra-specific
> interfaces to the DRM.
>
> Furthermore, Tegra is added to the list of supported chips in the
> modetest and vbltest programs.
>
> Signed-off-by:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/35a63a1a/attachment.html>
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Previous SoCs have hdmi phys which are accessible through
> dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
> Hdmi driver is modified to support apb mapped phys.
>
> Signed-off-by: Rahul Sharma
> ---
>
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/libdrm.h b/libdrm.h
> new file mode 100644
> index ..23926e6f6741
> --- /dev/null
> +++ b/libdrm.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> + *
> + * Permission is hereby granted, free of
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tegra/fence.c b/tegra/fence.c
> new file mode 100644
> index ..f58725ca8472
> --- /dev/null
> +++ b/tegra/fence.c
> +drm_public
> +int drm_tegra_fence_wait(struct drm_tegra_fence *fence)
> +{
> + return
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/959c434e/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b6be7ea7/attachment.html>
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Cleaning up unnecessary i2c read call after hdmiphy configuration.
> This check is redundant since check for hdmiphy pll lock status
> confirms the correct settings for phy.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Daniel
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Hdmiphy control bit needs to be set before setting the resolution
> to hdmi hardware. This was handled using dummy hdmiphy clock which
> is removed now.
>
> PMU is already defined as system controller for exynos SoC.
org/archives/dri-devel/attachments/20140410/46d5eeec/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/56e30573/attachment-0001.html>
On 04/10/2014 05:22 PM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:33 PM, Tony Battersby
> wrote:
>> For O_DIRECT the kernel pins the submitted pages in memory for DMA by
>> incrementing the page reference counts when the I/O is submitted,
>> allowing the pages to be modified by
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/48aa7175/attachment.html>
(reposted from my comments at http://lwn.net/Articles/593918/)
I may have thought of a way to subvert SEAL_WRITE using O_DIRECT and
asynchronous I/O. I am not sure if this is a real problem or not, but
better to ask, right?
The exploit would go like this:
1) mmap() the shared memory
2) open
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Exynos drm hdmi driver used to get dummy hdmiphy clock to
> control the PMU bit for hdmiphy. This clock is removed
> during CCF migration. This should also be cleaned from
> hdmi driver.
>
> Signed-off-by: Rahul Sharma
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/59ff658e/attachment.html>
op 10-04-14 13:08, Thomas Hellstrom schreef:
> On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 10-04-14 10:46, Thomas Hellstrom schreef:
>>> Hi!
>>>
>>> Ugh. This became more complicated than I thought, but I'm OK with moving
>>> TTM over to fence while we sort out
>>> how / if
On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>
> This is the second time in a week that someone has asked for a way to
> have a struct file (or struct inode or whatever) that can't be reopened
> through /proc/pid/fd. This should be quite easy to implement as a
> separate
On Thu, Apr 10, 2014 at 4:16 PM, David Herrmann
wrote:
> Hi
>
> On Fri, Apr 11, 2014 at 1:05 AM, Andy Lutomirski
> wrote:
>> /proc/pid/fd is a really weird corner case in which the mode of an
>> inode that doesn't have a name matters. I suspect that almost no one
>> will ever want to open one
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140410/bf8b06cd/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/568c44b0/attachment.html>
The list of machines in the "Use native backlight" table is getting longer
and longer, which is a solid indication that we're doing something wrong.
Disable the ACPI backlight interface if the system claims to be Windows 8
or later.
Signed-off-by: Matthew Garrett
---
Let's at least get this
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/5ebd0bb9/attachment.html>
Adding Rob and Rusty in the review thread.
Kindly review these patches for interface being proposed to set
color/alpha property of planes modeled after glBlendFunc.
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042350.html
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, inlining it grows radeon.ko by 7%.
However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
in Urban Terror.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 18
On Thu, Apr 10, 2014 at 3:57 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski
> wrote:
>> Would it make sense for the initial mode on a memfd inode to be 000?
>> Anyone who finds this to be problematic could use fchmod to fix it.
>
> memfd_create() should be
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/380dc5fc/attachment-0001.html>
On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
> On Thu, 10 Apr 2014 12:19:10 -0400
> Ilia Mirkin wrote:
>
>> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
>> > reg,
>> > + bool always_indirect)
>> > +{
>> > + if (reg
ttachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/dec5cde4/attachment.sig>
On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote:
>
> Looking at your patches, and what files you are modifying, you are
> enforcing this in the low-level file system.
I would love for this to be implemented in the filesystem level as
well. Something like the ext4 immutable bit, but
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/93a4e11e/attachment.html>
Signed-off-by: Matt Roper
---
include/drm/drm.h | 8
xf86drmMode.h | 4
2 files changed, 12 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0b4c16..229a29f 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -627,6 +627,14 @@ struct drm_get_cap {
rg/archives/dri-devel/attachments/20140410/c74601ff/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/cd9a06f3/attachment.html>
The src_w / src_h parameters to update_plane include a subpixel offset;
we need to shift off the subpixel bits before comparing to CRTC size
when checking for primary plane scaling.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff
On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
> wrote:
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could just make
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #10 from Christian K?nig ---
Created attachment 131871
--> https://bugzilla.kernel.org/attachment.cgi?id=131871=edit
Possible fix.
Please try the attached patch.
--
You are receiving this mail because:
You are watching the
d it looked great, too. 368 vs 100 on 24P made vary little difference too
me.
--
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/20140410/afa0392f/attachment.html>
On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>>
>> This is the second time in a week that someone has asked for a way to
>> have a struct file (or struct inode or whatever) that can't be reopened
>> through /proc/pid/fd.
On 04/10/2014 01:08 PM, Thomas Hellstrom wrote:
> On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 10-04-14 10:46, Thomas Hellstrom schreef:
>>> Hi!
>>>
>>> Ugh. This became more complicated than I thought, but I'm OK with moving
>>> TTM over to fence while we sort out
>>> how /
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/0b570f5d/attachment.html>
On 09.04.2014 15:39, Thierry Reding wrote:
> From: Thierry Reding
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field that was originally intended to
> properly pad the following __u64 field. Unfortunately it seems like a
> different
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 10-04-14 10:46, Thomas Hellstrom schreef:
>> Hi!
>>
>> Ugh. This became more complicated than I thought, but I'm OK with moving
>> TTM over to fence while we sort out
>> how / if we're going to use this.
>>
>> While reviewing, it
On Thu, Apr 10, 2014 at 9:08 AM, Lauri Kasanen wrote:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, inlining it grows radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
> in Urban Terror.
>
> Signed-off-by:
On 04/08/2014 06:00 AM, Florian Weimer wrote:
> On 03/19/2014 08:06 PM, David Herrmann wrote:
>
>> Unlike existing techniques that provide similar protection, sealing
>> allows
>> file-sharing without any trust-relationship. This is enforced by
>> rejecting seal
>> modifications if you don't own
On 04/10/2014 07:45 AM, Colin Walters wrote:
> On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote:
>>
>> Looking at your patches, and what files you are modifying, you are
>> enforcing this in the low-level file system.
>
> I would love for this to be implemented in the filesystem level as
On 03/20/2014 09:38 AM, tytso at mit.edu wrote:
> On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
>> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
>>> Why not make sealing an attribute of the "struct file", and enforce it
>>> at the VFS layer? That way all file system objects would
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
> Hi!
>
> Ugh. This became more complicated than I thought, but I'm OK with moving
> TTM over to fence while we sort out
> how / if we're going to use this.
>
> While reviewing, it struck me that this is kind of error-prone, and hard
> to follow
On 04/02/2014 06:38 AM, Konstantin Khlebnikov wrote:
> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
> wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to user-visible
Hello Andreas,
after pulling and rebooting my machine this morning, nouveau was no
longer working:
[6.455247] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
[6.455312] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC)
[6.455374] nouveau [ DEVICE][:02:00.0]
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a
inux/reservation.h | 40
> 4 files changed, 224 insertions(+), 31 deletions(-)
>
-- next part --
A non-text attachment was scrubbed...
Name: rcu_fence.diff
Type: text/x-patch
Size: 4139 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2d0922a9/attachment-0001.bin>
org/archives/dri-devel/attachments/20140410/7568c976/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #9 from sdh ---
Hi,
Any update on this? Is there any other information required to fix the bug?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote:
> commit c0b00a5 ("dma-buf: update debugfs output") modified the
> default exporter name to be the KBUILD_MODNAME pre-processor
> macro instead of __FILE__ but the documentation was not updated.
>
> Also the "Supporting
Hi Dave,
Could you pick up this patch?
It touches drm core and different drm drivers so I guess
your repo is the best place for it.
Regards
Andrzej
On 04/03/2014 11:21 PM, Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 12:29:46PM +0200, Andrzej Hajda wrote:
>> Many drm connectors do not need
Hi Dan,
Thanks for the patch.
On 04/09/2014 05:21 PM, Dan Carpenter wrote:
> Smatch complains that we are reading beyond the end of the array here:
>
> drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id()
> warn: buffer overflow 's6e8aa0_variants' 4 <= 4
>
> We set the
Please re-send this patch with a correct commit message (subject). Add
at least "drm: " prefix to it.
2014-04-09 23:11 GMT+02:00 Micah Richert :
> Signed-off-by: Micah Richert
You have some weird indent before "Signed-off-by".
+0900
r600g: Don't leak bytecode on shader compile failure
--
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/20140410/1e97d
commit c0b00a5 ("dma-buf: update debugfs output") modified the
default exporter name to be the KBUILD_MODNAME pre-processor
macro instead of __FILE__ but the documentation was not updated.
Also the "Supporting existing mmap interfaces in exporters" section
title seems wrong since talks about the
Signed-off-by: Javier Martinez Canillas
---
drivers/base/dma-buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index ea77701..840c7fa 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -491,7 +491,7 @@
https://bugs.freedesktop.org/show_bug.cgi?id=75127
--- Comment #30 from kh3095 at yandex.ru ---
Patch v3 (applied to 3.13.7) doesn't work for me. Again the same messages:
20.528628] pciehp :00:03.0:pcie04: Device :02:00.0 already exists at
:02:00, cannot hot-add
[ 20.528807]
1 - 100 of 102 matches
Mail list logo
