-generator/20161217-013805
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address':
unknown
HI,
Thanks for patch. Reasonable to me and go to misc excepting below one thing.
Please check my comment.
2016-12-14 4:34 GMT+09:00 Laurent Pinchart
:
> From: Laurent Pinchart
>
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the de
When constructing a path to a device node the minor number retrieved
from fstat needs to have the offset of the node type subtracted from it.
Control and render node types have the same major as the primary node
but each has their own block of minor types at fixed offsets.
v2: remove min < base te
Implement a generic drmGetDeviceNameFromFd2() to use on non-linux
systems without sysfs.
v2: remove min < base test as requested by Emil
Signed-off-by: Jonathan Gray
---
xf86drm.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/x
When iterating over all the device nodes if drmProcessPciDevice()
returned an error for any node the function would return an error,
ignoring any valid nodes.
The result of this on OpenBSD where drmProcessPciDevice() results in
device nodes being opened to issue ioctls to get pci data
was that dat
On 12/17/2016 01:16 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
>> Forgot to add the most relevant list for this issue (linux-next).
>>
>> Stephen, maybe you will want to temporarily revert this patch until this
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/1f34ebfd/attachment.html>
Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>>
>>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
>>> unsigned int subclass,
>>> struct mutex_waiter wa
ing everything I can think of, and glad to provide additional info as
needed.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/ba2ff03a/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/20161217/314e2740/attachment.html>
ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/cc359cc0/attachment-0001.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/27801a15/attachment.html>
eceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/664dbbc3/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/20161217/d3d8163c/attachment.html>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/e37901f0/attachment.html>
eceiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/0116ddb3/attachment.html>
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/a418ce69/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/ef4f0277/attachment-0001.html>
Exercise drm_mm_insert_node_in_range(), check that we only allocate from
the specified range.
v2: Use all allocation flags
v3: Don't pass in invalid ranges - these will be asserted later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h
Check that if we request top-down allocation from drm_mm_insert_node()
we receive the next available hole from the top.
v2: Flip sign on conditional assert.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selfte
ent was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/46fa9b2f/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/920979f7/attachment.html>
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwin
On Fri, Dec 16, 2016 at 02:17:25PM +0100, Nicolai Hähnle wrote:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
> >On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
> >
> >>@@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
> >>unsigned int subclass,
> >>str
On Fri, Dec 16, 2016 at 07:16:25PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Liviu Dudau [mailto:liviu at dudau.co.uk]
> > Sent: Friday, December 16, 2016 2:11 PM
> > To: Daenzer, Michel; Deucher, Alexander
> > Cc: Koenig, Christian; David Airlie; dri-devel at lists.
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/f268308b/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/d938ab3d/attachment.html>
i7-3770
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/8edb4eac/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/1bf1392d/attachment.html>
On 12/16/2016 04:01 PM, Michel Dänzer wrote:
> On 16/12/16 01:29 AM, Dmitriy Kryuk wrote:
>> I have a laptop with a Radeon X200M card in it. I use Radeon DRM driver
>> for graphics, and it makes the system hang with display off when trying
>> to suspend (either to disk or to RAM). Using /sys/power
From: Matthew Wilcox
> From: Rasmus Villemoes [mailto:linux at rasmusvillemoes.dk]
> > This sounds good. I think there may still be a lot of users that never
> > allocate more than a handful of IDAs, making a 128 byte allocation still
> > somewhat excessive. One thing I considered was (exactly as i
On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> On Fri, 16 Dec 2016, Daniel Vetter wrote:
> > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> >> The two remaining patches from [1], rebased.
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> [1]
> >> http://mid.mail-archive.com/1480
r a couple of hours now
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161217/8b7c76e2/attachment.html>
Hi Daniel,
On Friday 16 Dec 2016 18:02:20 Daniel Stone wrote:
> On 13 December 2016 at 19:34, Laurent Pinchart wrote:
> > From: Laurent Pinchart
> >
> > The drm driver .load() operation is prone to race conditions as it
> > initializes the driver after registering the device nodes. Its usage is
34 matches
Mail list logo
