Calling drm_connector_update_edid_property() should be done
unconditionally instead of depending on the number of modes added. Also
match the call order in inno_hdmi and rk3066_hdmi.

Cc: Sandy Huang <hjc@rock-chips.com>
Cc: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/bb733eccfb389533cc6e207689be845164a1ed91.1662036058.git.jani.nikula@intel.com

Prefer the parsed results for is_hdmi in display info over calling
drm_detect_hdmi_monitor(). Remove the now redundant hdmi_monitor member
from struct sti_hdmi.

Cc: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Alain Volmat <avolmat@me.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74fbd7a83712009734534d92e5499d4d87f0c53b.1662036058.git.jani.nikula@intel.com

Create a symlink pointing to USB Type-C connector for DRM connectors
when they are created. The link will be created only if the firmware is
able to describe the connection beween the two connectors.

Currently, even if a display uses a USB Type-C port, there is no way for
the userspace to find which port is used for which display. With the
symlink, display information would be accessible from Type-C connectors
and port information would be accessible from DRM connectors.

Associating the two subsystems, userspace would have potential to expose
and utilize more complex information. ChromeOS intend to use this
information for metrics collection. For example, we want to tell which
port is deriving which displays. Also, combined with USB PD information,
we can tell whether user is charging their device through display.
Chromium patch for parsing the symlink from the kernel is at
http://crrev.com/c/4317207.

We already have a framework in typec port-mapper.c where it goes through
component devices and runs the bind functions for those with matching
_PLD (physical location of device).
https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/
port-mapper.c
Since _PLD is ACPI specific field, this linking would only work on ACPI
x86 as long as _PLD field for Type-C connectors and DRM connectors are
correctly added to the firmware.

Currently, USB ports and USB4 ports are added as components to create a
symlink with Type C connector.
USB:
https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus
@linux.intel.com/
USB4:
https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/
So, we follow the same pattern in this patch.
Signed-off-by: Won Chung <wonchung@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427165813.2844530-1-wonchung@google.com

Expose DRM connector id in device sysfs so that we can map the connector
id to the connector syspath. Currently, even if we can derive the
connector id from modeset, we do not have a way to find the
corresponding connector's syspath.

This is helpful when determining the root connector of MST tree. When a
tree of multiple MST hub is connected to the system, modeset describes
the tree in the PATH blob. For example, consider the following scenario.

+-------------+
| Source      |    +-------------+
| (Device)    |    | BranchX     |
|             |    | (MST)       |
|       [conn6]--->|       [port1]--->DisplayA
+-------------+    |             |
                   |             |    +-------------+
                   |             |    | BranchY     |
                   |             |    | (MST)       |
                   |       [port2]--->|       [port1]----->DisplayB
                   +-------------+    |             |
                                      |       [port2]----->DisplayC
                                      +-------------+

DPMST connector of DisplayA would have "mst:6-1" PATH.
DPMST connector of DisplayB would have "mst:6-2-1" PATH.
DPMST connector of DisplayC would have "mst:6-2-2" PATH.

Given that connector id of 6 is the root of the MST connector tree, we
can utilize this patch to parse through DRM connectors sysfs and find
which connector syspath corresponds to the root connector (id == 6).

ChromeOS intend to use this information for metrics collection. For
example, we want to tell which port is deriving which displays even with
a MST hub. Chromium patch for parsing DRM connector id from the kernel
is at http://crrev.com/c/4317207.
Signed-off-by: Won Chung <wonchung@google.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329014455.1990104-1-wonchung@google.com

drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show()

The address of a data structure member was determined before
a corresponding null pointer check in the implementation of
the function “receive_timing_debugfs_show”.

Thus avoid the risk for undefined behaviour by moving the assignment
for the variable “vid” behind the null pointer check.

This issue was detected by using the Coccinelle software.

Fixes: b5c84a9e ("drm/bridge: add it6505 driver")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://patchwork.freedesktop.org/patch/msgid/fa69384f-1485-142b-c4ee-3df54ac68a89@web.deReviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>

Document in which order the CTM matrix elements are stored.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411222931.15127-2-ville.syrjala@linux.intel.comReviewed-by: Xaver Hugl <xaver.hugl@gmail.com>
Acked-by: Simon Ser <contact@emersion.fr>

smatch has several similar warnings to
drivers/gpu/drm/meson/meson_venc.c:189:28: warning: symbol
  'meson_hdmi_enci_mode_480i' was not declared. Should it be static?

These variables are only used in their defining file so should be static
Signed-off-by: Tom Rix <trix@redhat.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230423145300.3937831-1-trix@redhat.com

The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the
Anbernic RG353V handheld gaming device. Add support for it.

Unfortunately it appears this controller is not able to support 120hz
or 100hz mode like the first revision panel.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230426143213.4178586-4-macroalpha82@gmail.com

A later revision of the datasheet for the ST7703 refers to this command
as "SETECO".
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230426143213.4178586-3-macroalpha82@gmail.com

The Anbernic RG353V-V2 panel is a 3.5 inch 640x480 MIPI-DSI LCD panel.
It's based on the ST7703 LCD controller just like rocktech,jh057n00900.
It's used in a 2nd revision of the Anbernic RG353V handheld gaming
device. Like the first revision of the RG353V the control chip is known
but the panel itself is unknown, so name it for the device.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Guido Günther <agx@sigxcpu.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230426143213.4178586-2-macroalpha82@gmail.com

Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
order to avoid unnecessary delays.

This initial document starts with a TODO list containing items with clear and
measurable key results. Xe’s initial pull request should only be sent to
dri-devel after all the items are clearly resolved.

Since many of them involve some level of a community consensus, in many cases,
the consensus will be reached in follow-up patches to this document with more
details of the API or helpers that will be developed or modified.

Besides of the items that are highlighted in this document, it is important
to highlight that Oded, has been volunteered to give the overall ack on Xe
driver as the way to confirm that it looks good for upstream.

v2: Incorporated Daniel's feedback:
    - Do not make long-running compute a blocker.
    - Add a mention to drm-exec that that ties to vm_bind and long-running
      compute jobs. Then I also added GPUVA since I recently noticed that this
      ties also to the work Matt is doing on that front.
    - Added the devcoredump section.
    - Add the mention to Oded being volunteered for the overall ack.

v3: Reword a bit the Async VM_BIND to incorporate Daniel's feedback on ensuring
    the async vmbind consensus explicitly include Mesa, besides other kernel
    drivers.

Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Signed-off-by: Luis Strano <luis.strano@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230419191913.158807-1-rodrigo.vivi@intel.com

Now that VKMS supports full alpha blending on all planes, drop the
"ARGB format on primary plane" and "Full alpha blending on all planes"
tasks from the TODO list.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420232228.273340-2-mcanal@igalia.com

Before commit bc0d7fde ("drm: vkms: Supports to the case where
primary plane doesn't match the CRTC"), the composition was executed on
top of the primary plane. Therefore, the primary plane was not able to
support the alpha channel. After commit bc0d7fde, this is possible,
as the composition is now executed on top of the CRTC.

So, allow all planes to support the alpha channel, making full alpha
blending possible in vkms.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Melissa Wen <mwen@igalia.com>
Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420232228.273340-1-mcanal@igalia.com

Move the implementation of fb_pgprotect() to fbdev.c and include
<asm/fb.h>. Fixes the following warning:

  ../arch/x86/video/fbdev.c:14:5: warning: no previous prototype for 'fb_is_primary_device' [-Wmissing-prototypes]
     14 | int fb_is_primary_device(struct fb_info *info)
        |     ^~~~~~~~~~~~~~~~~~~~

Just including <asm/fb.h> results in a number of built-in errors
about undefined function. Moving fb_pgprotect() to the source file
avoids the required include statements in the header. The function
is only called occasionally from fb_mmap(), [1] so having it as static
inline had no benefit.

While at it, fix the codying style in fbdev.c.

Link: https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/video/fbdev/core/fbmem.c#L1404 # 1
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230424084751.14641-1-tzimmermann@suse.de

Add atomic_get_input_bus_fmts() implementation, tc358768 has a parallel
RGB input interface with the actual bus format depending on the amount
of parallel input data lines.

Without this change when the tc358768 is used with less than 24bit the
color mapping is completely wrong.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230330095941.428122-7-francesco@dolcini.it

Even though we report that we support the BT.2020 Colorspace, we were
always using the BT.709 conversion matrices. Let's add the BT.2020 ones.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-9-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

Even though we report that we support the BT601 Colorspace, we were
always using the BT.709 conversion matrices. Let's add the BT601 ones.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-8-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The CSC matrix to use depends on the output format, its range and the
colorspace.

Since we're going to add more colorspaces, let's move the CSC matrix
retrieval to a function.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-7-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The CSC matrices were stored as separate matrix for each colorspace, and
if we wanted a limited or full RGB output.

This created some gaps in our support and we would not always pick the
relevant matrix.

Let's rework our data structure to store one per colorspace, and then a
matrix for limited range and one for full range. This makes us add a new
matrix to support full range BT709 YUV output.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-6-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

YUV444 and YUV422 actually require the same matrix, but programmed
differently.

We've dealt with it in the past by having two matrices, with the one
for YUV444 reordered to accomodate the hardware.

This gets in the way of subsequent reworks so let's define a function
that will take the coefficients swap into account, and remove the now
redundant YUV444 matrix.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-5-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The VC4 HDMI driver has a helper function to figure out whether full
range or limited range RGB is being used called
vc4_hdmi_is_full_range_rgb().

We'll need it to support other colorspaces, so let's rename it to
vc4_hdmi_is_full_range().
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-4-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

Copy Intel's "Broadcast RGB" property semantics to add manual override
of the HDMI pixel range for monitors that don't abide by the content
of the AVI Infoframe.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-3-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

On VC4, the TV margins on the HDMI connector are implemented by scaling
the planes.

However, if only the TV margins or the connector are changed by a new
state, the planes ending up on that connector won't be. Thus, they won't
be updated properly and we'll effectively ignore that change until the
next commit affecting these planes.

Let's make sure to add all the planes attached to the connector so that
we can update them properly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-2-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.

Let's switch all our instances of container_of() to
container_of_const().
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20221207-rpi-hdmi-improvements-v3-1-bdd54f66884e@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

Currently, the pixel conversion functions repeat the same loop to
iterate the rows. Instead of repeating the same code for each pixel
format, create a function to wrap the loop and isolate the pixel
conversion functionality.
Suggested-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418130525.128733-2-mcanal@igalia.com

Insert a parameterized test for the drm_rect_rotate_inv() to ensure its
correctness and prevent future regressions. The test covers all rotation
modes.

It uses the same test cases from drm_test_rect_rotate().
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418230146.461129-6-arthurgrillo@riseup.net

Insert a parameterized test for the drm_rect_rotate() to ensure
correctness and prevent future regressions.

All possible rotation modes are covered by the test.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418230146.461129-5-arthurgrillo@riseup.net

Insert parameterized test for the drm_rect_calc_vscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.

It uses the same struct from drm_rect_calc_hscale().
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418230146.461129-4-arthurgrillo@riseup.net

Insert parameterized test for the drm_rect_calc_hscale() to ensure
correctness and prevent future regressions. Besides the test for the
usual case, tests the exceptions.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418230146.461129-3-arthurgrillo@riseup.net

Insert parameterized tests for the drm_rect_intersect() to ensure
correctness and prevent future regressions.

Also, create a helper for testing if two drm_rects are equal.
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418230146.461129-2-arthurgrillo@riseup.net

Backmerging to get the exynos fbdev updates.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

Switch to using RCU handling for the last scheduled job and add a
function to return the error code of it.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420115752.31470-2-christian.koenig@amd.com

When a hw fence is signaled with an error properly forward that to the
finished fence.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Luben Tuikov <luben.tuikov@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420115752.31470-1-christian.koenig@amd.com

Convert platform_get_resource(),devm_ioremap_resource() to a single
call to devm_platform_ioremap_resource(), as this is exactly what this
function does.
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230421091319.79744-1-yang.lee@linux.alibaba.com

Merge tag 'exynos-drm-next-for-v6.4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

A patch series for implementing fbdev emulation as in-kernel client.

- This patch series refactors fbdev callbacks to DRM client functions and
  simplifies fbdev emulation initialization including some code cleanups.
  The changes make fbdev emulation behave like a regular DRM client.
Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417100624.35229-1-inki.dae@samsung.com

Merge tag 'drm-intel-next-fixes-2023-04-20-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

Active port PLL MST fix for second stream, CSC plane index fix,
null and oob array deref fixes and selftest memory leak fix.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZEDz9ZedyZVyFXxU@jlahtine-mobl.ger.corp.intel.com

This driver includes the deprecated OF GPIO header <linux/of_gpio.h>
yet fail to use symbols from it, so drop this include.

Cc: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Acked-by: Alain Volmat <avolmat@me.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220812205746.609107-5-mairacanal@riseup.net

This driver includes the deprecated OF GPIO header <linux/of_gpio.h>
yet fail to use symbols from it, so drop the include.

Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Maíra Canal <mairacanal@riseup.net>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220812205746.609107-2-mairacanal@riseup.net

This commit adds missing luminance control registers to enable a more
standard way (VESA) to deal with eDP luminance control.

Cc: Anthony Koo <anthony.koo@amd.com>
Cc: Iswara Negulendran <iswara.nagulendran@amd.com>
Cc: Felipe Clark <felipe.clark@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230412000943.429031-1-Rodrigo.Siqueira@amd.com

Add InnoLux G070ACE-L01 7" 800x480 TFT LCD with WLED backlight panel
support. Timing data was extracted from datasheet and vendor provided
EDID file.
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230201-innolux-g070ace-v2-2-2371e251dd40@skidata.com