On Sat, Jun 18, 2016 at 12:19 AM, Chris Wilson
wrote:
> On Sat, Jun 18, 2016 at 05:24:30AM +0800, kernel test robot wrote:
>>
>>
>> FYI, we noticed the following commit:
>>
>> git://anongit.freedesktop.org/drm-intel topic/drm-misc
>> commit e28cd4d0a223e1bcea616326e2281900e7e7e9a2 ("drm: Automati
Hi Daniel,
It doesn't look quite right I'm afraid. This causes a leak plus
there's a small style issue. See below for details.
On 17 June 2016 at 08:33, Daniel Vetter wrote:
> @@ -134,24 +152,21 @@ static int drm_new_set_master(struct drm_device *dev,
> struct drm_file *fpriv)
>
> /*
On 17 June 2016 at 08:33, Daniel Vetter wrote:
> @@ -315,10 +313,10 @@ struct drm_file {
> /* true if client understands atomic properties */
> unsigned atomic:1;
> /*
> -* This client is allowed to gain master privileges for @master.
> +* This client is th
On 17 June 2016 at 08:33, Daniel Vetter wrote:
> Also extract drm_auth.h for nicer grouping.
>
> v2: Nuke the other comments since they don't really explain a lot, and
> within the drm core we generally only document functions exported to
> drivers: The main audience for these docs are driver writ
On 18 June 2016 at 00:00, Emil Velikov wrote:
>> @@ -134,24 +152,21 @@ static int drm_new_set_master(struct drm_device *dev,
>> struct drm_file *fpriv)
>>
>> /* take another reference for the copy in the local file priv */
>> old_master = fpriv->master;
>> - fpriv->master =
Hi Vinay,
On 17 June 2016 at 19:23, Vinay Simha BN wrote:
> v6:
> * emil review comments incorporated
>PANEL_NUM_REGULATORS dropped, return ret added at necessary
>places, if checks dropped for backlight and gpios
Looks like some of my suggestions went below the radar. Did you miss
the
On 17 June 2016 at 09:25, Chris Wilson wrote:
> Up to now, the recommendation was for drivers to call drm_dev_register()
> followed by drm_connector_register_all(). Now that
> drm_connector_register() is safe against multiple invocations, we can
> move drm_connector_register_all() to drm_dev_regis
! has higher precedence than bitwise & so we need to add parenthesis
for this to work as intended.
Fixes: 048765ad5af7 ('amdgpu: fix asic initialization for virtualized
environments (v2)')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/am
On Fri, Jun 17, 2016 at 2:03 PM, Jon Hunter wrote:
> The pinconf-generic.h file exposes functions for creating generic mappings
> but it does not expose a function for freeing the mappings. Add a function
> for freeing generic mappings.
>
> Signed-off-by: Jon Hunter
Looks reasonable. Can I appl
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/a79b9ce0/attachment.html>
0-day kbuilder found
[1.360244] BUG: unable to handle kernel NULL pointer dereference at (null)
[1.360972] IP: [] mutex_lock_nested+0x11f/0x2c3
[1.361512] *pde =
[1.361827] Oops: 0002 [#1]
[1.362123] Modules linked in:
[1.362451] CPU: 0 PID: 1 Comm: swapper Not t
Hi Chris,
On 18 June 2016 at 13:13, Chris Wilson wrote:
>
> - drm_connector_register_all(dev);
> + if (drm_core_check_feature(dev, DRIVER_MODESET))
> + drm_connector_register_all(dev);
>
Shouldn't the drm_connector_unregister_all() call in
drm_dev_unregister() be guarde
On Sat, Jun 18, 2016 at 02:26:36PM +0100, Emil Velikov wrote:
> Hi Chris,
>
> On 18 June 2016 at 13:13, Chris Wilson wrote:
>
> >
> > - drm_connector_register_all(dev);
> > + if (drm_core_check_feature(dev, DRIVER_MODESET))
> > + drm_connector_register_all(dev);
> >
> S
0-day kbuilder found
[1.360244] BUG: unable to handle kernel NULL pointer dereference at (null)
[1.360972] IP: [] mutex_lock_nested+0x11f/0x2c3
[1.361512] *pde =
[1.361827] Oops: 0002 [#1]
[1.362123] Modules linked in:
[1.362451] CPU: 0 PID: 1 Comm: swapper Not t
Signed-off-by: Chris Wilson
---
lib/drmtest.c | 47 ---
lib/drmtest.h | 7 ---
2 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index c59cabe..30eae19 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -
Signed-off-by: Chris Wilson
---
lib/Makefile.sources| 2 +
lib/igt_vgem.c | 80 ++
lib/igt_vgem.h | 42 ++
tests/Makefile.sources | 2 +
tests/vgem_basic.c | 145
tests/vgem_relo
Rendering operations to the dma-buf are tracked implicitly via the
reservation_object (dmabuf->resv). The dmabuf sync ioctl allows
userspace to wait upon outstanding rendering and prepare the object for
CPU access (provided by the prime dma_buf_ops.begin_cpu_access). Fill
this out for the generic d
The vGEM mmap code has bitrotted slightly and now immediately BUGs.
Since vGEM was last updated, there are new core GEM facilities to
provide more common functions, so let's use those here.
Testcase: igt/vgem_basic/mmap
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/vgem/vgem_drv.c | 163 ++
Enable the standard GEM dma-buf interface provided by the DRM core, but
only for exporting the VGEM object. This allows passing around the VGEM
objects created from the dumb interface and using them as sources
elsewhere. Creating a VGEM object for a foriegn handle is not supported.
Testcase: igt/v
On 18 June 2016 at 14:46, Chris Wilson wrote:
> 0-day kbuilder found
>
> [1.360244] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [1.360972] IP: [] mutex_lock_nested+0x11f/0x2c3
> [1.361512] *pde =
> [1.361827] Oops: 0002 [#1]
> [1.362123] Modu
On Sat, Jun 18, 2016 at 04:25:46PM +0100, Emil Velikov wrote:
> On 18 June 2016 at 14:46, Chris Wilson wrote:
> > 0-day kbuilder found
> >
> > [1.360244] BUG: unable to handle kernel NULL pointer dereference at
> > (null)
> > [1.360972] IP: [] mutex_lock_nested+0x11f/0x2c3
> > [1.36
https://bugzilla.kernel.org/show_bug.cgi?id=120591
Bug ID: 120591
Summary: BUG() in dmesg after loading nouveau module
Product: Drivers
Version: 2.5
Kernel Version: 4.7-rc3
Hardware: x86-64
OS: Linux
Tree: Mai
https://bugzilla.kernel.org/show_bug.cgi?id=120591
--- Comment #1 from Dmitrii Tcvetkov ---
Created attachment 220571
--> https://bugzilla.kernel.org/attachment.cgi?id=220571&action=edit
kernel config
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=120591
Ilia Mirkin changed:
What|Removed |Added
CC||imirkin at alum.mit.edu
--- Comment #2 fro
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/a04d50b6/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/8c6c438c/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/fb1855cd/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/b1a796c3/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160618/430df65a/attachment-0001.html>
amdgpu_cgs_acpi_eval_object() returned the value of variable "result"
without initializing it first.
This bug has been found by compiling the kernel with clang. The
compiler complained:
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:972:14: error: variable
'result' is used uninitialized wheneve
On 2016-06-16 21:02, Meng Yi wrote:
> The lable fail_connector should placed before fail_encoder since encoder was
> initialized before connector. which should also be called after
> connector initialization failed.
>
> Hi Stefan,
>
> What do you think?
The current error handling is wrong, I agr
Commit 7566e247672d ("drm/fsl-dcu: handle initialization errors properly")
introduced error handling during initialization, but with a wrong cleanup
order.
Replace the error handling with the generic cleanup function
drm_mode_config_cleanup.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-d
On 2016-06-14 02:20, Meng Yi wrote:
> This patch creates another Encoder for HDMI port, and linking the Encoder
> to appropriate DRM bridge. And this Encoder using same CRTC with RGB-LCD.
> For RGB-LCD and HDMI using the same hardware connection to DCU, RGB-LCD
> panel should be unplugged when usin
On Fri, Jun 17, 2016 at 08:37:38AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Jun 2016 13:09:10 +0200
> Hans Verkuil escreveu:
>
> > On 06/17/2016 11:50 AM, Mauro Carvalho Chehab wrote:
> > One area where I am uncertain is when remote control messages are received
> > and
> > passed on by
alloc_workqueue replaces deprecated create_workqueue().
A dedicated workqueue has been used since the workqueue isr_workq is
involved in irq handling path of block driver and requires forward
progress under memory pressure. Hence, WQ_MEM_RECLAIM has been set.
Since there are only a fixed number of
From: Wei Yongjun
In case of error, the function drm_mode_duplicate() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value check
should be replaced with NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
1 file changed, 2 insertions(+),
0-06172203/gcc-6/e28cd4d0a223e1bcea616326e2281900e7e7e9a2/vmlinuz-4.7.0-rc2-00564-ge28cd4d
-append 'root=/dev/ram0 user=lkp
job=/lkp/scheduled/vm-lkp-wsx03-yocto-i386-2/bisect_boot-1-yocto-minimal-i386.cgz-i386-randconfig-b0-06172203-e28cd4d0a223e1bcea616326e2281900e7e7e9a2-20160618-131023-156vzgq-0.yaml~
A
On Sat, Jun 18, 2016 at 5:58 AM, Emil Velikov
wrote:
> Hi Vinay,
>
> On 17 June 2016 at 19:23, Vinay Simha BN wrote:
>
>> v6:
>> * emil review comments incorporated
>>PANEL_NUM_REGULATORS dropped, return ret added at necessary
>>places, if checks dropped for backlight and gpios
>
> Look
System workqueues have been able to handle high level of concurrency
for a long time now and there's no reason to use dedicated workqueues
just to gain concurrency. Since the workqueue host->intr_wq is involved
in sync point interrupts, and sync point wait and is not being used on
a memory reclaim
Thanks!
On 2016/6/18 2:29, weiyj_lk at 163.com wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_clk_get() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
Reviewed-by: Chen
40 matches
Mail list logo