On 03/04/17 01:31 AM, Keith Packard wrote:
> Daniel Vetter writes:
>
>> I'm also not sure whether we really want sub-leases in v1, that's easy
>> to add later on, but for now just complicates stuff. Main compositor
>> should be a full master, VR can be the first lease level, we don't
>> need more
Daniel Vetter writes:
> On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote:
>> +BUG_ON(__mutex_owner(&master->dev->mode_config.idr_mutex) != current);
>
> Forgot to reply on this:
>
> lockdep_assert_held + enable lockdep.
Thanks. Will fix.
--
-keith
signature.asc
Description:
Daniel Vetter writes:
> Still not sure we want to restrict objects on the lessor side. Feels like
> unecessary complexity (i.e. more bugs in kernel, that's never good), and
> at best only needed for lessors who can't keep track of stuff.
It's been useful when hacking existing code, and will help
On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote:
> + BUG_ON(__mutex_owner(&master->dev->mode_config.idr_mutex) != current);
Forgot to reply on this:
lockdep_assert_held + enable lockdep.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote:
> This provides new data structures to hold "lease" information about
> drm mode setting objects, and provides for creating new drm_masters
> which have access to a subset of the available drm resources.
>
> An 'owner' is a drm_master
This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.
An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns
