Hi Russell,
On Tue, 26 Jun 2018 at 15:49, Russell King - ARM Linux
wrote:
> On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote:
> > Thanks Russell. I did do a build test locally as well which had no
> > complaints. I'll merge this through drm-misc.
>
> I've not seen this go in during
On Thu, May 17, 2018 at 04:41:35PM +0100, Daniel Stone wrote:
> On 17 May 2018 at 16:26, Russell King - ARM Linux
> wrote:
> > On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
> >> On 30 March 2018 at 15:11, Daniel Stone wrote:
> >> > Since drm_framebuffer can now store GEM objects
On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
> Hi Russell,
>
> On 30 March 2018 at 15:11, Daniel Stone wrote:
> > Since drm_framebuffer can now store GEM objects directly, place them
> > there rather than in our own subclass. As this makes the framebuffer
On 17 May 2018 at 16:26, Russell King - ARM Linux wrote:
> On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
>> On 30 March 2018 at 15:11, Daniel Stone wrote:
>> > Since drm_framebuffer can now store GEM objects directly, place them
>> >
On Fri, Mar 30, 2018 at 03:11:33PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse
Hi Russell,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
>
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.
Signed-off-by: Daniel Stone
Cc: Russell