A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
CMA helpers.  Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape).  There are also various LCD
displays, for which support can be added (as I get hw to test on),
and an external i2c HDMI encoder found on some boards.

The display controller supports a single CRTC.  And the encoder+
connector are split out into sub-devices.  Depending on which LCD
or external encoder is actually present, the appropriate output
module(s) will be loaded.

v1: original
v2: fix fb refcnting and few other cleanups
v3: get +/- vsync/hsync from timings rather than panel-info, add
    option DT max-bandwidth field so driver doesn't attempt to
    pick a display mode with too high memory bandwidth, and other
    small cleanups
v4: remove some unneeded stuff from panel-info struct, properly
    set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NKoen Kooi <koen@dominion.thruhere.net>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Simplify life for drivers using an encoder-slave, so that they can make
their drm_encoder_helper_funcs const, rather than needing to dynamically
allocate and populate them.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Add helper to display fb's which can be used directly in drm_info_list:

static struct drm_info_list foo_debugfs_list[] = {
		...
		{ "fb",   drm_fb_cma_debugfs_show, 0 },
};

to display information about CMA fb objects, as well as a
drm_gem_cma_describe() which can be used if the driver bothers to keep
a list of CMA GEM objects.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Initialize e->pipe.. some drivers set this themselves, others do not.
Setting it in drm_send_vblank_event() should help ensure more consistent
behavior with the different drivers.
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.

Breakage introduced in

commit 6c2a7532
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Dec 11 00:59:24 2012 +0100

    drm: refcounting for sprite framebuffers
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rob Clark <rob@ti.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

/me grabs a few brown paper bags

So it looks like I've broken compilation in

commit 6aed8ec3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jan 20 17:32:21 2013 +0100

    drm: review locking for drm_fb_helper_restore_fbdev_mode

Fix it up again.
Reported-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.

I get it the first time that the entire block is all 0xff..
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [v3.7]
Signed-off-by: NDave Airlie <airlied@redhat.com>

On tile architecture (with "make allyesconfig") including
<linux/swiotlb.h> is required to call swiotlb_nr_tbl().
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Move drm_pcie_get_speed_cap_mask() under #ifdef CONFIG_PCI because it
it used only for PCI devices (evergreen, r600, r770), and it uses
PCI interfaces that only exist when CONFIG_PCI=y.

Previously, we tried to compile drm_pcie_get_speed_cap_mask() even when
CONFIG_PCI=n, which fails.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.

Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch
from Konstantin Khlebnikov. The callchain leading to this, cut&pasted
from Konstantin's original patch:

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)

Note that the entire locking in the fb helper around panic/sysrq and
kdbg is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like
the fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.

v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.

Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.

I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.

Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...

v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
  Dave Airlie didn't want me to kill this one from the fb helper
  interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
  from the driver's ->fb_probe callback to setup the fbdev info
  structure.
- Clarify what the ->fb_probe callback should all do - it needs to
  setup both the fbdev info and allocate the drm framebuffer used as
  backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
  vfunc.

v3: Implement clarifications Laurent Pinchart suggested in his review.

v4: Fix another mispelling Laurent spotted.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No need to check whether we've allocated a new fb since we're not
always doing that. Also, we always need to register the fbdev and add
it to the panic notifier.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The idea behind calling down into the driver's ->fb_probe function on each
hotplug seems to be able to reallocate the backing storage (if e.g. a screen
with higher resolution gets added). But that requires quite a bit of work in the
fb helper itself, since currently we limit new screens to the currently
allocated fb. An no kms driver supports fbdev fb resizing.

So don't bother and start to simplify the code by calling drm_fb_helper_set_par
directly from the fbdev hotplug function, since that's the only thing left in
drm_fb_helper_single_fb_probe which does not concern itself with fb allocation
and initial setup. Follow-on patches will streamline the initial setup
code.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
  screen).
- It unconditionally sets the fb, even if no mode will be set on a
  given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
  the desired fb size, but also should set the modeset->fb pointer.
  Explain what's going on in the fixup code after the fb is allocated.

The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.

Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.

v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
  through the real interface vfuncs, forcing i915 to fake all the
  ->disable callbacks used by the crtc helper to avoid ugly Oopsen

v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm_fbdev_cma_init does the inital fbcon setup by calling down into
drm_fb_helper_initial_config, so no need at all to restore the just
set up configuration right away ...
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It doesn't even show up in any header files and only used iternally.
Originally it was (ab)used to restore the fbcon on lastclose, but that
died with

commit e8e7a2b8
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Apr 21 22:18:32 2011 +0100

    drm/i915: restore only the mode of this driver on lastclose (v2)
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.

Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).

But that's both better done in separate patches.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... it's required. Fix up exynos and the cma helper, and add a
corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.

Note that tegra calls the fbdev cma helper restore function also from
it's driver-load callback. Which is a bit against current practice,
since usually the call is only from ->lastclose, and initial setup is
done by drm_fb_helper_initial_config.

Also add the relevant drm DocBook entry.

v2: Add promised WARN to restore_fbdev_mode.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 6f33814b.

The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It is a bit more precise to compute the total number of pixels first and
then divide, rather than multiplying the line pixel count by the
already-rounded line duration.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use PCI Express Capability access functions to simplify this code a bit.
For non-PCIe devices or pre-PCIe 3.0 devices that don't implement the Link
Capabilities 2 register, pcie_capability_read_dword() reads a zero.

Since we're only testing whether the bits we care about are set, there's no
need to mask out the other bits we *don't* care about.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For devices that conform to PCIe r3.0 and have a Link Capabilities 2
register, we test and report every bit in the Supported Link Speeds Vector
field.  For a device that supports both 2.5GT/s and 5.0GT/s, we set both
DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in the returned mask.

For pre-r3.0 devices, the Link Capabilities 0010b encoding
(PCI_EXP_LNKCAP_SLS_5_0GB) means that both 5.0GT/s and 2.5GT/s are
supported, so set both DRM_PCIE_SPEED_25 and DRM_PCIE_SPEED_50 in this
case as well.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the standard #defines rather than bare numbers for the PCIe Link
Capabilities speed bits.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Drivers that register interrupt handlers without the DRM core helpers
don't initialize the .irq_enabled field and drm_dev_to_irq() may fail
when called on them. This shouldn't preclude them from implementing
the vblank IOCTL.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Simplify the Radeon prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.

v2:
- Rename functions to radeon_gem_prime_get_sg_table and
  radeon_gem_prime_import_sg_table.
- Delete the now-unused vmapping_count variable.
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Simplify the Nouveau prime implementation by using the default behavior provided
by drm_gem_prime_import and drm_gem_prime_export.

v2: Rename functions to nouveau_gem_prime_get_sg_table and
nouveau_gem_prime_import_sg_table.
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:

  gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT
  gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for export
  gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
  gem_prime_vmap, gem_prime_vunmap: map and unmap an object

These hooks are optional; drivers can opt in by using drm_gem_prime_import and
drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of
struct drm_driver.

v2:
- Drop .begin_cpu_access.  None of the drivers this code replaces implemented
  it.  Having it here was a leftover from when I was trying to include i915 in
  this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
  did.  This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
  Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.

v3:
- Pass the vaddr down to the driver.  This lets drivers that just call vunmap on
  the pointer avoid having to store the pointer in their GEM private structures.
- Move documentation into a /** DOC */ comment in drm_prime.c and include it in
  drm.tmpl with a !P line.  I tried to use !F lines to include documentation of
  the individual functions from drmP.h, but the docproc / kernel-doc scripts
  barf on that file, so hopefully this is good enough for now.
- apply refcount fix from commit be8a42ae
  ("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: NAaron Plattner <aplattner@nvidia.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Move this out of nouveau directory.  As we start to add more encoder
slaves used by other drivers, it makes sense to put the Kconfig bits in
one place.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Okay so Alan's patch handled the case where there was no registered fbcon,
however the other path entered in set_con2fb_map pit.

In there we called fbcon_takeover, but we also took the console lock in a couple
of places. So push the console lock out to the callers of set_con2fb_map,

this means fbmem and switcheroo needed to take the lock around the fb notifier
entry points that lead to this.

This should fix the efifb regression seen by Maarten.
Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: NLu Hua <huax.lu@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There seems to be a bad interaction between gem/shmem and defio on top,
I get list corruption on the page lru in the shmem code.

Turn it off for now until we get some more digging done.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

As we use a variable length the compiler does not realise that it is a
fixed value of either 2 or 4 bytes. Instead of performing the inline
comparison itself, the compiler inserts a function call to the generic
memcmp routine which is optimised for long comparisons of variable
length. That turns out to be quite expensive...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Okay you don't really want to use udl devices as your console, but if
you are unlucky enough to do so, you run into a lot of schedule while atomic
due to printk being called from all sorts of funky places. So check if we
are in an atomic context, and queue the damage for later, the next printk
should cause it to appear. This isn't ideal, but it is simple, and seems to
work okay in my testing here.

(dirty area idea came from xenfb)

fixes a bunch of sleeping while atomic issues running fbcon on udl devices.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

While looking at plymouth on udl I noticed that plymouth was trying
to use its fb plugin not its drm one, it was trying to drmOpen a driver called
usb not udl, noticed that we actually had out driver pointing at the wrong
device.

Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only enable it when we disable the display rather than
at DPMS time since enabling it requires a full modeset
to restore the display state.  Fixes blank screens in
certain cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>