Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

2016-12-10 Thread Srivatsa, Anusha
>-Original Message- >From: Michal Wajdeczko [mailto:michal.wajdec...@linux.intel.com] >Sent: Friday, December 9, 2016 4:37 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine > >Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authenticat

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm: Protect master->unique with dev->master_mutex

2016-12-10 Thread Patchwork
== Series Details == Series: series starting with [1/4] drm: Protect master->unique with dev->master_mutex URL : https://patchwork.freedesktop.org/series/16661/ State : failure == Summary == Series 16661v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/16661/revi

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread Daniel Vetter
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 +

Re: [Intel-gfx] [PATCH 4/4] drm: Simplify GETRESOURCES ioctl

2016-12-10 Thread Chris Wilson
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

[Intel-gfx] [PATCH 1/4] drm: Protect master->unique with dev->master_mutex

2016-12-10 Thread Daniel Vetter
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

[Intel-gfx] [PATCH 3/4] drm: Enforce BKL-less ioctls for modern drivers

2016-12-10 Thread Daniel Vetter
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

[Intel-gfx] [PATCH 4/4] drm: Simplify GETRESOURCES ioctl

2016-12-10 Thread Daniel Vetter
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

[Intel-gfx] [PATCH 2/4] drm: setclientcap doesn't need the drm BKL

2016-12-10 Thread Daniel Vetter
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

[Intel-gfx] [PULL] drm-misc-next-fixes

2016-12-10 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread Chris Wilson
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

Re: [Intel-gfx] [PATCH 6/7] drm: Don't walk fb list twice in getresources

2016-12-10 Thread Daniel Vetter
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. > > > >

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread Chris Wilson
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

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread Chris Wilson
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

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread Daniel Vetter
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

Re: [Intel-gfx] [PATCH] drm: Make each driver's struct_mutex its own subclass

2016-12-10 Thread kbuild test robot
-each-driver-s-struct_mutex-its-own-subclass/20161210-33 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. incl