On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote: > On Wed, Feb 22, 2017 at 12:01:12AM +0000, Pandiyan, Dhinakaran wrote: > > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > > > > > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: > > > >> Comparing this func to > > > >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it > > > >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already > > > >> exist. I > > > >> don't understand the locking stuff toowell, I just noticed this > > > >> difference when > > > >> comparing this approach with what is done in the msm kms driver (where > > > >> we > > > >> have subclassed drm_atomic_state to msm_kms_state). > > > >> > > > >> Thanks, > > > >> Archit > > > >> > > > > > > > > > > > > The caller is expected to take care of any required locking. The > > > > driver-private objects are opaque from core's pov, so the core is not > > > > aware of necessary locks for that object type. > > > > > > I had a look at the rest of the series, and I couldn't easily understand > > > whether the caller code protects the MST related driver private state. Is > > > it expected to be protect via the drm_mode_config.connection_mutex lock? > > > > > > Thanks, > > > Archit > > > > > > > That's right, the connection_mutex takes care of the locking for the MST > > private state. I can add that as a comment to the caller's (MST helper) > > kernel doc with a > > > > WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)); > > Please don't add this as a comment, but as real code so it is checked at > runtime :-) Personally I wouldn't mention locking rules in kernel-doc, > that part tends to get outdated fast. Better to enforce with > runtime-checks. > -Daniel
That's what I meant but evidently didn't type it that way:) I was going to add that the connection_mutex does the locking for MST state as a comment and put the WARN_ON() in code. -DK _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
