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>
Hack! Tweak hwmod to 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().
omapdrm no need to die if no detect callback

Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Vincent Stehlé <v-stehle@ti.com>
drm: remove unused fxn prototypes

Signed-off-by: Rob Clark <rob@ti.com>
OMAPDSS: workaround 'operation stopped while reading edid' error

Signed-off-by: Rob Clark <rob@ti.com>
ARM: OMAP: usb: musb: OMAP: Delete unused function

Not in use anymore.

Signed-off-by: Bjarne Steinsbo <bsteinsbo@gmail.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
OMAP5: usbhs: Add mux initialization for ehci to support HSIC

Adds mux initialization to support hsic mode in EHCI. This includes
mux initialization for port3 that has been added in omap5.

Rename setup_ehci/ohci_io_mux funcs to setup_34xx_ehci/ohci_io_mux
As these are used only for OMAP3 socs.

Rename setup_4430ehci/ohci_io_mux to setup_ehci_io_mux as this will
be used for both omap4 and omap5 socs.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
usb: ehci: Add custom irq handler.

With irq chaining used by PM layer to wakeup the
module based on pad wakeup event calling hcd irq
handler. Now accessing ehci regs without enabling
host & port clocks can cause interconnect error.
So enable host and port clocks if disabled form usb
autosuspend before handling usb irq's.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
usb: uhh: Adapt mux configuration mux_hwmod framework

Adapt the mux configuration to current hwmod and mux
framework, and mark compatible pins as wakeup capable.

Signed-off-by: Govindraj.R <govindraj.raja@ti.com>