[Intel-gfx] [RFC PATCH 07/12] drm/i915/dsi: switch to drm_panel interface

Shobhit Kumar shobhit.kumar at linux.intel.com
Tue Jan 27 00:52:52 PST 2015


On 01/23/2015 09:01 PM, Daniel Vetter wrote:
> On Fri, Jan 23, 2015 at 04:27:46PM +0530, Shobhit Kumar wrote:
>> On 01/16/2015 05:57 PM, Jani Nikula wrote:
>>> @@ -881,13 +889,23 @@ void intel_dsi_init(struct drm_device *dev)
>>>
>>>   	drm_connector_register(connector);
>>>
>>> -	fixed_mode = dsi->dev_ops->get_modes(&intel_dsi->dev);
>>> +	drm_panel_attach(intel_dsi->panel, connector);
>>> +	drm_panel_get_modes(intel_dsi->panel);
>>
>> Should be inside the config mutex_lock below.
>
> Why?

Because usually the drm_mode_probed_add gets called in the drm flow with 
correct locking, but in this case calling get_modes here results in 
drm_mode_probed_add being called which expects the lock to be taken. 
Else we will see a big WARN dump. I agree with your comment below but 
this was mainly to avoid the warning dump.

>
>>> +
>>> +	mutex_lock(&dev->mode_config.mutex);
>>> +	list_for_each_entry(scan, &connector->probed_modes, head) {
>>> +		if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
>>> +			fixed_mode = drm_mode_duplicate(dev, scan);
>>> +			break;
>>> +		}
>>> +	}
>>> +	mutex_unlock(&dev->mode_config.mutex);
>
> Generally this is single-threaded init code, no one else can touch it.
> Which means you also never ever need locks. We tend to occasionally
> sprinkle them around to satisfy general locking checks which are correct
> at runtime. But at least in tricky cases that means we also stick a
> comment next to them (see e.g. the various places in i915_irq.c).
>
> Merged up to the previous patch, thanks a lot.
> -Daniel
>

Regards
Shobhit


More information about the Intel-gfx mailing list