Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/eb914313f9d0e58d81572ccd3c718a573a891bd7.1516810726.git.meghana.madhyastha@gmail.com

Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/140d01afb138d687680b2d1776a4c101c9fa9a0a.1516810725.git.meghana.madhyastha@gmail.com

Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/30d5b26c3c7d75de3d2ab3cff9dee67084fc3caf.1516810725.git.meghana.madhyastha@gmail.com

Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/bc80cdb5cf1a6638dce9fb9f8da674e361e3b749.1516810725.git.meghana.madhyastha@gmail.com

Call devm_of_find_backlight (the devres version) instead of
of_find_backlight.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/244cd4d567cb3944a8cb7633715ffc8ac4e1ce83.1516810725.git.meghana.madhyastha@gmail.com

Remove tinydrm_of_find_backlight from tinydrm-helpers.c. We now have
a generic of_find_backlight defined in backlight.c. Let the callers
of tinydrm_of_find_backlight call of_find_backlight. Also, remove
select BACKLIGHT_LCD_SUPPORT and select BACKLIGHT_CLASS_DEVICE from
tinydrm/Kconfig as it is a hack that is no longer needed.
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/11dd1cabd098a730d07ab04c5987b139d14d8b21.1516810725.git.meghana.madhyastha@gmail.com

Remove tinydrm_enable/disable_backlight and let the callers call the
more generic backlight_enable/disable helpers
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMeghana Madhyastha <meghana.madhyastha@gmail.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/ec700724e47814e6426966e093bd32b2364ba147.1516810725.git.meghana.madhyastha@gmail.com

Quoting the module option format looks soo much nicer, and avoids
sphinx spewing errors about markup issues.

v2: Fix typo in commit message (Thierry).
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-4-daniel.vetter@ffwll.ch

Move it out of the csv dungeon.

While at it add the missing link to the helper functions for setting
up the "panel rotation" property.

Also OCD how we list enum property values and their corresponding docs.
Going for a nest definition list seams cleanest, no need for also making
it an uordered list.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-3-daniel.vetter@ffwll.ch

Just a bit of drive-by OCD. All the other property docs use enumerations,
for some nice visual consistency. It also neatly highlights the property
name.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180219225356.24996-2-daniel.vetter@ffwll.ch

The PL111 needs to filter valid modes based on memory bandwidth.
I guess it is a pretty simple operation, so we can still claim
the DRM KMS helper pipeline is simple after adding this (optional)
vtable callback.
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180220072859.3386-1-linus.walleij@linaro.org

Use the new idr_init_base() function to create an IDR that knows id==0
is never allocated as it maps to an invalid identifier. By knowing that
id==0 is invalid, the IDR can start from id=1 instead avoiding the issue
of having to start each lookup from the zeroth leaf as id==0 is always
unused (and thus the tree-of-bitmaps indicate that is the first
available).

References: 6ce711f2 ("idr: Make 1-based IDRs more efficient")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christian Konig <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Christian König <christian.koenig@amd.com> as well.
Link: https://patchwork.freedesktop.org/patch/msgid/20180212145533.30046-1-chris@chris-wilson.co.uk

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL.  A check for this added right after
the call to drm_cvt_mode() in this particular area of code.
Signed-off-by: NJoe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: NSteven Sistare <steven.sistare@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-4-joe.moriarty@oracle.com

The Parfait (version 2.1.0) static code analysis tool found the
following NULL pointer derefernce problem.

- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.
Signed-off-by: NJoe Moriarty <joe.moriarty@oracle.com>
Reviewed-by: NSteven Sistare <steven.sistare@oracle.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180212195144.98323-3-joe.moriarty@oracle.com

drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 'obj'
drivers/dma-buf/sw_sync.c:248: warning: No description found for parameter 'value'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'parent' description in 'sync_pt_create'
drivers/dma-buf/sw_sync.c:248: warning: Excess function parameter 'inc' description in 'sync_pt_create'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208113816.8288-1-chris@chris-wilson.co.uk

drivers/gpu/drm/drm_lease.c:56: warning: No description found for parameter 'lessee_id'
drivers/gpu/drm/drm_lease.c:56: warning: Excess function parameter 'id' description in '_drm_find_lessee'
drivers/gpu/drm/drm_lease.c:114: warning: No description found for parameter 'file_priv'
drivers/gpu/drm/drm_lease.c:114: warning: Excess function parameter 'master' description in '_drm_lease_held'
drivers/gpu/drm/drm_lease.c:134: warning: No description found for parameter 'file_priv'
drivers/gpu/drm/drm_lease.c:134: warning: Excess function parameter 'master' description in 'drm_lease_held'
drivers/gpu/drm/drm_lease.c:158: warning: No description found for parameter 'crtcs_in'
drivers/gpu/drm/drm_lease.c:158: warning: Excess function parameter 'crtcs' description in 'drm_lease_filter_crtcs'
drivers/gpu/drm/drm_lease.c:311: warning: No description found for parameter 'top'
drivers/gpu/drm/drm_lease.c:311: warning: Excess function parameter 'master' description in '_drm_lease_revoke'
drivers/gpu/drm/drm_lease.c:494: warning: No description found for parameter 'lessor_priv'
drivers/gpu/drm/drm_lease.c:494: warning: Excess function parameter 'file_priv' description in 'drm_mode_create_lease_ioctl'
drivers/gpu/drm/drm_lease.c:672: warning: No description found for parameter 'lessee_priv'
drivers/gpu/drm/drm_lease.c:672: warning: Excess function parameter 'file_priv' description in 'drm_mode_get_lease_ioctl'
drivers/gpu/drm/drm_lease.c:733: warning: No description found for parameter 'lessor_priv'
drivers/gpu/drm/drm_lease.c:733: warning: Excess function parameter 'file_priv' description in 'drm_mode_revoke_lease_ioctl'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208110817.30057-1-chris@chris-wilson.co.uk

The structure bochs_bo_driver is local to the source and does not need to
be in global scope, so make it static.

Cleans up sparse warning:
drivers/gpu/drm/bochs/bochs_mm.c:197:22: warning: symbol 'bochs_bo_driver'
was not declared. Should it be static?
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180207111353.30261-1-colin.king@canonical.com

When mapping external DMA-bufs through the PRIME mmap call, we might be
given an offset which has to be respected. However for the internal DRM
GEM mmap path, we have to ignore the fake mmap offset used to identify
the buffer only. Currently the code always zeroes out vma->vm_pgoff,
which breaks the former.

This patch fixes the problem by moving the vm_pgoff assignment to a
function that is used only for GEM mmap path, so that the PRIME path
retains the original offset.

Cc: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NØrjan Eide <orjan.eide@arm.com>
Signed-off-by: NTomasz Figa <tfiga@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com

The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).
Signed-off-by: NHaixia Shi <hshi@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-3-thierry.escande@collabora.com

This patch removes unused fields from vop structure.
Signed-off-by: NTomasz Figa <tfiga@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Escande <thierry.escande@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-2-thierry.escande@collabora.com

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

Cc: Heiko Stübner <heiko@sntech.de>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-4-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: Heiko Stübner <heiko@sntech.de>
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1513602150-7542-3-git-send-email-festevam@gmail.com

Differently from other Lcd signals, HSYNC and VSYNC signals
result inverted if their bits are cleared to 0.

Invert their settings of IO_POL register.
Signed-off-by: NGiulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1518717288-123578-1-git-send-email-giulio.benetti@micronovasrl.com

Commit eea034af ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
broke the build with one build error and one warning. Fix both.

Cc: Archit Taneja <architt@codeaurora.org>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fixes: eea034af ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180216154412.22876-1-maxime.ripard@bootlin.com

A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.

Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-11-jernej.skrabec@siol.net

It supports 1 VI and 1 UI plane and HW scaling on both planes.
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-10-jernej.skrabec@siol.net

This TCON is connected to HDMI encoder.
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-9-jernej.skrabec@siol.net

Some TCONs on newer SoCs doesn't support channel 0, since they are meant
to be used only with TV or HDMI encoder.

Prepare support for them with adding has_channel_0 quirk.
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-8-jernej.skrabec@siol.net

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd ("drm/bridge/synopsys: stop clobbering drvdata")

Cc: p.zabel@pengutronix.de
Cc: Laurent.pinchart@ideasonboard.com
Cc: hjc@rock-chips.com
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-6-jernej.skrabec@siol.net

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-5-jernej.skrabec@siol.net

Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

Tests show that one iteration is enough.
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214200906.31509-4-jernej.skrabec@siol.net

After the recent corrections to the R-Car gen2/3 LVDS startup code, already
similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
a merge and it's becoming actually necessary with the addition of the R-Car
V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Set the LVDS mode and input before turning channels on]
[Rebased, coding style changes]
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

According to the latest revisions of the R-Car Gen3 manual, the LVDS mode
must be set before the LVDS I/O pins are enabled, not after -- fix the
Gen3 LVDS startup sequence accordingly.

Fixes: e947eccb ("drm: rcar-du: Add support for LVDS mode selection")
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Updated comment in rcar_du_lvdsenc_start_gen3()]
[Moved Gen2 startup comment update to separate commit]
[Fixed =| typo]
Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

According to the latest revision 2.00 of the R-Car Gen2 manual, the LVDS
and the bias circuit must be enabled after the LVDS I/O pins are
enabled, not before. Fix the Gen2 LVDS startup sequence accordingly.

While at it, also fix the comment preceding the first LVDCR0 write that
still talks about hardcoding the LVDS mode 0.

Fixes: 90374b5c ("drm/rcar-du: Add internal LVDS encoder support")
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

According to the latest versions of both the Gen2 and Gen3 datasheets,
the operating range for the LVDS clock is 31 MHz to 148.5 MHz on all
SoCs. Update the driver accordingly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>

The LVDCR1 register for the R-Car gen3 SoCs was documented as having the
layout different from the gen2 SoCs in  the early R-Car gen3 manuals but
since v0.52 the LVDCR1 layout is described as being the same as on the gen2
SoCs; the old CHn control values are said to be prohibited now (and there
seems to be no valid output signal when they are used).

Fixes: 6bc2e15c ("drm: rcar-du: lvds: Add R-Car Gen3 support")
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

On Gen3 hardware the VSP compositor is required for display. Enable it
by default in the kernel configuration. The option is kept
user-configurable for testing purpose on Gen2 platforms.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>

In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be large impact.
Thus, selecting Hi VCO is general theory.

   fin                                 fvco        fout      fclkout
in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
             +-> |  |                             |
             |                                    |
             +-----------------[1/N]<-------------+

	fclkout = fvco / P / FDPLL -- (1)

In PD, it will loop until fin/M = fvco/P/N

	fvco = fin * P *  N / M -- (2)

(1) + (2) indicates

	fclkout = fin * N / M / FDPLL

In this device, N = (n + 1), M = (m + 1), P = 2, FDPLL = (fdpll + 1).

	fclkout = fin * (n + 1) / (m + 1) / (fdpll + 1)

This is the datasheet formula.
One note here is that it should be 2kHz < fvco < 4096MHz
To be smaller jitter, fvco should be maximum,
in other words, N as large as possible, M as small as possible driver
should select. Here, basically M=1.
This patch do it.
Reported-by: NHIROSHI INOSE <hiroshi.inose.rb@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Small clarifications in comments, renamed finnm to fout]
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

It is difficult to understand its scale if number has many 0s.
This patch uses "* 1000" to avoid it in rcar_du_dpll_divider().
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Since commit 2fc4d838 ("drm: rcar: use generic code for managing
zpos plane property") the rcar-du driver stores the plane zpos in the
drm_plane_state structure. The commit however forgot to remove the zpos
field from the rcar_du_vsp_plane_state structure. Remove it.

Fixes: 2fc4d838 ("drm: rcar: use generic code for managing zpos plane property")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>