Because, there is no reason for it not to be const.

v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
    by Ville Syrjälä
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.

So give it to them and roll it out in all drivers.

This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Acked-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Reviwed-by: NRob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The omapdrm driver currently uses a string comparison to find out if the
display is a DVI display. This is not reliable, and as we now have a
specific display type for DVI, let's use that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that omap_dss_output has been combined into omap_dss_device, we can
add ref counting for the relevant output functions also.

This patch adds omap_dss_get_device() calls to the various find_output()
style functions. This, of course, means that the users of those
find_output functions need to do a omap_dss_put_device() after use.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.

In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.

Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.

This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.

To support that kind of scenarios, we need to add new step to the
initialization: connect.

This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.

One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.

This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.

We cannot fix this the sane way, which would be to create crtcs for each
overlay manager, because we need an overlay for each crtc. With limited
number of overlays, that's not possible.

So the solution for now is to detach the overlay manager from the crtc.
crtcs are still created on demand at init time, but all overlay managers
are always initialized by the omapdss.

This way we can create and connect whole display pipelines from the
overlay manager to the display, regardless of which crtcs omapdrm would
create.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.

This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When booting with DT, there's a crash when omapfb is probed. This is
caused by the fact that omapdss+DT is not yet supported, and thus
omapdss is not probed at all. On the other hand, omapfb is always
probed. When omapfb tries to use omapdss, there's a NULL pointer
dereference crash. The same error should most likely happen with omapdrm
and omap_vout also.

To fix this, add an "initialized" state to omapdss. When omapdss has
been probed, it's marked as initialized. omapfb, omapdrm and omap_vout
check this state when they are probed to see that omapdss is actually
there.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Some static structs are not marked as static. Add it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can attach to a single
crtc.

Since the number of crtcs may be lesser than the number of hardware overlay
managers, we need to figure out which overlay managers to use for our crtcs. The
current approach is to use pipe2chan(), which returns a higher numbered manager
for the crtc.

The problem with this approach is that it assumes that the overlay managers we
choose will connect to the encoders the platform's panels are going to use,
this isn't true, an overlay manager connects only to a few outputs/encoders, and
choosing any overlay manager for our crtc might lead to a situation where the
encoder cannot connect to any of the crtcs we have chosen. For example, an
omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
connect to the hdmi encoder at all. The only manager that could have connected
to hdmi was the TV overlay manager.

Therefore, there is a need to choose our overlay managers keeping in mind the
panels we have on that platform. The new approach iterates through all the
available panels, creates encoders and connectors for them, and then tries to
get a suitable overlay manager to create a crtc which can connect to the
encoders.

We use the dispc_channel field in omap_dss_output to retrieve the desired
overlay manager's channel number, we then check whether the manager had already
been assigned to a crtc or not. If it was already assigned to a crtc, we assume
that out of all the encoders which intend use this crtc, only one will run at a
time. If the overlay manager wan't assigned to a crtc till then, we create a
new crtc and link it with the overlay manager.

This approach just looks for the best dispc_channel for each encoder. On DSS HW,
some encoders can connect to multiple overlay managers. Since we don't try
looking for alternate overlay managers, there is a greater possibility that 2
or more encoders end up asking for the same crtc, causing only one encoder to
run at a time.

Also, this approach isn't the most optimal one, it can do either good or bad
depending on the sequence in which the panels/outputs are parsed. The optimal
way would be some sort of back tracking approach, where we improve the set of
managers we use as we iterate through the list of panels/encoders. That's
something left for later.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.

The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of the future panels and encoders which
come after it, that isn't the correct thing to do, we should go through the rest
of the panels. Replace the 'return's with 'continue's.
Signed-off-by: NArchit Taneja <archit@ti.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm.  And in the mean time the PM sequencing and many
other of that open issues have been solved.  So I think it makes sense
to finally move omapdrm out of staging.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT.  We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.

On resume, the DMM resume handler will first reprogram the LUT to point
to the dummy page.  The subsequent resume handler in the omapdrm will call
into the DMM and reprogram each of the buffer objects.  This will ensure
that all of the necessary objects will be pinned into the DMM properly.

Order of suspend/resume handlers is done by device creation.  We create
the DMM device before the omapdrm, so the correct order is maintained.
Signed-off-by: NAndy Gross <andy.gross@ti.com>
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

alloc failures already get standardized OOM
messages and a dump_stack.

For the affected mallocs around these OOM messages:

Converted kzallocs with multiplies to kcalloc.
Converted kmallocs with multiplies to kmalloc_array.
Converted a kmalloc/strlen/strncpy to kstrdup.
Moved a spin_lock below a removed OOM message and
removed a now unnecessary spin_unlock.
Neatened alignment and whitespace.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I've left the locking in the debugfs code as-is, it's essentially just
used to keep the framebuffer object alive (which won't be necessary
any more later on). We don't need fb refcounting either, since the new
mode_config.fb_lock ensures that the framebuffers can't disappear
(once mode_config.mutex doesn't guarantee this any more later on in
the series).

The fbcon restore needs all modeset locks. The crtc callbacks seem to
only need the crtc locks, but I've quickly discussed things with Rob
Clark and he's fine with just using modeset_lock_all for those, too.
He'll look into converting things over later.
Reviewed-by: NRob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT.  We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.

On resume, the DMM resume handler will first reprogram the LUT to point
to the dummy page.  The subsequent resume handler in the omapdrm will call
into the DMM and reprogram each of the buffer objects.  This will ensure
that all of the necessary objects will be pinned into the DMM properly.

Order of suspend/resume handlers is done by device creation.  We create
the DMM device before the omapdrm, so the correct order is maintained.
Signed-off-by: NAndy Gross <andy.gross@ti.com>
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch changes the omapdrm KMS to bypass the omapdss "compat"
layer and use the core omapdss API directly.  This solves some layering
issues that would cause unpin confusion vs GO bit status, because we
would not know whether a particular pageflip or overlay update has hit
the screen or not.  Now instead we explicitly manage the GO bits in
dispc and handle the vblank/framedone interrupts ourself so that we
always know which buffers are being scanned out at any given time, and
so on.

As an added bonus, we no longer leave the last overlay buffer pinned
when the display is disabled, and have been able to add the previously
missing vblank event handling.

v1: original
v2: rebased on latest staging-next and omapdss patches from Tomi and
    review comments from Archit Taneja
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NArchit Taneja <archit@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

omapdss_compat_init() and omapdss_compat_uninit() is called internally
by omapdss. This patch moves the calls to omapfb, omap_vout and omapdrm
drivers. omapdrm driver can later remove the call after non-compat
support has been implemented in omapdrm.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The following warnings fixed.
- WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: NYAMANE Toshiaki <yamanetoshi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove usage of plat/cpu.h and get information from platform data
instead.  This enables omapdrm to be built with ARCH_MULTIPLATFORM.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Not actually used anymore.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For hardware that does not have DMM/TILER, there is no rotation,
so no point in getting userspace's hopes up.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the introduction of output entities, managers will now connect to outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager.

Using the helper function will reduce the number of pointer dereferences a user
of OMAPDSS needs to do and reduce risk of a NULL dereference.
Signed-off-by: NArchit Taneja <archit@ti.com>

This is an equivalent conversion and will ease scheduled removal of
WQ_NON_REENTRANT.

Only compile tested.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reclaim_buffers callback has already been removed by Daniel Vetter
<daniel.vetter@ffwll.ch> with his patch "drm: kill reclaim_buffers callback"
(b0071efe). As a result the kernel compilation fails with omapdrm support
and so the callback for reclaim_buffers is being removed from omapdrm.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NRob Clark <rob@ti.com>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Rob Clark <rob.clark@linaro.org>
Reviwed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The GEM vm operations structure is passed to the VM core that stores it
in a const field. There vm operations structures can thus be const in
DRM as well.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <rob.clark@linaro.org>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds support to re-import omapdrm's own buffers.  Importing buffers
allocated by other drivers can be added later, but for now is not needed
(we don't yet have any other exportering drivers to test with).
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For now just implementing the exporting APIs, not yet importing.  And
kmap is rejected on tiled buffers (although the usefulness of that seems
questionable, but could be added later if needed).
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Not sure what triggered the change in behavior, but seems to
result in recursively acquiring a mutex and hanging on boot.  But
omap_drm_init() seems a much more sane place to register the
driver for the DMM sub-device.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch splits the DMM off into a separate sub-device, in order to
utilize the platform device information that was created as part of
the OMAP hwmod entry for the DMM.

The driver probe function queries the iomem resource and IRQ using
standard platform_get functions.

The OMAP DRM driver now calls the platform_driver_register() function
for the subordinate DMM driver inside its probe function.  This
guarantees the required order for the DMM and ensures the DMM resources
are available for use by the DRM driver.
Signed-off-by: NAndy Gross <andy.gross@ti.com>
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add some additional debugfs file to aid in tracking buffer usage.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a workqueue for omapdrm driver, which is needed for at least a
couple things currently: (1) moving omap_gem_roll() to a non-atomic
context, (2) synchronizing page flips w/ DSS scanout related irq's
(in particular not unmapping previous buffer until DSS finishes
scanout).
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix minimum width/height so planes could be used to implement
hw mouse cursor.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane object
is used by the CRTC object.  This avoids code duplication between the
plane and CRTC.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Right now just a tiler_map file to dump a 2d map of which areas in
tiler/dmm have pinned buffers (or reservations).  In the future more
could be added.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

TILER/DMM provides two features for omapdrm GEM objects:
1) providing a physically contiguous view to discontiguous memory
   for hw initiators that cannot otherwise support discontiguous
   buffers (DSS scanout, IVAHD video decode/encode, etc)
2) providing untiling for 2d tiled buffers, which are used in some
   cases to provide rotation and reduce memory bandwidth for hw
   initiators that tend to access data in 2d block patterns.

For 2d tiled buffers, there are some additional complications when
it comes to userspace mmap'ings.  For non-tiled buffers, the original
(potentially physically discontiguous) pages are used to back the
mmap.  For tiled buffers, we need to mmap via the tiler/dmm region to
provide an unswizzled view of the buffer.  But (a) the buffer is not
necessarily pinned in TILER all the time (it can be unmapped when
there is no DMA access to the buffer), and (b) when they are they
are pinned, they not necessarily page aligned from the perspective of
the CPU.  And non-page aligned userspace buffer mapping is evil.

To solve this, we reserve one or more small regions in each of the 2d
containers when the driver is loaded to use as a "user-GART" where we
can create a second page-aligned mapping of parts of the buffer being
accessed from userspace.  Page faulting is used to evict and remap
different regions of whichever buffers are being accessed from user-
space.
Signed-off-by: NRob Clark <rob@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>