-failed-allocation/20151230-030043
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x008-12291635 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by
-allocation/20151230-031647
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x008-12291635 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/g
-allocation/20151230-031647
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x017-12300038 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
I
>
> 1. As UP replies also got to slots (even as mentioned in code it
> should not happen), we should clean them somewhere. For DOWN requests they
> are cleaned on DOWN reply when full reply received. However we will not
> receive interrupt when UP reply sent;
>
> 2. I am not sure if DRM
https://bugzilla.kernel.org/show_bug.cgi?id=64661
--- Comment #10 from Austin Robertson ---
For now, I've been using the nouveau drivers. udl does not have this problem
when using nouveau.
--
You are receiving this mail because:
You are watching the assignee of the bug.
here:
https://bbs.archlinux.org/viewtopic.php?id=79509&p=115
--
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/20151230/c666ce05/attachment.html>
w the start value (apitrace surely couldn't handle that)...
--
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/20151230/50b248e7/attachment-0001.html>
Fixes errors e.g.
error: implicit declaration of function 'select'
and missing definitions of FD_* defines
Signed-off-by: Khem Raj
---
tests/kms/kms-steal-crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms/kms-steal-crtc.c b/tests/kms/kms-steal-crtc.c
index 2f7f327..24d70ab 1
On Tue, 29 Dec 2015, Insu Yun wrote:
> Signed-off-by: Insu Yun
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index a5e99ac..4e279dd 100644
On 30/12/15 11:31, Sebastian Frias wrote:
> Hi,
>
> On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
>>
>> Also note that I don't want new fbdev drivers into the mainline kernel.
>> You should implement a DRM based driver instead.
>>
>
> Thanks, is there a porting guide to go from fbdev to DRM?
I
The drm_dp_mst_topology_cbs structures are never modified, so declare them
as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/i915/intel_dp_mst.c|2 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c |2 +-
include/drm/drm_dp_mst_helper.h|
bbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151230/d3df8920/attachment.html>
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that uses
an i2c encoder (adv7511), following the basic steps suggested by Laurent
in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4
After initiliazing all kms, crtc, encoder, i2c, connector
Since devm_kzalloc can be failed, it needs to be checked
if not, NULL dereference could be happened.
Signed-off-by: Insu Yun
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/int
Hi, Stefan
I have tested your patch, It seems good to me.
But I think state->fb check is still necessary, because fb is related to crtc ,
and panel is related to connector,. When fsl,panel is not valid, it indicate
that connector is not available, but fb check is still needed. But I am not so
s
Hi,
On 12/30/2015 09:06 AM, Tomi Valkeinen wrote:
>
> Also note that I don't want new fbdev drivers into the mainline kernel.
> You should implement a DRM based driver instead.
>
Thanks, is there a porting guide to go from fbdev to DRM?
Does DRM provides a "fbdev" backward compatible API? Would t
l->panel);
>
> --
> Jani Nikula, Intel Open Source Technology Center
>
--
Regards
Insu Yun
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151230/20e02d7e/attachment.html>
17 matches
Mail list logo
