Add support for the A83T display pipeline.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/614b430adf3a67320362a75c01b01bd53013da8a.1513854122.git-series.maxime.ripard@free-electrons.com

The TCON supports the LVDS interface to output to a panel or a bridge.
Let's add support for it.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7fbb85f33ee1d5009fde4f0d7d236e11ca58b114.1513854122.git-series.maxime.ripard@free-electrons.com

The various outputs the TCON can provide have different constraints on the
dotclock divider. Let's make them configurable by the various mode_set
functions.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/92ff5881c8f8674056d34458b2f264cd48d4e136.1513854122.git-series.maxime.ripard@free-electrons.com

It seems like the mixer can only run properly when clocked at 150MHz. In
order to have something more robust than simply a fire-and-forget
assigned-clocks-rate, let's put that in the code.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f5f05307972ed05250e8094b302d68b9e7e167f6.1513854122.git-series.maxime.ripard@free-electrons.com

The A83T has two video pipelines in parallel that looks quite similar to
the other SoCs.

The video planes are handled through a controller called the mixer, and the
video signal is then passed to the timing controller (TCON).

And while there is two instances of the mixers and TCONs, they have a
significant number of differences. The TCONs are quite easy to deal with,
one is supposed to generate TV (in the broader term, so including things
like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
call them TCON-TV and TCON-LCD, which seems more appropriate.

However, the mixers differ mostly by their capabilities, with some features
being available only in the first one, or the number of planes they expose,
but also through their register layout. And while the capabilities could be
represented as properties, the register layout differences would need to
express all the registers offsets as properties, which is usually quite
bad. Especially since documentation on that hardware block is close to
non-existent and we don't even have the list of all those registers in the
first place.

So let's call them mixer 0 and 1 in our compatibles, even though the name
is pretty bad...

At the moment, we only have tested the code on a board that has a single
display output, so we're leaving the tcon-tv and mixer1 out.
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2702a5c1d224af1c51743492ad1b917966f2ad43.1513854122.git-series.maxime.ripard@free-electrons.com

Some clocks and resets supposed to drive the LVDS logic in the display
engine have been overlooked when the driver was first introduced.

Add those additional resources to the binding, and we'll deal with the ABI
stability in the code.
Reviewed-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ddbde28fe2e4f21412974e4c69fbfe1c5ff9383f.1513854122.git-series.maxime.ripard@free-electrons.com

This adds a new driver for Sitronix ST7735R display panels.

This has been tested using an Adafruit 1.8" TFT.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1514833336-22564-4-git-send-email-david@lechnology.com

This adds a new device tree binding for Sitronix ST7735R display panels,
such as the Adafruit 1.8" TFT.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1514833336-22564-3-git-send-email-david@lechnology.com

This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1514833336-22564-2-git-send-email-david@lechnology.com

This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".

The original bindings were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.

This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1513881187-3197-4-git-send-email-david@lechnology.com

This updates the compatible string for a no-name LCD panel to
"vot,v220hf01a-t", "ilitek,ili9225".

The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220"
because I could not find a datasheet. However, after some more research,
I finally found one, so the actual vendor and model name are now known.

This previous bindings have not made it to the mainline kernel yet, so
this is not breaking backwards compatibility.

This is also following the precedence of the ILI9322 bindings [2] by using
the pattern "vendor,specific-system-config", "vendor,ip-part";

[1]: https://patchwork.ozlabs.org/patch/839352/
[2]: https://patchwork.ozlabs.org/patch/843576/Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1513881187-3197-3-git-send-email-david@lechnology.com

This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd.
They make LCD displays.
Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1513881187-3197-2-git-send-email-david@lechnology.com

drm_panel_orientation_quirks.c introduced in commit 404d1a3e ("drm:
Add panel orientation quirks, v6.") taints the kernel when compiled as a
module. Fix this by adding MODULE_LICENSE().
Signed-off-by: NDavid Lechner <david@lechnology.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1513881979-13801-1-git-send-email-david@lechnology.com

This adds support for the Ilitek ILI9322 QVGA (320x240)
TFT panel driver.

This panel driver supports serial or parallel RGB or
YUV input and also ITU-T BT.656 input streams.

The controller is combined with a physical panel and
configured through the device tree.

Cc: David Lechner <david@lechnology.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171221234411.12156-1-linus.walleij@linaro.org

This adds device tree bindings for the Ilitek ILI9322
320x240 TFT panel driver.

Cc: David Lechner <david@lechnology.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: devicetree@vger.kernel.org
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171201161659.9588-1-linus.walleij@linaro.org

This is is very useful to finding sources of leaked framebufers.
The fbcon fb is annotated with [fbcon], to give it a better name
than kworker.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220093545.613-3-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add helper for initializing fbdev deferred I/O.

The cleanup could have happened in drm_fb_helper_fini(), but that would
have required me to set fb_info->fbdefio to NULL in a couple of drivers
before they call _fini() to avoid double defio cleanup. The problem is
that one of those is vboxvideo which lives in Greg's staging tree.
So I put the cleanup in drm_fb_helper_fbdev_teardown(), not perfect
but not that bad either.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-6-noralf@tronnes.org

Promote new helpers for dealing with fbdev emulation.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-5-noralf@tronnes.org

Add entry for conversion of drivers to new helpers.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-4-noralf@tronnes.org

Add helpers to setup and teardown fbdev emulation.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-3-noralf@tronnes.org

Set dev->fb_helper even when fbdev emulation is compiled out,
so drivers can use it to free the structure.
Clear it for consistency.

Fixes: 29ad20b2 ("drm: Add drm_device->fb_helper pointer")
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171215175119.36181-2-noralf@tronnes.org

devm_ioremap_resource() already checks if the resource is NULL, so
remove the unnecessary platform_get_resource() error check.

Cc: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-6-git-send-email-festevam@gmail.com

devm_ioremap_resource() already checks if the resource is NULL, so
remove the unnecessary platform_get_resource() error check.

Cc: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-5-git-send-email-festevam@gmail.com

We don't want people to accidentally stumble over there.

Also rename the plane helpers to legacy plane helpers. After Ville's
patch to make the clipping helper atomic and move it to
drm_atomic_helper.c there's nothing left in there that should be
useful for modern drivers.

v2: Laurent had a few questions around how state is added to
drm_atomic_state, tried to clarify that. And spotted another sentence
where the docs suggested subclassing.

v3: Small polish (Alex).
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-6-daniel.vetter@ffwll.ch

DK put some nice docs into the commit introducing driver private
state, but in the git history alone it'll be lost.

Also, since Ville remove the void* usage it's a good opportunity to
give the driver private stuff some tlc on the doc front.

Finally try to explain why the "let's just subclass drm_atomic_state"
approach wasn't the greatest, and annotate all those functions as
deprecated in favour of more standardized driver private states. Also
note where we could/should extend driver private states going forward
(atm neither locking nor synchronization is handled in core/helpers,
which isn't really all that great).

v2: Spelling and phrasing improvements (Alex, DK).

Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-5-daniel.vetter@ffwll.ch

Complete a few missing bits, fix up the existing xcross-references and
add a bunch more.

v2: Fix typos (Alex).

Cc: Dave Airlie <airlied@gmail.com> via lists.freedesktop.org
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-4-daniel.vetter@ffwll.ch

It thinks we want to document the __printf(2,0) annotion. Not sure we
want to teach it about all possible gcc-only flags, hence why I opted
for the cheap trick of just moving it ahead of the kerneldoc.

This is only a problem for static inline functions, since for
non-inline function the kerneldoc is in the .c file, but the special
annotations are all in the header.

Cc'ing kernel-doc maintainers as fyi.

Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-3-daniel.vetter@ffwll.ch

Also some breadcrumbs for how exactly to find this. Probably should
pass drm_connector * or at least drm_display_info * to that function
instead. But drm_hdmi_avi_infoframe_quant_range probably also wants
drm_connector_state (and the hdmi stuff moved into that), so this is a
bit more work.

v2: Fix typo (Alex).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 9271c0ca ("drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks")
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171214203054.20141-2-daniel.vetter@ffwll.ch

kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it doesn't
actually do that anymore since commit 38d868e4 ("drm: Don't force
all planes to be added to the state due to zpos"). Instead, drivers are
supposed to explicitly call the drm_atomic_normalize_zpos() function.
Change the kerneldoc comment to reflect that.

v2: reference the commit that introduced the kerneldoc unclarity
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120150959.26913-1-thierry.reding@gmail.com

There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never reset when EDID was not, as happened when the
display was disconnected.

One of these fields, non_desktop, is used from
drm_mode_connector_update_edid_property, the function responsible for
assigning the new edid value to the application-visible property.

Various drivers call these two functions (drm_add_edid_modes and
drm_mode_connector_update_edid_property) in different orders. This
means that even when EDID is present, the drm_display_info fields may
not have been computed at the time that
drm_mode_connector_update_edid_property used the non_desktop value to
set the non_desktop property.

I've added a public function (drm_reset_display_info) that resets the
drm_display_info field values to default values and then made the
drm_add_display_info function public. These two functions are now
called directly from drm_mode_connector_update_edid_property so that
the drm_display_info fields are always computed from the current EDID
information before being used in that function.

This means that the drm_display_info values are often computed twice,
once when the EDID property it set and a second time when EDID is used
to compute modes for the device. The alternative would be to uniformly
ensure that the values were computed once before being used, which
would require that all drivers reliably invoke the two paths in the
same order. The computation is inexpensive enough that it seems more
maintainable in the long term to simply compute them in both paths.

The API to drm_add_display_info has been changed so that it no longer
takes the set of edid-based quirks as a parameter. Rather, it now
computes those quirks itself and returns them for further use by
drm_add_edid_modes.

This patch also includes a number of 'const' additions caused by
drm_mode_connector_update_edid_property taking a 'const struct edid *'
parameter and wanting to pass that along to drm_add_display_info.

v2: after review by Daniel Vetter <daniel.vetter@ffwll.ch>

	Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
	drm_add_display_info.

	Added FIXME in drm_mode_connector_update_edid_property about
	potentially merging that with drm_add_edid_modes to avoid
	the need for two driver calls.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171213084427.31199-1-keithp@keithp.com

I'm juggling too many things, and drm-misc maintenance is one that I
keep dropping on the floor. Admit reality and remove myself as
maintainer. This still leaves us with a nice team of three who are
actually doing the drm-misc work, while I focus on drm-intel.

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Relunctantly-Acked-By: NSean Paul <seanpaul@chromium.org>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123121308.12818-1-jani.nikula@intel.com

Use drm_fb_cma_fbdev_init_with_funcs() and drm_fb_cma_fbdev_fini() which
relies on the fact that drm_device holds a pointer to the drm_fb_helper
structure. This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove todo entry.

Cc: David Lechner <david@lechnology.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NDavid Lechner <david@lechnology.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NDavid Lechner <david@lechnolgy.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171208193743.34450-11-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-20-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NShawn Guo <shawnguo@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-19-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-18-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-17-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NJyri Sarha <jsarha@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-16-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-15-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.
Remove duplicate ldev assignment.

Cc: Yannick Fertre <yannick.fertre@st.com>
Cc: Philippe Cornu <philippe.cornu@st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-14-noralf@tronnes.org

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Acked-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115142001.45358-13-noralf@tronnes.org