A small helper to queue up work to do, from workqueue context, after a
flip.  Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.

v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This function is unused.
Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.

So I don't see any use for this stat gathering complexity at all.

To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.

To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.

I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to

commit b018fcda
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Nov 22 18:46:54 2007 +1000

    drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx

there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.

So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.

Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.

v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.

This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.

Cc: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.

I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

No driver ever sets that flag, so good riddance!
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.

First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...

Then I wondered how this ever works, and what that strange "No-op."
comment right above it should mean. After all calling the core fasync
helper is pretty obviously not a noop. After reading through the
kernels FASYNC implementation I've noticed that signals are only sent
out to the processes attached with FASYNC by calling kill_fasync.

No merged drm driver has ever done that.

After more digging I've found out that the only driver that ever used
this is the so called GAMMA driver. I've frankly never heard of such a
gpu brand ever before. Now FASYNC seems to not have been the only bad
thing with that driver, since Dave Airlie removed it from the drm
driver with prejudice:

commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
Author: Dave Airlie <airlied@linux.ie>
Date:   Sun Aug 29 12:04:35 2004 +0000

    Drop GAMMA DRM from a great height ...

Long story short, the drm fasync support seems to be doing absolutely
nothing. And the only user of it was never merged into the upstream
kernel. And we don't need any fops->fasync callback since the fcntl
implementation in the kernel already implements the noop case
correctly.

So stop this particular cargo-cult and rip it all out.

v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
(somehow I've missed that one in staging). Also drop the reference in
the drm DocBook. ARM compile-fail reported by Rob Clark.

v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
patch here.

v4: Actually git add ... tsk.

Cc: Dave Airlie <airlied@linux.ie>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It's kzalloced ...
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).

Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.

So we can safely disallow these pair of ioctls for modesetting
drivers.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Again, it does nothing.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This field is never read. No need to set it in radeon. Besides, DRM gem
core clears it during setup, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

gem_bo->driver_private is never read by cirrus nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

gem_bo->driver_private is never read by mgag200 nor DRM core. No need to
set it. Besides, drm core clears it during setup, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

gem_bo->driver_private is never read by ast nor DRM core. No need to set
it. Besides, drm core clears it during setup, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a fixup function that will flip the hsync priority and
add a hskew value that is used to shift the tda998x to the
right by a variable number of pixels depending on the mode.
This works around an issue with the sync timings that tilcdc
is outputing.
Signed-off-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some LCD controller cannot provide valid VESA style sync, i.e. coincident
HS/VS edges. First, this patch adds hskew passed from the adjusted_mode to
reference pixel calculation to allow those controllers to add an offset
relative to the expected reference pixel.
Signed-off-by: NDarren Etheridge <detheridge@ti.com>
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes the wrong sync generation and sync calculation of TDA998x
for HS/VS-based sync detection.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The video-input-port (VIP) is highly configurable. This prepares
current driver to allow to configure VIP configuration, as some
boards connect lcd controller and TDA998x "pin-swapped" and depend
on VIP to swap the pins by register configuration.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The npix/nline registers are supposed to be programmed with the total
number of pixels/lines, not the displayed pixels/lines, and not minus
one either.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When switching between various drivers for this device, it's possible
that some critical registers are left containing values which affect
the device operation.  One such case encountered is the VIP output
mux register.  This defaults to 0x24 on powerup, but other drivers may
set this to 0x12.  This results in incorrect colours.

Fix this by ensuring that the register is always set to the power on
default setting.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TDA19988 devices need their RAM enabled in order to read EDID
information.  Add support for this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NRob Clark <robdclark@gmail.com>
Tested-by: NDarren Etheridge <detheridge@ti.com>
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Tested-by: NRussell King <rmk_kernel@arm.linux.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If NO_DMA=y:

drivers/built-in.o: In function `__drm_pci_free':
drivers/gpu/drm/drm_pci.c:112: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `drm_pci_alloc':
drivers/gpu/drm/drm_pci.c:72: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `drm_gem_unmap_dma_buf':
drivers/gpu/drm/drm_prime.c:87: undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `drm_gem_map_dma_buf':
drivers/gpu/drm/drm_prime.c:78: undefined reference to `dma_map_sg'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the FB CMA helpers to implement FBDEV emulation support. The VGA
connector status must be reported as connector_status_connected instead
of connector_status_unknown to be usable by the emulation layer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 includes two internal LVDS encoders. Support them in the DU
driver.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU variant has a single RGB output called DPAD0 that can be
fed with the output of DU0, DU1 or DU2. Making the routing configurable.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Split the output routing specification between SoC-internal data,
specified in the rcar_du_device_info structure, and board data, passed
through platform data.

The DU has 5 possible outputs (DPAD0/1, LVDS0/1, TCON). SoC-internal
output routing data specify which output are valid, which CRTCs can be
connected to the valid outputs, and the type of in-SoC encoder for the
output.

Platform data then specifies external encoders and the output they are
connected to.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU has a new extended function control register. Support it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU has 3 CRTCs, split in two groups. Support them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The R8A7790 DU seems to require a 128 bytes pitch alignment, even though
the documentation only mentions a 16 pixels alignement as for the
R8A7779 DU. Make this configurable through a device flag.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

The DU revision in the R8A7790 SoC uses one IRQ and clock per CRTC. Add
a corresponding entry in the module platform ID table.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>