2014-11-21 8:54 GMT+09:00 Gustavo Padovan :
> From: Gustavo Padovan
>
> DP was leaked everytime function returns EPROBE_DEFER, free it before
> returning.
It seems that you misunderstood devm_* api.
Thanks,
Inki Dae
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos_dp_c
Hello Vivek
On Wed, Nov 19, 2014 at 1:03 PM, Vivek Gautam
wrote:
>>
>> Tested-by: Javier Martinez Canillas
>
> Thanks for testing.
>
You are welcome
>>
>> Kukjin,
>
> Sorry for not adding Kukjin to the list and thereby for the delay
> about this patch.
>
No worries but I'm not sure if Kukjin
At least Apple's MacBook Pro 8,2 booting EFI -> GRUB2 -> Linux (without
BIOS emulation) seems to have no Radeon BIOS accessible via conventional
means. Loading one via firmware system previously dumped (with
"dd if=/dev/mem of=/lib/firmware/radeon/vbios.bin bs=65536 skip=12 count=1")
when booted wi
Hey,
Op 22-11-14 om 01:19 schreef Michael Marineau:
> On Thu, Nov 20, 2014 at 12:53 AM, Maarten Lankhorst
> wrote:
>> Op 20-11-14 om 05:06 schreef Michael Marineau:
>>> On Wed, Nov 19, 2014 at 12:10 AM, Maarten Lankhorst
>>> wrote:
Hey,
On 19-11-14 07:43, Michael Marineau wrote:
>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/7336ea38/attachment.html>
On Sat, Nov 22, 2014 at 2:45 PM, nick wrote:
> Greetings again David and other maintainers,
> I am wondering if I can remove the following code below my message in
> psb_drv.h as you state it's unneeded in a TODO.
> Cheers Nick
> /* TODO: To get rid of */
> #define PSB_TT_PRIV0_LIMIT (256*1
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/01980069/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/d2423c16/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Daniel Otero changed:
What|Removed |Added
Regression|No |Yes
Severity|normal
07] 1173.668511: fence:fence_signaled:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56908
> > > swapper 0 [007] 1173.668513: fence:fence_destroy:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56908
> > > kworker/4:180 [004] 1173.676265: fence:fence_destroy:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56896
> > > kworker/4:180 [004] 1173.676273: fence:fence_destroy:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56898
> > > kworker/4:180 [004] 1173.676277: fence:fence_destroy:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56902
> > > kworker/4:180 [004] 1173.676280: fence:fence_destroy:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56904
> > > Xorg 474 [001] 1188.676067: fence:fence_wait_end:
> > > driver=nouveau timeline=Xorg[474] context=2 seqno=56910
> > >
> > > I assume that excludes the context you really want so the full fence
> > > event log and corresponding dmesg output are attached.
> >
> > Yep, the trace events are useful. The fence is emitted and presumably
no event is fired after emission.
> >
> > Lets find out if the nvif crap is buggy or it's a result of some other
issue, what happens when you change:
> > .wait = fence_default_wait,
> > to
> > .wait = nouveau_fence_wait_legacy,
> > in nouveau_fence.c?
>
> That change works just fine.
The xorg hangs also appear to be resolved by db1cf46 "drm/nouveau: use rcu
in nouveau_gem_ioctl_cpu_prep"
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/01a203ae/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/d50723f7/attachment.html>
On Sat, Nov 22, 2014 at 12:37 AM, Jasper St. Pierre
wrote:
> This fixes an issue when trying to use -v and -C together. When trying
> to read the page flip event, we are interrupted by the SIGALRM that
> comes in, and so we think we timed out when we simply got EINTR. While
> we could just loop ch
swapper 0 [007] 1173.668513: fence:fence_destroy:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56908
> > kworker/4:180 [004] 1173.676265: fence:fence_destroy:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56896
> > kworker/4:180 [004] 1173.676273: fence:fence_destroy:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56898
> > kworker/4:180 [004] 1173.676277: fence:fence_destroy:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56902
> > kworker/4:180 [004] 1173.676280: fence:fence_destroy:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56904
> > Xorg 474 [001] 1188.676067: fence:fence_wait_end:
> > driver=nouveau timeline=Xorg[474] context=2 seqno=56910
> >
> > I assume that excludes the context you really want so the full fence
> > event log and corresponding dmesg output are attached.
>
> Yep, the trace events are useful. The fence is emitted and presumably no
event is fired after emission.
>
> Lets find out if the nvif crap is buggy or it's a result of some other
issue, what happens when you change:
> .wait = fence_default_wait,
> to
> .wait = nouveau_fence_wait_legacy,
> in nouveau_fence.c?
That change works just fine.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/11292c2c/attachment-0001.html>
Removes unnessary define statements not needing for this hardware
driver to function correctly.
Signed-off-by: Nicholas Krause
---
drivers/gpu/drm/gma500/psb_drv.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 55e
Greetings again David and other maintainers,
I am wondering if I can remove the following code below my message in psb_drv.h
as you state it's unneeded in a TODO.
Cheers Nick
/* TODO: To get rid of */
#define PSB_TT_PRIV0_LIMIT (256*1024*1024)
#define PSB_TT_PRIV0_PLIMIT (PSB_TT_PRIV0_
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/b69f2dc2/attachment.html>
ceiving 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/20141122/2aa5acc9/attachment.html>
e for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/1e412a2a/attachment.html>
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141122/366552d7/attachment-0001.html>
on vlv, if ipvr is installed, it need be manually unloaded before
i915, otherwise user might run into use-after-free issue.
v2:
added this patch per Daniel's comment
v3:
no change
Signed-off-by: Yao Cheng
---
tests/drv_module_reload | 16
1 file changed, 16 insertions(+)
diff
add usermode helper for the ipvr kernel driver.
test_ioctl: test kernel driver by directly ioctl
v2:
take Emil's comments
- correctly align ipvr_drm.h
v3:
take Daniel Vetter and Daniel Stone's comments, and implement PRIME
- correctly align ipvr_drm.h
- use __u32 family in
Probes VED and creates a new drm device for hardware accelerated
video decoding.
Currently support VP8 decoding on valleyview.
v2:
take David's comments
- add mmap support and remove mmap_ioctl
- remove postclose since it's deprecated
- NULL set_busid
v3:
take David, Danie
Setup minimum required resources during i915_driver_load:
1. Create a platform device to share MMIO/IRQ resources
2. Make the platform device child of i915 device for runtime PM.
3. Create IRQ chip to forward the VED irqs.
VED driver (a standalone drm driver) probes the VED device and
creates a new
drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel GPU),
which extends video capability.
A new Kconfig added for building ipvr driver:
CONFIG_DRM_IPVR: Build option for ipvr module
The driver name "ipvr" means the PowerVR's core wrapped by Intel. The PowerVR
VPUs are also
nts/20141122/2eb16f1a/attachment.html>
?
https://github.com/jumoog/GFX_Linux_DDK
--
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/20141122/eb66a1d3/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/20141122/7882724a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Adam Williamson changed:
What|Removed |Added
CC||adamw at happyassassin.net
--- Comment
||
--
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/20141122/0d0eed8d/attachment.html>
DX: 1:7.5.0-1
--
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/20141122/61f1b451/attachment.html>
30 matches
Mail list logo
