https://bugs.freedesktop.org/show_bug.cgi?id=68451
Andreas Boll changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #3 from Peter Kraus ---
RE: Emil:
Possibly. I couldn't get a screenshot of the corruption, mine looked a lot
different, but it's definitely possible.
RE: Alex:
I'll try when I get back home and have some time (ie tomorrow). I might t
https://bugs.freedesktop.org/show_bug.cgi?id=68468
Priority: medium
Bug ID: 68468
Assignee: dri-devel@lists.freedesktop.org
Summary: 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)
Severity: major
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=68468
adam...@gmail.com changed:
What|Removed |Added
Version|unspecified |9.2
--
You are receiving this mail b
Argh, forgotten to cc lists!
On Fri, Aug 23, 2013 at 10:42:37AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Just one patch that soaked for quite a bit to fix a resume issue,
> resulting in gpu hangs (or worse) due to tlb containing garbage.
>
> Cheers, Daniel
>
>
> The following changes since c
To address the case where physically contiguous memory MAY NOT be a mandatory
requirement for framebuffer for the application calling
exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for
framebuffer,
if physically contiguous memory allocation fails and
https://bugs.freedesktop.org/show_bug.cgi?id=68468
--- Comment #1 from Michel Dänzer ---
> All of the above (except UVD, of course) work fine under 9.1.6
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dr
Tegra is a 32 bit arch. On 32 bit systems then size_t is 32 bits so
"total" will never be higher than UINT_MAX because of integer overflows.
We need cast to u64 first before doing the math.
Also the addition earlier:
unsigned int num_unpins = num_cmdbufs + num_relocs;
That can overflow
There is a mistake here so it returns PTR_ERR(NULL) which is success
instead of -ENOMEM.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..6cf41da 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/j
Hi Linus,
Ben was on holidays for a week so a few nouveau regression fixes backed
up, but they all seem necessary, otherwise one i915 and one gma500 fix.
Dave.
The following changes since commit 3387ed83943daf6cb1bb4195ae369067b9cd80ce:
Merge tag 'drm-intel-fixes-2013-08-15' of
git://peopl
Hello,
On Friday 23 August 2013 10:21:21 Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid
Hi
I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-obj
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn'
We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.
This allows us to use drm_vma_node_is_
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().
TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instea
Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.
Compared to legacy clients, render clients no longer need any
authentication
From: Kristian Høgsberg
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Cc: Daniel Vetter
Signed-off-by: Kristian Høgsberg
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++---
From: Martin Peres
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Cc: Ben Skeggs
Cc: Maarten Lankhorst
Signed-off-by: Martin Peres
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 24 --
Hi
On Tue, Aug 13, 2013 at 11:05 PM, Daniel Vetter wrote:
> On Tue, Aug 13, 2013 at 09:38:31PM +0200, David Herrmann wrote:
>> Implement automatic access management for mmap offsets for all GEM
>> drivers. This prevents user-space applications from "guessing" GEM BO
>> offsets and accessing buffe
On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian Høgsberg
>
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
>
> Cc: Daniel Vetter
> Signed-off-by: Kristian Høgsberg
> Signed-off-by: David Herrm
Le 23/08/2013 13:13, David Herrmann a écrit :
Hi
I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access()
Hi
On Fri, Aug 23, 2013 at 1:28 PM, Christian König
wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> al
Hi
On Fri, Aug 23, 2013 at 2:34 PM, Christian König
wrote:
>> Feel free to send a patch to dri-devel or just let me know the ioctls
>> and I will include it in this series.
>
>
> Do you have a branch somewhere I can grab?
>
> That's a bit easier than applying the patchset from the list.
https://
On Thu, Aug 22, 2013 at 06:00:14PM +0200, Wolfram Sang wrote:
> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register ch
Hi David,
Am 23.08.2013 13:13, schrieb David Herrmann:
Hi
I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify
Feel free to send a patch to dri-devel or just let me know the ioctls
and I will include it in this series.
Do you have a branch somewhere I can grab?
That's a bit easier than applying the patchset from the list.
Thanks,
Christian.
Am 23.08.2013 14:31, schrieb David Herrmann:
Hi
On Fri, Aug
On Friday 23 August 2013 21:15:16 Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redunda
On Fri, Aug 23, 2013 at 7:28 AM, Christian König
wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all ge
From: Christian König
Enable support for drm render nodes for radeon by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 22 +++---
2 files
Hi
On Fri, Aug 23, 2013 at 3:45 PM, Christian König
wrote:
> From: Christian König
>
> Enable support for drm render nodes for radeon by flagging the ioctls that
> are safe and just needed for rendering.
>
> Signed-off-by: Christian König
Looks good to me. I queued it locally. v3 will include
Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm
Changes in v3:
- rebase to 3.11-rc6
Changes in v2:
- remove redundant/unnecessary SoC specific setting in the board dts
Signed-off-by: Benoit Parrot
---
arch/arm/boot/dts/am335x-evm.dts | 72 ++
i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.
See https://bugs.freedesktop.org/show_bug.cgi?id=68456
Reported-by: Hans-Peter Deifel
Tested-by: Hans-Peter Deifel
Signed-o
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #35 from Neil Connolly ---
I have the same overheating problem with a Sony Vaio i5 with ATI Redeon 5400
graphics.
Idle temperature quickly rises to 70oC and then any desktop activity takes the
temperature into the 80's. Running a vide
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #36 from Alex Deucher ---
Starting with kernel 3.11 you can enable the dynamic power management hardware
on the gpu by booting with radeon.dpm=1 on the kernel command line in grub.
You will also need the latest smc firmware for your
On 08/23/2013 04:19 AM, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
>
> Signed-off-by: Dan Carpenter
> ---
> I can't compile this.
For the record, just do:
export CROSS_COMPILE=xxx
make ARCH=arm tegra_defconfig
make ARCH=arm
On Thu, Aug 22, 2013 at 09:12:40AM +0200, Maarten Lankhorst wrote:
> Op 22-08-13 02:10, Ilia Mirkin schreef:
> > The code expects non-VRAM mem nodes to have a pages list. If that's not
> > set, it will do a null deref down the line. Warn on that condition and
> > return an error.
> >
> > See https:
There is a typo so deadlocks on error instead of unlocking.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7ae2bfc..276d470 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -552,7 +552,7 @@ fail:
*/
https://bugs.freedesktop.org/show_bug.cgi?id=68468
--- Comment #2 from adam...@gmail.com ---
Well, I've learned of bisect right about now, so not efficiently, I suppose.
That being said, with a few pointers, I'm willing to try.
--
You are receiving this mail because:
You are the assignee for the
On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian Høgsberg
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter
>> S
https://bugs.freedesktop.org/show_bug.cgi?id=68391
--- Comment #4 from Rafael Castillo ---
i can confirm my hd7770 give the same error in xonotic 7.0 in some worlds too
LLVM ERROR: ran out of registers during register allocation
and gdb can't backtrace either
--
You are receiving this mail be
On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian Høgsberg
>
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
>
> Cc: Daniel Vetter
> Signed-off-by: Kristian Høgsberg
> Signed-off-by: David Herrm
On Fri, Aug 23, 2013 at 11:46:02PM +0300, Dan Carpenter wrote:
> There is a typo so deadlocks on error instead of unlocking.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7ae2bfc..276d470 100644
> --- a/drivers/gpu/drm/drm_pri
https://bugs.freedesktop.org/show_bug.cgi?id=68224
--- Comment #4 from Tom Stellard ---
Created attachment 84543
--> https://bugs.freedesktop.org/attachment.cgi?id=84543&action=edit
Patch #2
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=68224
--- Comment #5 from Tom Stellard ---
Created attachment 84544
--> https://bugs.freedesktop.org/attachment.cgi?id=84544&action=edit
LLVM Patch #3
If you apply all three of these patches, does it fix the crash?
--
You are receiving this mail b
On 15/07/2013 10:39, Maarten Lankhorst wrote:
Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
wrote:
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to
Hi Alex,
FYI, there are new warnings show up in
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-3.12-wip
head: 21419df38d4ba010b1ea80e2f91b853c8c3de7e5
commit: 38306848032ac045ac5a5f3145271bc01176883e [31/90] drm/radeon/dpm: add
support for parsing the atom powertune table
scr
https://bugzilla.kernel.org/show_bug.cgi?id=60741
Eastern Heart changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=60674
Eastern Heart changed:
What|Removed |Added
CC||zxd123314 at hotmail.com
--- Comment #16
the drm-next branch that was included in rc1.
--
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/20130823/bd717ebd/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/e7d0254d/attachment.html>
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/20130823/9d3772af/attachment.html>
From: Wei Yongjun
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/gpu
works. I
now have 1 day uptime.
--
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/20130823/d65b5a2e/attachment.html>
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/20130823/019d76f7/attachment-0001.html>
s/dri-devel/attachments/20130823/90977b32/attachment.html>
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/20130823/790953eb/attachment.html>
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/20130823/6bffa659/attachment.html>
Argh, forgotten to cc lists!
On Fri, Aug 23, 2013 at 10:42:37AM +0200, Daniel Vetter wrote:
> Hi Dave,
>
> Just one patch that soaked for quite a bit to fix a resume issue,
> resulting in gpu hangs (or worse) due to tlb containing garbage.
>
> Cheers, Daniel
>
>
> The following changes since c
To address the case where physically contiguous memory MAY NOT be a mandatory
requirement for framebuffer for the application calling
exynos_drm_gem_dumb_create,
the patch adds a feature to get non physically contiguous memory for
framebuffer,
if physically contiguous memory allocation fails and
TML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/aef75d0e/attachment.html>
Tegra is a 32 bit arch. On 32 bit systems then size_t is 32 bits so
"total" will never be higher than UINT_MAX because of integer overflows.
We need cast to u64 first before doing the math.
Also the addition earlier:
unsigned int num_unpins = num_cmdbufs + num_relocs;
That can overflow
There is a mistake here so it returns PTR_ERR(NULL) which is success
instead of -ENOMEM.
Signed-off-by: Dan Carpenter
---
I can't compile this.
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc80766..6cf41da 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/j
Hi Linus,
Ben was on holidays for a week so a few nouveau regression fixes backed
up, but they all seem necessary, otherwise one i915 and one gma500 fix.
Dave.
The following changes since commit 3387ed83943daf6cb1bb4195ae369067b9cd80ce:
Merge tag 'drm-intel-fixes-2013-08-15' of
git://peopl
Hello,
On Friday 23 August 2013 10:21:21 Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid
Hi
I reduced the vma access-management patches to a minimum. I now do filp*
tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
all gem drivers are safe now. For TTM drivers, I now use the already available
verify_access() callback to get access to the underlying gem-obj
The VMA offset manager uses a device-global address-space. Hence, any
user can currently map any offset-node they want. They only need to guess
the right offset. If we wanted per open-file offset spaces, we'd either
need VM_NONLINEAR mappings or multiple "struct address_space" trees. As
both doesn'
We implement automatic vma mmap() access management for all drivers using
gem_mmap. We use the vma manager to add each open-file that creates a
gem-handle to the vma-node of the underlying gem object. Once the handle
is destroyed, we drop the open-file again.
This allows us to use drm_vma_node_is_
GEM does already a good job in tracking access to gem buffers via handles
and drm_vma access management. However, TTM drivers currently do not
verify this during mmap().
TTM provides the verify_access() callback to test this. So fix all drivers
to actually call into gem+vma to verify access instea
Render nodes provide an API for userspace to use non-privileged GPU
commands without any running DRM-Master. It is useful for offscreen
rendering, GPGPU clients, and normal render clients which do not perform
modesetting.
Compared to legacy clients, render clients no longer need any
authentication
From: Kristian H?gsberg
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Cc: Daniel Vetter
Signed-off-by: Kristian H?gsberg
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++---
From: Martin Peres
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Cc: Ben Skeggs
Cc: Maarten Lankhorst
Signed-off-by: Martin Peres
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 24 --
Hi
On Tue, Aug 13, 2013 at 11:05 PM, Daniel Vetter wrote:
> On Tue, Aug 13, 2013 at 09:38:31PM +0200, David Herrmann wrote:
>> Implement automatic access management for mmap offsets for all GEM
>> drivers. This prevents user-space applications from "guessing" GEM BO
>> offsets and accessing buffe
On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian H?gsberg
>
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
>
> Cc: Daniel Vetter
> Signed-off-by: Kristian H?gsberg
> Signed-off-by: David Herrm
Le 23/08/2013 13:13, David Herrmann a ?crit :
> Hi
>
> I reduced the vma access-management patches to a minimum. I now do filp*
> tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
> all gem drivers are safe now. For TTM drivers, I now use the already available
> verify_
Hi
On Fri, Aug 23, 2013 at 1:28 PM, Christian K?nig
wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> al
Hi
On Fri, Aug 23, 2013 at 2:34 PM, Christian K?nig
wrote:
>> Feel free to send a patch to dri-devel or just let me know the ioctls
>> and I will include it in this series.
>
>
> Do you have a branch somewhere I can grab?
>
> That's a bit easier than applying the patchset from the list.
https://
olfram Sang
Applied to for-next!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/a3c35475/attachment-0001.pgp>
Hi David,
Am 23.08.2013 13:13, schrieb David Herrmann:
> Hi
>
> I reduced the vma access-management patches to a minimum. I now do filp*
> tracking in gem unconditionally and force drm_gem_mmap() to check this. Hence,
> all gem drivers are safe now. For TTM drivers, I now use the already available
> Feel free to send a patch to dri-devel or just let me know the ioctls
> and I will include it in this series.
Do you have a branch somewhere I can grab?
That's a bit easier than applying the patchset from the list.
Thanks,
Christian.
Am 23.08.2013 14:31, schrieb David Herrmann:
> Hi
>
> On Fr
On Friday 23 August 2013 21:15:16 Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR(). Also remove the dev_err call to avoid redunda
On Fri, Aug 23, 2013 at 7:28 AM, Christian K?nig
wrote:
> Hi David,
>
> Am 23.08.2013 13:13, schrieb David Herrmann:
>
>> Hi
>>
>> I reduced the vma access-management patches to a minimum. I now do filp*
>> tracking in gem unconditionally and force drm_gem_mmap() to check this.
>> Hence,
>> all ge
From: Christian K?nig
Enable support for drm render nodes for radeon by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
drivers/gpu/drm/radeon/radeon_kms.c | 22 +++---
2 files
Hi
On Fri, Aug 23, 2013 at 3:45 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Enable support for drm render nodes for radeon by flagging the ioctls that
> are safe and just needed for rendering.
>
> Signed-off-by: Christian K?nig
Looks good to me. I queued it locally. v3 will include
Add LCDC device node in DT for am33xx
Add LCDC and Panel info in DT for am335x-evm
Changes in v3:
- rebase to 3.11-rc6
Changes in v2:
- remove redundant/unnecessary SoC specific setting in the board dts
Signed-off-by: Benoit Parrot
---
arch/arm/boot/dts/am335x-evm.dts | 72 ++
i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.
See https://bugs.freedesktop.org/show_bug.cgi?id=68456
Reported-by: Hans-Peter Deifel
Tested-by: Hans-Peter Deifel
Signed-o
ing a video fullscreen causes the machine to
shutdown.
--
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/20130823/2595cecf/attachment.html>
card.
--
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/20130823/4240de21/attachment.html>
On 08/23/2013 04:19 AM, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
>
> Signed-off-by: Dan Carpenter
> ---
> I can't compile this.
For the record, just do:
export CROSS_COMPILE=xxx
make ARCH=arm tegra_defconfig
make ARCH=arm
eate a fb in vram with
valid_domains=0004
Does that help?
-- Pasi
-- next part --
A non-text attachment was scrubbed...
Name: nouveau_test_fix_null_deref_v3.10.patch
Type: text/x-diff
Size: 1202 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/b13e064d/attachment.patch>
There is a typo so deadlocks on error instead of unlocking.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7ae2bfc..276d470 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -552,7 +552,7 @@ fail:
*/
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130823/723e41d9/attachment.html>
On Fri, Aug 23, 2013 at 4:29 AM, Chris Wilson
wrote:
> On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
>> From: Kristian H?gsberg
>>
>> Enable support for drm render nodes for i915 by flagging the ioctls that
>> are safe and just needed for rendering.
>>
>> Cc: Daniel Vetter
>>
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/20130823/94e80dd9/attachment.html>
From: Wei Yongjun
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR(). Also remove the dev_err call to avoid redundant
error message and check for return value of platform_get_res
94 matches
Mail list logo
