gitignore

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Revive SATA Makefile entry

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
omap5: sata: use soc_is_ instead of cpu_is_

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Turn on SATA

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Revive sata ocp2scp3 hwmod data

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Tweak config

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Symlinks to enable DDK compilation

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
WIP: drm/omap: V2: add plugin API
OMAP4: change default GPU clock source to PER DPLL

POR for GPU Clock source is the PER DPLL. It permits selecting GPU
freqs like 307MHz or 384MHz.

Signed-off-by: Sebastien Jan <s-jan@ti.com>

[Rebase on 3.7]
Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Kernel changes for hwmod and omap_device initialization for GPU.

Change-Id: I4bd96e76af31d0991ce9e67b0c499f0d6f39a1a8
Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>

[Rebase on 3.7]
Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
OMAP5: hwmod: fix gpu offsets

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
Hack! Map the whole GPU for now

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
omapdrm gem ioctl protect

Signed-off-by: Andy Green <andy.green@linaro.org>
staging: drm/omap: fix NULL pointer dereference
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Make sure we do not dereference NULL pointers when things go wrong in
omap_framebuffer_replace.

Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
WIP: V2: syncobj updates

 - v2 disable syncdbg traces
Change kmap/kunmap in OMAP DRM/GEM so that mapped buffers will be flushed to RAM after being modified
fix ref leak of external buffers (merge back to plugin API)

drm_gem_mmap() increments the ref count, and expects the corresponding
vm_close fxn to decrement it.. otherwise you have a memory leak.
HACK: drm_gem_mmap - do not check valid size

Signed-off-by: Xavier Boudet <x-boudet@ti.com>
drm/prime: fixup the dma buf export cache locking

Well, actually add some, because currently there's exactly none:
- in handle_to_fd we only take the file_priv's prime lock, but the
  underlying gem object we're exporting isn't per-file.
- in each driver's dma_buf->release callback we don't grab any locks
  at all.

Also, we're not protected by any object lifetime rules: We can export
and GEM object then fclose that fd _while_ we re-export the same
object again. If we're unlucky, we'll see a non-zero export_dma_buf,
but the file's refcount is already zero.

To fix this, we need two pieces:
- We need to add some locking. I've opted for a new per-device lock to
  not entangle this locking with the already messy dev->struct_mutex
  misery.
- We need to hold a reference onto the dma buf object while
  exported_dma_buf is non-NULL.  Otherwise we'll always have races
  where the dma buf's file refcount is zero already, but
  export_dma_buf is still set.

Now obviously this dma buf reference would lead to a refcount loop, so
we need to break that at the right time. Do the same trick as for the
gem flink name: As soon as all GEM userspace handles are gone (i.e.
obj->handle_count == 0) we drop this dma_buf reference.

This has a few funny complications:
- We could hold the last dma buf reference (but by necessity not the
  last reference to the underlying GEM object). The only thing that
  can therefore happen is that the dma buf object gets freed and we
  call the driver's ->release callback. Which needs to drop its own
  reference to the underlying GEM object.

  To ensure that we don't end up with surprises kill the (already)
  unused handle_unreference variant and only expose the unlocked one
  (which is safer).

- Userspace might race with us when exporting a dma_buf and close the
  last userspace GEM handle. Check for that and re-call handle_free to
  clean up the mess. Note that the current flink name code is
  suffering from the same race but doesn't hanlde it. A follow-up
  patch will fix this.

- Userspace might drop all GEM handles, but still hold a reference
  through a dma buf object. To ensure that an export of this object
  after it has been imported will do the right thing, we also need to
  set up the dma buf cache again. Otherwise we could create a second
  dma buf when exporting it again. Also add some paranoia and check
  whether a re-import gives back the right dma_buf.

  Because this cache is now not only set on export but also on import
  and is always set if there's a dma buf associated for this GEM
  object (and some GEM userspace handles still around), drop the
  export_ prefix and just call it obj->dma_buf.

Note that this patch also fixes another little race on the export
side: As soon as we've called dma_buf_fd, userspace could sneak in and
close the fd, hence reaping the last reference count to the dma_buf
and destroying it. Avoid this use-after-free by doing the
fd-installing last, once everything has been set up correctly.

v2: Be careful to not drop any references while holding locks. This
only really affected -ENOMEM error paths, but could lead to a deadlock
on one of the prime locks.

v3: Chris Wilson complained that a per-obj mutex is a bit much. So
moved to the device again.

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/prime: drop reference on imported dma-buf

The GEM handle takes the reference.  If a driver is actually importing a
foreign dmabuf, rather than just re-importing it's own dmabuf, it needs
to do a get_dma_buf().