WIP: drm: sync to drm-next (7963e9db)

commit 7963e9db1b1f842fdc53309baa8714d38e9f5681
Author:     Dave Airlie <airlied@gmail.com>
AuthorDate: Fri Aug 8 07:30:53 2014 +1000
Commit:     Dave Airlie <airlied@gmail.com>
CommitDate: Fri Aug 8 07:30:53 2014 +1000

    Revert "drm: drop redundant drm_file->is_master"

    This reverts commit 48ba813701eb14b3008edefef4a0789b328e278c.

    Thanks to Chris:
    "drm_file->is_master is not synomous with having drm_file->master ==
    drm_file->minor->master. This is because drm_file->master is the same
    for all drm_files of the same generation and so when there is a master,
    every drm_file believes itself to be the master. Confusion ensues and
    things go pear shaped when one file is closed and there is no master
    anymore."

    Conflicts:
        drivers/gpu/drm/drm_drv.c
        drivers/gpu/drm/drm_stub.c
WIP: backport-revert
DOWNSTREAM: drm/msm: use downstream iommu
DOWNSTREAM: un-CCF-ify hdmi pll
DOWNSTREAM: remove mdp axi clk

On downstream kernel, axi clk is hidden behind the scenes.
drm: idiot-proof vblank

After spending slightly more time than I'd care to admit debugging the
various and presumably spectacular way things fail when you pass too low
a value to drm_vblank_init() (thanks console-lock for not letting me see
the carnage!), I decided it might be a good idea to add some sanity
checking.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: avoid flood of kernel logs on faults

87e956e9 changed the fault handler to return -ENOSYS, which causes the
iommu driver to print out a huge splat.  Which wouldn't be quite so bad
if nothing ever faulted.  But seems like some EXA composite operations
generate quite a lot of (seemingly harmless) faults.  That is probably a
userspace problem, but the huge increase in verbosity from iommu fault
dumps makes things kind of unusable.

We probably should actually log *some* message (not conditional on
drm.debug).  But ratelimit it.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm/mdp4: request vblank during modeset

This avoids a problem seen with weston (for example) where the display
gets stuck in "black screen" if starting weston first thing after boot.
Possibly mdp5 needs something similar.  The downstream android fbdev
driver always requests DMA_E (or DMA_P) when display is active, rather
than only enabling it on-demand as the drm driver does, which I believe
has the same end result.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: fix compile error for non-dt builds

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: update generated headers

In particular, pick up the definitions for a handful of LVDS related
registers.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm/mdp4: fix blend setup with multiple crtcs

In particular, blend_setup() should not overwrite the other crtc's mixer
settings.  Also, the encoder needs to be able to specify the mixer-id
explicitly, since both LVDS and DTV use 'INTF_LVDC_DTV', so we cannot
guess the mixer-id from the interface.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm/mdp4: add LVDS panel support

LVDS panel support uses the LCDC (parallel) encoder.  Unlike with HDMI,
there is not a separate LVDS block, so no need to split things into a
bridge+connector.  Nor is there is anything re-used with mdp5.

Note that there can be some regulators shared between HDMI and LVDS (in
particular, on apq8064, ext_3v3p), so we should not use the _exclusive()
variants of devm_regulator_get().

The drm_panel framework is used for panel-specific driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
DOWNSTREAM: un-CCF-ify lvds pll
drm/panel/simple: add optronics B101XTN01.0 (v3)

LVDS panel, make/model described as:

AU Optronics Corporation - B101XTN01.0 (H/W:0A)

See:
http://www.encore-electronic.com/media/B101XTN01.0.pdf

Tested with panel attached to an Inforce IFC6410 board.

Signed-off-by: Rob Clark <robdclark@gmail.com>
DOWNSTREAM: hack to use simple-panel without DT

A bit ugly, but some things cannot be done so easily without devicetree.
mach-msm/8064: give LVDS regulators to drm/msm

We don't have the fake 'lvds.0' device like msm fbdev, we need the
regulators assigned to the actual display device.
mach-msm/8064: bus-scale tables for lvds

Just use the same tables we use for dtv/hdmi.. might be overkill, but
otoh it should be enough for 1920x1080 lvds panel.
mach-msm/8064: add gpios needed for lvds panel