In order to prevent timeouts and stalls in the pipeline, the core clock
needs to be maxed at 500MHz during a modeset on the BCM2711.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/37ed9e0124c5cce005ddc8dafe821d8b0da036ff.1599120059.git-series.maxime@cerno.tech

The HVS found in the BCM2711 is slightly different from the previous
generations.

Most notably, the display list layout changes a bit, the LBM doesn't have
the same size and the formats ordering for some formats is swapped.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1d02fab3b916d639c2dc05608c117bbd8230ebe8.1599120059.git-series.maxime@cerno.tech

The HVS found in the BCM2711 is slightly different from the previous
generations, let's add a compatible for it.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/a6b4c9ee03bc8f950adc6c493db70cd540c2f902.1599120059.git-series.maxime@cerno.tech

Add support for the video pattern generator (VPG) BER pattern mode and
configuration in runtime.

This enables using the debugfs interface to manipulate the VPG after
the pipeline is set.
Also, enables the usage of the VPG BER pattern.

Changes in v2:
  - Added VID_MODE_VPG_MODE
  - Solved incompatible return type on __get and __set

Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Adrian Pop <pop.adrian61@gmail.com>
Signed-off-by: Angelo Ribeiro <angelo.ribeiro@synopsys.com>
Tested-by: Yannick Fertre <yannick.fertre@st.com>
Tested-by: Adrian Pop <pop.adrian61@gmail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Cc: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a809feb7d7153a92e323416f744f1565e995da01.1586180592.git.angelo.ribeiro@synopsys.com

Current code enables the HS clock when video mode is started or to
send out a HS command, and disables the HS clock to send out a LP
command. This is not what DSI spec specify.

Enable HS clock either in command and in video mode.
Set automatic HS clock management for panels and devices that
support non-continuous HS clock.

Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Tested-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Philippe Cornu <philippe.cornu@st.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200701194234.18123-1-yannick.fertre@st.com

Current code does not properly computes the max length of LP
commands that can be send during H or V sync, and rely on static
values.
Limiting the max LP length to 4 byte during the V-sync is overly
conservative.

Relax the limit and allows longer LP commands (16 bytes) to be
sent during V-sync.

Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Tested-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Philippe Cornu <philippe.cornu@st.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200701143131.841-1-yannick.fertre@st.com

Current code only sends LP commands in command mode.

Allows sending LP commands also in video mode by setting the
proper flag in DSI_VID_MODE_CFG.

Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Tested-by: Philippe Cornu <philippe.cornu@st.com>
Reviewed-by: Philippe Cornu <philippe.cornu@st.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708140836.32418-1-yannick.fertre@st.com

Make sure we can use this on mixed systems.

Signed-off-by: Kristian H. Kristensen <hoegsberg@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200903181652.432067-1-hoegsberg@google.com


Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

Ooops the panel drivers stopped to use DRM_DEV* messages
and we predictably create errors by merging code that
still use it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: David Airlie <airlied@linux.ie>
Link: https://patchwork.freedesktop.org/patch/msgid/20200906132903.5739-1-linus.walleij@linaro.org

The upstream S6E63M0 driver has some peculiarities around
the prepare/enable disable/unprepare sequence: the screen
is taken out of sleep in prepare() as part of
s6e63m0_init() the put to on with MIPI_DCS_SET_DISPLAY_ON
in enable().

However it is just put into sleep mode directly in
disable(). As disable()/enable() can be called without
unprepare()/prepare() being called, this is unbalanced,
we should take the display out of sleep in enable()
then turn it off().

Further MIPI_DCS_SET_DISPLAY_OFF is never called
balanced with MIPI_DCS_SET_DISPLAY_ON.

The vendor driver for Samsung GT-I8190 (Golden) does all
of these things in strict order.

Augment the driver to do exit sleep/set display on in
enable() and set display off/enter sleep in disable().

Further send an explicit reset pulse in power_on() so we
come up in a known state, and issue the MCS_ERROR_CHECK
command after setting display on like the vendor driver
does. Also use the timings from the vendor driver in
the sequence.

Doing all of these things makes the display much more
stable on the Samsung GT-I8190 when enabling/disabling
the display pipeline.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Stephan Gerhold <stephan@gerhold.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200817213906.88207-1-linus.walleij@linaro.org

We add code to identify a few different panels mounted
on the s6e63m0 controller. This is necessary to achieve
the proper biasing with DSI versions of the panel.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-5-linus.walleij@linaro.org

This adds code to send read commands to read a single
byte from the display, in order to perform MTP ID
look-up of the mounted panel on the s6e63m0 controller.
This is needed for proper biasing on the DSI variants.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-4-linus.walleij@linaro.org

This makes it possible to use the s6e63m0 panel with a
DSI host, such as in the Samsung GT-I8190 (Golden) mobile
phone.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Stephan Gerhold <stephan@gerhold.net>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20200809215104.1830206-3-linus.walleij@linaro.org

This panel can be accessed using both SPI and DSI.

To make it possible to probe and use the device also from
a DSI bus, first break out the SPI support to its own file.

Since all the panel driver does is write DCS commands to
the panel, we pass a DCS write function to probe()
from each subdriver.

We make the Kconfig entry for SPI mode default so all
current users will continue to work.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Acked-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/384873/

Following functions are only used internally, not by drivers:
- devm_drm_dev_init

Also, now that we have a very slick and polished way to allocate a
drm_device with devm_drm_dev_alloc, update all the docs to reflect the
new reality. Mostly this consists of deleting old and misleading
hints. Two main ones:

- it is no longer required that the drm_device base class is first in
  the structure. devm_drm_dev_alloc can cope with it being anywhere

- obviously embedded now strongly recommends using devm_drm_dev_alloc

v2: Fix typos (Noralf)

v3: Split out the removal of drm_dev_init, that's blocked on some
discussions on how to convert vgem/vkms/i915-selftests. Adjust commit
message to reflect that.

Cc: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Noralf Trønnes <noralf@tronnes.org> (v2)
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Luben Tuikov <luben.tuikov@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200902072627.3617301-1-daniel.vetter@ffwll.ch

That is not used any more.

v2: keep the NULL checks in TTM.
v3: remove unused variable

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/388646/

While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.

In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.

v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
v5: rebased and keep the mem.bus init in TTM.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/388643/

We are trying to remove the io_lru handling and depend
on zero init base, offset and addr here.

v2: init addr as well

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/388642/

Fix kernel-doc warning in <linux/dma-buf.h>:

../include/linux/dma-buf.h:330: warning: Function parameter or member 'name_lock' not described in 'dma_buf'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/388523/


Signed-off-by: Christian König <christian.koenig@amd.com>

Add @cookie to dma_fence_end_signalling() to prevent kernel-doc
warning in drivers/dma-buf/dma-fence.c:

../drivers/dma-buf/dma-fence.c:291: warning: Function parameter or member 'cookie' not described in 'dma_fence_end_signalling'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/388527/


Signed-off-by: Christian König <christian.koenig@amd.com>

Not needed, already tracked by drm_crtc_state->active.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-3-kraxel@redhat.com

When going through a disable/enable cycle without changing the
framebuffer the optimization added by commit 3954ff10 ("drm/virtio:
skip set_scanout if framebuffer didn't change") causes the screen stay
blank.  Add a bool to force an update to fix that.

v2: use drm_atomic_crtc_needs_modeset() (Daniel).

Cc: 1882851@bugs.launchpad.net
Fixes: 3954ff10 ("drm/virtio: skip set_scanout if framebuffer didn't change")
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Jiri Slaby <jirislaby@kernel.org>
Tested-by: Diego Viola <diego.viola@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20200818072511.6745-2-kraxel@redhat.com

The only usage of these is to assign their address to the fbops field in
the fb_info struct, which is a const pointer. Make them const to allow
the compiler to put them in read-only memory.

Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200830211741.17326-1-rikard.falkeborn@gmail.com

In order to shrink drm_display_mode below the magic two cacheline
mark in 64bit we need to shrink it by another 8 bytes. The easiest
thing to eliminate is the 'export_head' list head which is only
used during the getconnector ioctl to temporarly track which modes
on the connector's mode list are to be exposed and which are to
remain hidden.

We can simply replace the list head with a boolean which we use
to tag the modes that are to be exposed. If we make sure to clear
the tags after we're done with them we don't even need an extra
loop over the modes to reset the tags at the start of the
getconnector ioctl.

Conveniently we already have a hole for the boolean left
behind by the removal of mode->private_flags. The final size
of the struct is now 112 bytes on 32bit and 120 bytes on 64bit.

Another alternative would be a temp bitmask so we wouldn't have
to have anything in the mode struct itself. The main issue is
how large of a bitmask do we need? I guess we could allocate
it dynamically but that means an extra kcalloc() and an extra
loop through the modes to count them first (or grow the bitmask
with krealloc() as needed).

CC: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-17-ville.syrjala@linux.intel.com


Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

The last two uses of mode->private_flags (in i915 and gma500)
are now gone. So let's remove mode->private_flags entirely.

v2: Drop the earlier int->u8 conversion

CC: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-16-ville.syrjala@linux.intel.com


Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

For DP MST outputs, the i2c device currently only supports transfers
that can be implemented using remote i2c reads. Such transfers must
consist of zero or more write transactions followed by one read
transaction. DDC/CI commands require standalone write transactions and
hence aren't supported.

Since each remote i2c write is handled as a separate transfer, remote
i2c writes can support transfers consisting of write transactions, where
all but the last have I2C_M_STOP set. According to the DDC/CI 1.1
standard, DDC/CI commands only require a single write or read
transaction in a transfer, so this is sufficient.

For i2c transfers meeting the above criteria, generate and send a remote
i2c write message for each transaction. Add the trivial remote i2c write
reply parsing support so remote i2c write acks bubble up correctly.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37


Signed-off-by: Sam McNally <sammc@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200727160225.1.I4e95a534de051551cd143e6cb83d4c5a9b0ad1cd@changeid

When verify_crc_source() fails, source needs to be freed.
However, current code is returning directly and ends up
leaking memory.

Fixes: d5cc15a0 ("drm: crc: Introduce verify_crc_source callback")
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[danvet: change Fixes: tag per Laurent's review]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200819082228.26847-1-dinghao.liu@zju.edu.cn

Fix kconfig dependency warning by using a different Kconfig symbol.

WARNING: unmet direct dependencies detected for VIRTIO_DMA_SHARED_BUFFER
  Depends on [n]: VIRTIO_MENU [=n] && DMA_SHARED_BUFFER [=y]
  Selected by [y]:
  - DRM_VIRTIO_GPU [=y] && HAS_IOMEM [=y] && DRM [=y] && VIRTIO [=y] && MMU [=y]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/7481fb88-6b04-3726-57e0-0f513245c657@infradead.org


Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

This can be gotten back from bdev.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-3-airlied@gmail.com

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-2-airlied@gmail.com

hibmc can only be used in ARM64 architectures, and mmu defaults to y
in arch/arm64/Kconfig, so there is no need to add a dependency on mmu
in hibmc's kconfig.

Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1598428528-49046-1-git-send-email-tiantao6@hisilicon.com

This patch avoid the warning in vkms_get_vblank_timestamp when vblanks
aren't enabled. When running igt test kms_cursor_crc just after vkms
module, the warning raised like below. Initial value of vblank time is
zero and hrtimer.node.expires is also zero if vblank aren't enabled
before. vkms module isn't real hardware but just virtual hardware
module. so vkms can't generate a resonable timestamp when hrtimer is
off. it's best to grab the current time.

[106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change
[106444.471475] WARNING: CPU: 0 PID: 10109 at
vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: G        W  OE
5.9.0-rc1+ #6
[106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471528] Call Trace:
[106444.471551]  drm_get_last_vbltimestamp+0xb9/0xd0 [drm]
[106444.471566]  drm_reset_vblank_timestamp+0x63/0xe0 [drm]
[106444.471579]  drm_crtc_vblank_on+0x85/0x150 [drm]
[106444.471582]  vkms_crtc_atomic_enable+0xe/0x10 [vkms]
[106444.471592]  drm_atomic_helper_commit_modeset_enables+0x1db/0x230
[drm_kms_helper]
[106444.471594]  vkms_atomic_commit_tail+0x38/0xc0 [vkms]
[106444.471601]  commit_tail+0x97/0x130 [drm_kms_helper]
[106444.471608]  drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper]
[106444.471622]  drm_atomic_commit+0x4a/0x50 [drm]
[106444.471629]  drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper]
[106444.471642]  drm_mode_setcrtc+0x1d9/0x7b0 [drm]
[106444.471654]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471666]  drm_ioctl_kernel+0xb6/0x100 [drm]
[106444.471677]  drm_ioctl+0x3ad/0x470 [drm]
[106444.471688]  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471692]  ? tomoyo_file_ioctl+0x19/0x20
[106444.471694]  __x64_sys_ioctl+0x96/0xd0
[106444.471697]  do_syscall_64+0x37/0x80
[106444.471699]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Cc: Melissa Wen <melissa.srw@gmail.com>

Signed-off-by: Sidong Yang <realwakka@gmail.com>
Reviewed-by: Melissa Wen <melissa.srw@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200828124553.2178-1-realwakka@gmail.com

The VKMS blend function was ignoring the alpha channel and just
overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a
warning when running the kms_cursor_crc/cursor-alpha-transparent test
case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to
documentation). Also current DRM assumption is that alpha is
premultiplied. Therefore, this patch considers premultiplied alpha
blending eq to compose vaddr_src with vaddr_dst.

This change removes the following cursor-alpha-transparent warning:

 "Suspicious CRC: All values are 0."

V2:
- static for local functions
- const for the read-only variable argb_src
- replaces variable names
- drops unnecessary comment

Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Cc: Haneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: Melissa Wen <melissa.srw@gmail.com>
Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200825114532.abzdooluny2ekzvm@smtp.gmail.com

The OrtusTech COM43H4M85ULC panel is a 18-bit RGB panel. Commit
f098f168 ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC
panel") has fixed the bus formats, but forgot to address the bpc value.
Set it to 6.

Fixes: f098f168 ("drm: panel: Fix bus format for OrtusTech COM43H4M85ULC panel")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200824003254.21904-1-laurent.pinchart@ideasonboard.com

DSI end-points are supposed to be at node 0 and node 1 as per binding.
So fix this and use node 0 and node 1 for dsi.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 23278bf5 ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200828074251.3788165-1-vkoul@kernel.org

The flag MIPI_DSI_CLOCK_NON_CONTINUOUS was wrong used in the DSI driver,
so it was added to this panel, but not necessary.
So, remove this flag since it is not needed.

Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1598626713-5595-1-git-send-email-robert.chiras@oss.nxp.com

Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200829163328.249211-2-jagan@amarulasolutions.com

Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd.
as part of panel-simple.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200829163328.249211-1-jagan@amarulasolutions.com

The LVDS controller can invert the polarity / lanes of the LVDS output.
The default polarity causes some issues on some panels.

However, U-Boot has always used the opposite polarity without any reported
issue, and the only currently supported LVDS panel in-tree (the TBS A711)
seems to be able to work with both settings.

Let's just use the same polarity than U-Boot to be more consistent and
hopefully support all the panels.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Cc: Ondrej Jirman <megous@megous.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200704133803.37330-1-maxime@cerno.tech

There is a spelling mistake in a drm_warn message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826084727.42703-1-colin.king@canonical.com