On Tue, May 22, 2018 at 10:24:18AM +0100, Daniel Stone wrote:
> On 22 May 2018 at 10:19, Thierry Reding wrote:
> > On Mon, May 21, 2018 at 03:24:49PM +0100, Daniel Stone wrote:
> >> bc61c97502e2 moved the gtt_range structure, from being in
> >> psb_framebuffer and embedding the GEM object, to bein
On 22 May 2018 at 10:19, Thierry Reding wrote:
> On Mon, May 21, 2018 at 03:24:49PM +0100, Daniel Stone wrote:
>> bc61c97502e2 moved the gtt_range structure, from being in
>> psb_framebuffer and embedding the GEM object, to being placed in the
>> drm_framebuffer with the gtt_range being derived fr
On Mon, May 21, 2018 at 03:24:49PM +0100, Daniel Stone wrote:
> bc61c97502e2 moved the gtt_range structure, from being in
> psb_framebuffer and embedding the GEM object, to being placed in the
> drm_framebuffer with the gtt_range being derived from the GEM object.
>
> The conversion missed out the
bc61c97502e2 moved the gtt_range structure, from being in
psb_framebuffer and embedding the GEM object, to being placed in the
drm_framebuffer with the gtt_range being derived from the GEM object.
The conversion missed out the Medfield subdriver, which was not being
built in the default drm-misc c
