On Sat, Dec 10, 2016 at 10:36 PM, Chris Wilson
wrote:
> On Sat, Dec 10, 2016 at 09:28:02PM +, Chris Wilson wrote:
>> On Sat, Dec 10, 2016 at 09:23:35PM +, Chris Wilson wrote:
>> > On Sat, Dec 10, 2016 at 10:19:30PM +0100, Daniel Vetter wrote:
>> > > On Fri, Dec 09, 2016 at 04:52:32PM +000
Looping twice when we can do it once is silly. Also use a consistent
style. Note that there's a good race with the connector list walking,
since that is no longer protected by mode_config.mutex. But that's for
a later patch to fix.
v2: Actually try to not blow up, somehow I lost the hunk that chec
With the last round of changes all ioctls called by modern drivers now
have their own locking. Everything else is only allowed for legacy
drivers and hence the lack of locking doesn't matter.
One exception is nouveau, due to the DRIVER_KMS_LEGACY_CONTEXT flag.
But that only works its magic on the
It only updates per-file feature flags. And all the ioctl which change
behaviour depending upon these flags (they're all kms features) do
_not_ hold the BKL. Therefor this is pure cargo-cult and can be
removed.
Note that there's a risk that the ioctl will behave inconsistently,
but that's ok. The
No one looks at the major/minor versions except the unique/busid
stuff. If we protect that with the master_mutex (since it also affects
the unique of each master, oh well) we can mark these two IOCTL with
DRM_UNLOCKED.
While doing this I realized that the comment for the magic_map is
outdated, I'v
Hi Dave,
Just the controlD* regression fix, with t-b from Alex and ack from Greg.
Cheers, Daniel
The following changes since commit 72a93e8dd52c9feea42f1258d555e6070680a347:
drm: Take ownership of the dmabuf->obj when exporting (2016-12-08 10:29:22
+0100)
are available in the git repositor
On Fri, Dec 09, 2016 at 09:57:45PM +, Chris Wilson wrote:
> On Fri, Dec 09, 2016 at 03:19:43PM +0100, Daniel Vetter wrote:
> > We can be more clever than that and merge the 2 list walking loops.
> > It's all under the one mutex critical section anyway, so nothing funny
> > can happen.
> >
> >
On Fri, Dec 09, 2016 at 04:52:32PM +, Chris Wilson wrote:
> With prime, we are running into false circular dependencies based on the
> order in which two drivers may lock their own struct_mutex wrt to a
> common lock (like the reservation->lock). Work around this by adding the
> lock_class_key
On Sat, Dec 10, 2016 at 10:52:55PM +0100, Daniel Vetter wrote:
> Looping twice when we can do it once is silly. Also use a consistent
> style. Note that there's a good race with the connector list walking,
> since that is no longer protected by mode_config.mutex. But that's for
> a later patch to f
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161210/ff19c233/attachment.html>
On Sat, Dec 10, 2016 at 09:28:02PM +, Chris Wilson wrote:
> On Sat, Dec 10, 2016 at 09:23:35PM +, Chris Wilson wrote:
> > On Sat, Dec 10, 2016 at 10:19:30PM +0100, Daniel Vetter wrote:
> > > On Fri, Dec 09, 2016 at 04:52:32PM +, Chris Wilson wrote:
> > > > With prime, we are running int
On Sat, Dec 10, 2016 at 09:23:35PM +, Chris Wilson wrote:
> On Sat, Dec 10, 2016 at 10:19:30PM +0100, Daniel Vetter wrote:
> > On Fri, Dec 09, 2016 at 04:52:32PM +, Chris Wilson wrote:
> > > With prime, we are running into false circular dependencies based on the
> > > order in which two dr
On Sat, Dec 10, 2016 at 10:19:30PM +0100, Daniel Vetter wrote:
> On Fri, Dec 09, 2016 at 04:52:32PM +, Chris Wilson wrote:
> > With prime, we are running into false circular dependencies based on the
> > order in which two drivers may lock their own struct_mutex wrt to a
> > common lock (like t
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161210/6b00cdca/attachment.html>
On Fri, Dec 9, 2016 at 3:30 PM, Dave Airlie wrote:
>> I think this is part of the reason a lot of people get fed up with working
>> upstream in Linux. I can respect your technical points and if you kept it
>> to that, I'd be fine with it and we could have a technical discussion
>> starting the
> So the MMU fault is somehow specific to what I'm doing. Interesting.
I think I found the issue: the MMU "flush and sync" is not good enough in some
cases.
What the Vivante kernel driver does, for MMUv2, after mapping some kinds of
buffer objects (apparently those tagged INDEX and VERTEX, this i
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161210/bd488147/attachment.html>
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
Implement a generic drmGetDeviceNameFromFd2() to use on non-linux
systems without sysfs.
Signed-off-by: Jonathan Gray
---
xf86drm.c | 44 ++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 6705605..afce8ec 10064
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.
Signed-off-by: Jonathan
93
--
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/20161210/d36197c7/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=190021
Bug ID: 190021
Summary: WARNING: CPU: 0 PID: 38 at
drivers/gpu/drm/drm_atomic_helper.c:1549
drm_atomic_helper_commit_hw_done+0xa6/0xb0
[drm_kms_helper]
P
> <3>[ 549.814025] etnaviv-gpu 13.gpu: MMU fault status 0x0002 <-
> happens almost immediately
> <3>[ 549.819960] etnaviv-gpu 13.gpu: MMU 0 fault addr 0xe8783040
> <3>[ 549.825889] etnaviv-gpu 13.gpu: MMU 1 fault addr 0x
> <3>[ 549.831817] etnaviv-gpu 13.gpu: MMU 2
I'm having an issue where a long-running test eventually runs into a MMU
fault. What this test does is basically:
- while [ 1 ]; do start a program that:
- Allocate bo A, B and C, D
- Map bo C, update it
- Loop
- Map bo A B and C, update them
- Build command buffer
ue until the end of the
buffer\0"
--
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/20161210/4438e5fe/attachment.html>
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/20161210/bea1f3c9/attachment-0001.html>
Look likes, the BOE panel FW didn't ack the DPCD600 signal from the host
device, that will cause the panel hang on the startup display.
The root cause we use the fast link mode during enter and exit the psr,
this issue is gone if switching the fast link to main link mode.
Signed-off-by: Caesar Wan
On Fri, 2016-12-09 at 14:57 +0100, David Herrmann wrote:
> Despite all of this I still see no reason why a driver could not
> expose the static, real frambuffers via private ioctls. You can get
> all your fancy acceleration that way. Then fix user-space to use this
> API. If enough drivers end up w
On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
> > As for multi userspace client, well, swapping an mmap between HW and
> > memory backing store is a somewhat solved problem already.
>
> Hm, I didn't know that, but then all existing drm drivers have fairly
> simplistic fbdev mmap implemen
On 10 December 2016 at 05:59, Daniel Vetter wrote:
> I guess things went a bit sideways by me and Dave only talking about
> the midlayer, so let me first state that the DC stuff has massively
> improved through replacing all the backend services that reimplemented
> Linux helper libraries with the
> I think this is part of the reason a lot of people get fed up with working
> upstream in Linux. I can respect your technical points and if you kept it to
> that, I'd be fine with it and we could have a technical discussion starting
> there. But attacking us or our corporate culture is not co
bbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161210/479ff441/attachment.html>
ed between CPU cores this much. And it seems
that my CPU is slower than I thought.
--
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/a
33 matches
Mail list logo
