On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote:
> On 08/10/15 21:50, Wayne Boyer wrote:
> >From: Chris Wilson
> >
> >A long time ago (before 3.14) we relied on a permanent pinning of the
> >ifbdev to lock the fb in place inside the GGTT. However, the
>
On Fri, Oct 30, 2015 at 05:18:15PM +0100, Daniel Vetter wrote:
> On Fri, Oct 23, 2015 at 10:17:44PM +0100, Dave Gordon wrote:
> > On 08/10/15 21:50, Wayne Boyer wrote:
> > >From: Chris Wilson
> > >
> > >A long time ago (before 3.14) we relied on a permanent pinning of
Hi,
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS
Another observation that occurred to me only after sending away my
previous message (sorry):
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the
On 08/10/15 21:50, Wayne Boyer wrote:
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the
On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and
On Fri, 09 Oct 2015, Chris Wilson wrote:
> On Thu, Oct 08, 2015 at 01:50:21PM -0700, Wayne Boyer wrote:
>> From: Chris Wilson
>>
>> A long time ago (before 3.14) we relied on a permanent pinning of the
>> ifbdev to lock the fb in place inside
On Wed, Oct 07, 2015 at 11:34:17AM -0700, Wayne Boyer wrote:
> From: Chris Wilson
>
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and
On 10/08/2015 02:07 AM, Chris Wilson wrote:
> On Wed, Oct 07, 2015 at 11:34:17AM -0700, Wayne Boyer wrote:
>> From: Chris Wilson
>>
>> A long time ago (before 3.14) we relied on a permanent pinning of the
>> ifbdev to lock the fb in place inside the GGTT. However, the
>>
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and
On Fri, Oct 02, 2015 at 10:16:26PM +, Boyer, Wayne wrote:
> On 8/26/15, 1:23 AM, Deepak wrote:
>
>
> >
> >
> >On 08/25/2015 10:18 PM, Chris Wilson wrote:
> >> A long time ago (before 3.14) we relied on a permanent pinning of the
> >> ifbdev to lock the fb in place
On 8/26/15, 1:23 AM, Deepak wrote:
>
>
>On 08/25/2015 10:18 PM, Chris Wilson wrote:
>> A long time ago (before 3.14) we relied on a permanent pinning of the
>> ifbdev to lock the fb in place inside the GGTT. However, the
>> introduction of stealing the BIOS framebuffer
On 08/25/2015 10:18 PM, Chris Wilson wrote:
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited
15 matches
Mail list logo