When msm_framebuffer_init() fails before calling drm_framebuffer_init(),
drm_framebuffer_cleanup() [called in msm_framebuffer_destroy()]
is still being called even though drm_framebuffer_init() was not
called for that buffer. Thus a NULL pointer derefencing:

[  247.529691] Unable to handle kernel NULL pointer dereference at virtual address 0000027c
...
[  247.563996] PC is at __mutex_lock_slowpath+0x94/0x3a8
...
[  247.823025] [<c07c3c78>] (__mutex_lock_slowpath) from [<c07c3fac>] (mutex_lock+0x20/0x3c)
[  247.831186] [<c07c3fac>] (mutex_lock) from [<c0347cf0>] (drm_framebuffer_cleanup+0x18/0x38)
[  247.839520] [<c0347cf0>] (drm_framebuffer_cleanup) from [<c036d138>] (msm_framebuffer_destroy+0x48/0x100)
[  247.849066] [<c036d138>] (msm_framebuffer_destroy) from [<c036d580>] (msm_framebuffer_init+0x1e8/0x228)
[  247.858439] [<c036d580>] (msm_framebuffer_init) from [<c036d630>] (msm_framebuffer_create+0x70/0x134)
[  247.867642] [<c036d630>] (msm_framebuffer_create) from [<c03493ec>] (internal_framebuffer_create+0x67c/0x7b4)
[  247.877537] [<c03493ec>] (internal_framebuffer_create) from [<c034ce34>] (drm_mode_addfb2+0x20/0x98)
[  247.886650] [<c034ce34>] (drm_mode_addfb2) from [<c034071c>] (drm_ioctl+0x240/0x420)
[  247.894378] [<c034071c>] (drm_ioctl) from [<c011df7c>] (do_vfs_ioctl+0x4e4/0x5a4)
...
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
[plus initialize msm_fb to NULL to -Rob]
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change adds the NV12 format support for public planes.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Fixes for a couple little issues found in testing.
Signed-off-by: NRob Clark <robdclark@gmail.com>

It's a problem that can't happen yet, since we don't support any
multi-planar formats yet.  But let's avoid nasty surprises when the
time comes.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Atomic wants to split the prepare/pin from where we actually program the
scanout address (so that any part that can fail is done synchronously).
Add some fb/gem apis to make this easier to use from the kms parts.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: NRob Clark <robdclark@gmail.com>