OMAPDSS fixes for 3.10:

* Compilation fix when DSI is disabled in Kconfig
* Basic deferred probe support to fix DT boot

* tag 'omapdss-for-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux:
  OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found
  OMAPDSS: VENC: Add error handling for venc_probe_pdata
  OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata
  OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata
  OMAPDSS: DSI: Add error handling for dsi_probe_pdata
  OMAPDSS: SDI: Add error handling for sdi_probe_pdata
  OMAPDSS: DPI: Add error handling for dpi_probe_pdata
  OMAPDSS: VENC: use platform_driver_register()
  OMAPDSS: HDMI: use platform_driver_register()
  OMAPDSS: RFBI: use platform_driver_register()
  OMAPDSS: DSI: use platform_driver_register()
  OMAPDSS: SDI: use platform_driver_register()
  OMAPDSS: DPI: use platform_driver_register()
  OMAPFB: defer probe if no displays
  OMAPFB: use module_platform_driver()
  OMAPDSS: Makefile: move omapfb after panels
  OMAPDSS: DPI: fix compilation if DSI not compiled in

Just some fixes that have accumulated over the last couple of
weeks and some new PCI ids.

* 'drm-next-3.10-2' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: fix handling of v6 power tables
  drm/radeon: clarify family checks in pm table parsing
  drm/radeon: consolidate UVD clock programming
  drm/radeon: fix UPLL_REF_DIV_MASK definition
  radeon: add bo tracking debugfs
  drm/radeon: add new richland pci ids
  drm/radeon: add some new SI PCI ids
  drm/radeon: fix scratch reg handling for UVD fence
  drm/radeon: allocate SA bo in the requested domain
  drm/radeon: fix possible segfault when parsing pm tables
  drm/radeon: fix endian bugs in atom_allocate_fb_scratch()

Signed-off-by: NDave Airlie <airlied@redhat.com>

The code was mis-handling variable sized arrays.
Reported-by: NSylvain BERTRAND <sylware@legeek.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We actually care about the chip family rather than the
DCE version although functionally they are the same.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Instead of duplicating the code over and over again, just use a single
function to handle the clock calculations.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Stupid copy & paste error over all generations.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is to allow debugging of userspace program not freeing buffer
after, which is basicly a memory leak. This print the list of all
gem object along with their size and placement (VRAM,GTT,CPU) and
with the pid of the task that created them.

agd5f: add warning fix
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Also init the scratch reg to zero on the UVD ring.
This fixes UVD on AGP based cards.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This avoid moving the BO directly after allocating it.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If we have a empty power table, bail early and allocate
the default power state.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=63865Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Reviwed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If the I2C adapter needed by the TFP410 device is not available yet,
return EPROBE_DEFER so that the device will get probed again.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for venc_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the VENC driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for hdmi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the HDMI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for rfbi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the RFBI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for dsi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DSI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for sdi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the SDI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for dpi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the DPI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use platform_driver_register() instead of platform_driver_probe() so
that we can support EPROBE_DEFER.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb requires the panel drivers to have been probed when omapfb is
initialized. omapfb does not support insertion of new panels after its
probe. This causes a problem in case omapdss or the panel probes have
been deferred due to EPROBE_DEFER error, as omapfb won't find any
displays.

As a quick fix, this patch changes the omapfb probe so that if omapfb
does not find any displays, it'll return EPROBE_DEFER. This is not
perfect, as with a board with no displays, omapfb will get deferred
forever. Also, if the board has multiple displays, but only some of them
have been probed, omapfb will start and leave the unprobed displays out.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using platform_driver_probe(), use module_platform_driver()
so that we can support deferred probing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb requires the panels to have been probed before omapfb's probe. We
currently manage that by having omapfb in late initcall level. However,
a much simpler way is to just change the makefile so that omapfb is
after the panel drivers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit 100c8262 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.

Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next

Add GK110 modesetting suport.

* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nve0: recognise nvf0 as a kepler board (GK110)
  drm/nouveau: force noaccel when no PFIFO support present
  drm/nvf0/disp: expose display class 2.2

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Sometimes that extra semicolon can really be hard to spot.
Acked-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_gem_release should release all handles connected to the drm file and
so should also release the prime lookup entries of these handles. So
just WARN if this isn't the case.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This just moves the fb sysfs node beside the drm sysfs node which
I fixed before.

just noticed it in passing.
Signed-off-by: NDave Airlie <airlied@redhat.com>

In commit be8a42ae we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.

Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing the
bug this is also more logical.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close. The reference gets added at step 2,
but at step 6 we don't have enough info to clean it up.

The solution is to take a reference on the dma-buf when we export it,
and drop the reference when the gem handle goes away.

So when we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.

This patch isn't meant to fix any other problem or bikesheds, and it doesn't
fix any races with other scenarios.

v1.1: move export symbol line back up.

v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.

v2.1: rebase this patch, write better commit msg.
v3: cleanup error handling, track import vs export in linked list,
these two patches were separate previously, but seem to work better
like this.
v4: danvet is correct, this code is no longer useful, since the buffer
better exist, so remove it.
v5: always take a reference to the dma buf object, import or export.
(Imre Deak contributed this originally)
v6: square the circle, remove import vs export tracking now
that there is no difference
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>