On Wed, Apr 12, 2017 at 11:00:18AM -0700, Eric Anholt wrote:
> Martin Peres writes:
>
> > On 11/04/17 04:47, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a link may become
> >>>
Martin Peres writes:
> On 11/04/17 04:47, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this point, the
>>>
On 11/04/17 04:47, Eric Anholt wrote:
Martin Peres writes:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and
Martin Peres writes:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> >> Manasi Navare writes:
> >>
> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt
On Mon, Apr 3, 2017 at 8:25 AM, Manasi Navare wrote:
>> So in that case you do need userspace to re-request the same mode at the
>> same bpp?
>
> So yes because when userspace requests the same mode at same bpp,
> kernel will still call intel_dp->mod_valid which
On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> Manasi Navare writes:
>
> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
> >> Manasi Navare writes:
> >>
> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric
On Mon, Apr 03, 2017 at 09:19:35AM +0200, Daniel Vetter wrote:
> On Mon, Apr 3, 2017 at 8:25 AM, Manasi Navare
> wrote:
> >> So in that case you do need userspace to re-request the same mode at the
> >> same bpp?
> >
> > So yes because when userspace requests the same
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> >> Manasi Navare writes:
> >>
> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt
Daniel Vetter writes:
> On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
>> Manasi Navare writes:
>>
>> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
>> >> Manasi Navare writes:
>> >>
>> >> >
Manasi Navare writes:
> On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
>> Manasi Navare writes:
>>
>> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
>> >> Martin Peres writes:
>>
On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
> Manasi Navare writes:
>
> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >> > On 26/01/17 14:37, Martin Peres wrote:
> >> >>
Manasi Navare writes:
> On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
>> Martin Peres writes:
>>
>> > On 26/01/17 14:37, Martin Peres wrote:
>> >> Despite all the careful planing of the kernel, a link may become
>> >>
On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
> Martin Peres writes:
>
> > On 26/01/17 14:37, Martin Peres wrote:
> >> Despite all the careful planing of the kernel, a link may become
> >> insufficient to handle the currently-set mode. At this point,
Martin Peres writes:
> On 26/01/17 14:37, Martin Peres wrote:
>> Despite all the careful planing of the kernel, a link may become
>> insufficient to handle the currently-set mode. At this point, the
>> kernel should mark this particular configuration as being broken
On 26/01/17 14:37, Martin Peres wrote:
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending
On Thu, Feb 02, 2017 at 09:57:20AM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >> Jani Nikula writes:
> >>
> >> > On Tue, 31 Jan 2017, Eric Anholt wrote:
>
On Tue, Feb 28, 2017 at 04:07:02AM +, Navare, Manasi D wrote:
>
> On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote:
> > Hi Daniel,
> >
> > We have ACKs on the userspace design from both Adams and Eric.
> > Is this enough to merge the kernel patches?
> >
> > I spoke to Eric
On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote:
> Hi Daniel,
>
> We have ACKs on the userspace design from both Adams and Eric.
> Is this enough to merge the kernel patches?
>
> I spoke to Eric briefly about this and he gave me a verbal r-b as well.
> He said the userspace
On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote:
> Hi Daniel,
>
> We have ACKs on the userspace design from both Adams and Eric.
> Is this enough to merge the kernel patches?
>
> I spoke to Eric briefly about this and he gave me a verbal r-b as well.
> He said the userspace patches
Hi Daniel,
We have ACKs on the userspace design from both Adams and Eric.
Is this enough to merge the kernel patches?
I spoke to Eric briefly about this and he gave me a verbal r-b as well.
He said the userspace patches cant get merged unless DRM patches are merged.
So what should be some of
On 13/02/17 23:05, Eric Anholt wrote:
I was just trying to provide review to get the kernel unstuck. The
kernel should not be blocked until the patch gets lands (this obviously
isn't the case with ioctls, which *don't* land in userspace until kernel
does), you just need userspace published and
On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> Martin Peres writes:
>
> > On 06/02/17 17:50, Martin Peres wrote:
> >> On 03/02/17 10:04, Daniel Vetter wrote:
> >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
> On 01/02/17
Martin Peres writes:
> On 06/02/17 17:50, Martin Peres wrote:
>> On 03/02/17 10:04, Daniel Vetter wrote:
>>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800,
On 06/02/17 17:50, Martin Peres wrote:
On 03/02/17 10:04, Daniel Vetter wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On 03/02/17 10:04, Daniel Vetter wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric Anholt
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
> On 01/02/17 22:05, Manasi Navare wrote:
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> > > Jani Nikula writes:
> > >
> > > > On Tue, 31 Jan 2017, Eric Anholt wrote:
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
> On 01/02/17 22:05, Manasi Navare wrote:
> >On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >>Jani Nikula writes:
> >>
> >>>On Tue, 31 Jan 2017, Eric Anholt wrote:
>
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> Jani Nikula writes:
>
> > On Tue, 31 Jan 2017, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a
On 01/02/17 22:05, Manasi Navare wrote:
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
Jani Nikula writes:
On Tue, 31 Jan 2017, Eric Anholt wrote:
Martin Peres writes:
Despite all the careful
Daniel Vetter writes:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
>> Jani Nikula writes:
>>
>> > On Tue, 31 Jan 2017, Eric Anholt wrote:
>> >> Martin Peres writes:
>> >>
>> >>>
On Tue, 31 Jan 2017, Eric Anholt wrote:
> Martin Peres writes:
>
>> Despite all the careful planing of the kernel, a link may become
>> insufficient to handle the currently-set mode. At this point, the
>> kernel should mark this particular
On Tue, 31 Jan 2017, Manasi Navare wrote:
> On Thu, Jan 26, 2017 at 06:21:20PM +0100, Daniel Vetter wrote:
>> On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
>> > Despite all the careful planing of the kernel, a link may become
>> > insufficient to handle
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> Jani Nikula writes:
>
> > On Tue, 31 Jan 2017, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a
Jani Nikula writes:
> On Tue, 31 Jan 2017, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this
On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode
Martin Peres writes:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before
On Thu, Jan 26, 2017 at 06:21:20PM +0100, Daniel Vetter wrote:
> On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
> > Despite all the careful planing of the kernel, a link may become
> > insufficient to handle the currently-set mode. At this point, the
> > kernel should mark this
On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode
Despite all the careful planing of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send
41 matches
Mail list logo