On Tue, Mar 01, 2016 at 06:17:33AM +0530, Thulasimani, Sivakumar wrote:
>
>
> On 3/1/2016 5:03 AM, Rob Clark wrote:
> >On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> >>On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>>
> >>>On 2/24/2016 3:41 AM, Lyude wrote:
On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote:
> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>
> >> On 2/24/2016 3:41 AM, Lyude wrote:
> >> >As it turns out, resuming DP MST is racey since we
On Wed, Mar 2, 2016 at 4:29 AM, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote:
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>> >>
>> >>
>> >> On 2/24/2016 3:41 AM, Lyude wr
On Tue, Mar 01, 2016 at 07:33:12AM +1000, Dave Airlie wrote:
> On 1 March 2016 at 02:12, Daniel Vetter wrote:
> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>
> >> On 2/24/2016 3:41 AM, Lyude wrote:
> >> >As it turns out, resuming DP MST is racey since we don't
On 1 March 2016 at 02:12, Daniel Vetter wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just usually
On 3/1/2016 5:03 AM, Rob Clark wrote:
> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>>
>>> On 2/24/2016 3:41 AM, Lyude wrote:
As it turns out, resuming DP MST is racey since we don't make sure MST
is
On Mon, Feb 29, 2016 at 7:47 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 3/1/2016 5:03 AM, Rob Clark wrote:
>>
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
On 2/24/2016 3:41 AM, Lyude wrote:
On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just
On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
> >As it turns out, resuming DP MST is racey since we don't make sure MST
> >is ready before we start modesetting, it just usually happens to be
> >ready in time. This isn't the case o
On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
>>
>> As it turns out, resuming DP MST is racey since we don't make sure MST
>> is ready before we start modesetting, it just usually happens to be
>> ready in time. This isn't the case on all s
Unfortunately MST is a wild beast, and doesn't work at all like other
connectors. This being said, putting it above intel_display_resume() was the
first thing I tried but that didn't work. Originally I had thought putting it
this high up was required because I had assumed drm_mode_config_reset() wa
On 2/24/2016 3:41 AM, Lyude wrote:
> As it turns out, resuming DP MST is racey since we don't make sure MST
> is ready before we start modesetting, it just usually happens to be
> ready in time. This isn't the case on all systems, particularly a
> ThinkPad T560 with displays connected through the
As it turns out, resuming DP MST is racey since we don't make sure MST
is ready before we start modesetting, it just usually happens to be
ready in time. This isn't the case on all systems, particularly a
ThinkPad T560 with displays connected through the dock. On these
systems, resuming the laptop
13 matches
Mail list logo