linux-kernel - Re: [PATCH v3 1/3] drm: add SimpleDRM driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160817105840.GU6232@phenom.ffwll.local>
Date:	Wed, 17 Aug 2016 12:58:40 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Noralf Trønnes <noralf@...nnes.org>
Cc:	Daniel Vetter <daniel@...ll.ch>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] drm: add SimpleDRM driver

On Wed, Aug 17, 2016 at 12:19:02PM +0200, Noralf Trønnes wrote:
> 
> Den 17.08.2016 11:30, skrev Daniel Vetter:
> > On Tue, Aug 16, 2016 at 9:38 PM, Noralf Trønnes <noralf@...nnes.org> wrote:
> > > > That's still a lot for what amounts to reimplementing mmap on shmem, but
> > > > badly. What I mean with redirecting is pointing the entire ->mmap
> > > > operation to the mmap implementation for the underlying mmap. Roughly:
> > > > 
> > > >          /* normal gem mmap checks first */
> > > > 
> > > >          /* redirect to shmem mmap */
> > > >          vma->vm_file = obj->filp;
> > > >          vma->vm_pgoff = 0;
> > > > 
> > > >          return obj->filp->f_op->mmap(obj->filp, vma);
> > > > 
> > > > Much less code ;-)
> > > 
> > > obj->filp is NULL in my case.
> > > 
> > > And looking at the docs, that's expected since I have driver specific
> > > backing?
> > > 
> > > /**
> > >   * @filp:
> > >   *
> > >   * SHMEM file node used as backing storage for swappable buffer objects.
> > >   * GEM also supports driver private objects with driver-specific backing
> > >   * storage (contiguous CMA memory, special reserved blocks). In this
> > >   * case @filp is NULL.
> > >   */
> > Hm, I totally misread the driver code. I assumed that we'd just
> > allocate normal shmem gem objects, and then copy them on-demand onto
> > the frontbuffer (in the dirty or plane update callbacks). Essentially
> > treat the firmware fb area as a manual upload display, except that we
> > don't use i2c or spi to do the upload, but normal mmio writes. I think
> > that would greatly simplify the driver, and more important: It would
> > also work like any other kms driver. Currently sdrm is violiting the
> > spec a bit by aliasing all dumb buffers to the same underlying backing
> > storage, and that's a bit evil.
> > 
> > The other bit I noticed (and why I was confused): The prime import
> > code reinvents a lot of wheels, and it digs into the backing storage
> > directly. Instead it should just call dma_buf_vmap/dma_buf_vunmap and
> > let the exporter figure out how it works.
> 
> Is there a driver I can look at that does it the way we want?
> I'm afraid that this gem framework is still over my head.
> Copying code or patterns is easy, starting from scratch demands
> understanding :-)

udl_gem.c is pretty much what I had in mind, including the handling of
dma-bufs and all that. Not sure how much point there is in sharing code,
at least if you can't test udl.

What udl doesn't do is directly redirect the mmap to the shmem node (and
reject the mmap for dma-buf imported buffers, since that's not a good idea
really).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch