The HW cursor of Matrox G200 cards only supports a 16-color palette
format. Univeral planes require at least ARGB or a similar component-
based format, so remove the HW cursor.

Alternatively, the driver could dither a cursor image from ARGB to
16 colors. But this does not produce pleasent-looking results in
general, so it's useless for modern compositors.

Without HW support, compositors will use software rendering.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NEmil Velikov <emil.velikov@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515083233.32036-2-tzimmermann@suse.de

struct platform_driver panel_driver is only used from tilcdc_panel.c, so
it can be static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-3-tomi.valkeinen@ti.comReviewed-by: NJyri Sarha <jsarha@ti.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>

tilcdc_plane_atomic_check() exits if state->fb == NULL, so no need to
check it again later.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-2-tomi.valkeinen@ti.comReviewed-by: NJyri Sarha <jsarha@ti.com>

If videomode_from_timings() returns true, the mode allocated with
drm_mode_create will be leaked.

Also, the return value of drm_mode_create() is never checked, and thus
could cause NULL deref.

Fix these two issues.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.comReviewed-by: NJyri Sarha <jsarha@ti.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>

The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
remapping of eDP lanes and also polarity inversion.  Both of these
features have been described in the device tree bindings for the
device since the beginning but were never implemented in the driver.
Implement both of them.

Part of this change also allows you to (via the same device tree
bindings) specify to use fewer than the max number of DP lanes that
the panel reports.  This could be useful if your display supports more
lanes but only a few are hooked up on your board.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200518114656.REPOST.v2.1.Ibc8eeddcee94984a608d6900b46f9ffde4045da4@changeid

If the rate in our table is _equal_ to the rate we want then it's OK
to pick it.  It doesn't need to be greater than the one we want.

Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200504213225.1.I21646c7c37ff63f52ae6cdccc9bc829fbc3d9424@changeid

The AUX channel transfer error bits in the status register are latched
and need to be cleared.  Clear them before doing our transfer so we
don't see old bits and get confused.

Without this patch having a single failure would mean that all future
transfers would look like they failed.

Fixes: b814ec6d ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200508163314.1.Idfa69d5d3fc9623083c0ff78572fea87dccb199c@changeid

The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware.  Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for knowing when the panel is ready, not for
detecting physical plug events.

Currently the driver in Linux just assumes that nobody has HPD hooked
up.  It relies on folks setting the "no-hpd" property in the panel
node to specify that HPD isn't hooked up and then the panel driver
using this to add some worst case delays when turning on the panel.

Apparently it's also useful to specify "no-hpd" in the bridge node so
that the bridge driver can make sure it's doing the right thing
without peeking into the panel [1].  This would be used if anyone ever
found it useful to implement support for the HW HPD pin on the bridge.
Let's add this property to the bindings.

NOTES:
- This is somewhat of a backward-incompatible change.  All current
  known users of ti-sn65dsi86 didn't have "no-hpd" specified in the
  bridge node yet none of them had HPD hooked up.  This worked because
  the current Linux driver just assumed that HPD was never hooked up.
  We could make it less incompatible by saying that for this bridge
  it's assumed HPD isn't hooked up _unless_ a property is defined, but
  "no-hpd" is much more standard and it's unlikely to matter unless
  someone quickly goes and implements HPD in the driver.
- It is sensible to specify "no-hpd" at the bridge chip level and
  specify "hpd-gpios" at the panel level.  That would mean HPD is
  hooked up to some other GPIO in the system, just not the hardware
  HPD pin on the bridge chip.

[1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.comSigned-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.5.I72892d485088e57378a4748c86bc0f6c2494d807@changeid

This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.4.Ifcdc4ecb12742a27862744ee1e8753cb95a38a7f@changeid

The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system.  Each pin can be configured as input,
output, or a special function for the bridge chip.  These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM

Let's expose these pins as GPIOs.  A few notes:
- Access to ti-sn65dsi86 is via i2c so we set "can_sleep".
- These pins can't be configured for IRQ.
- There are no programmable pulls or other fancy features.
- Keeping the bridge chip powered might be expensive.  The driver is
  setup such that if all used GPIOs are only inputs we'll power the
  bridge chip on just long enough to read the GPIO and then power it
  off again.  Setting a GPIO as output will keep the bridge powered.
- If someone releases a GPIO we'll implicitly switch it to an input so
  we no longer need to keep the bridge powered for it.

Because of all of the above limitations we just need to implement a
bare-bones GPIO driver.  The device tree bindings already account for
this device being a GPIO controller so we only need the driver changes
for it.

NOTE: Despite the fact that these pins are nominally muxable I don't
believe it makes sense to expose them through the pinctrl interface as
well as the GPIO interface.  The special functions are things that the
bridge chip driver itself would care about and it can just configure
the pins as needed.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
[added pdata->gchip.base = -1;]
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.1.Ia50267a5549392af8b37e67092ca653a59c95886@changeid

drivers/gpu/drm/drm_dp_mst_topology.c:2898:6: warning: symbol 'drm_dp_send_clear_payload_id_table' was not declared. Should it be static?
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-4-chris@chris-wilson.co.uk

drivers/gpu/drm/drm_dp_helper.c:1598: warning: Function parameter or member 'dp_rev' not described in 'drm_dp_set_phy_test_pattern'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-3-chris@chris-wilson.co.uk

drivers/gpu/drm/drm_client_modeset.c: In function ‘drm_client_firmware_config’:
./include/linux/bits.h:26:28: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
   __builtin_constant_p((l) > (h)), (l) > (h), 0)))

v2: Add a warning for passing connector_count==0 as this will hit an
infinite loop, so document the invalid parameter.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-2-chris@chris-wilson.co.uk

drivers/gpu/drm/drm_managed.c:61:6: warning: symbol 'drm_managed_release' was not declared. Should it be static?
  CC      drivers/gpu/drm/drm_managed.o
drivers/gpu/drm/drm_managed.c:61:6: warning: no previous prototype for ‘drm_managed_release’ [-Wmissing-prototypes]
 void drm_managed_release(struct drm_device *dev)

Fixes: c6603c74 ("drm: add managed resources tied to drm_device")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-1-chris@chris-wilson.co.uk

Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.

v2:
  - Added Cc: Peter Ujfalusi
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200517190139.740249-2-sam@ravnborg.org

drm_helper_probe_add_cmdline_mode() prefers using a probed mode matching
a video= argument over calculating our own timings for the user specified
mode using CVT or GTF.

But userspace code which is auto-configuring the mode may want to know that
the user has specified that mode on the kernel commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.

This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221173313.510235-2-hdegoede@redhat.com

i2c_new_client() is deprecated, use the replacement
i2c_new_client_device(). Also, we have a helper to check if a driver is
bound. Use it to simplify the code. Note that this changes the errno for
a failed device creation from ENOMEM to ENODEV. No callers currently
interpret this errno, though, so we use this condensed error check.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200316163907.13709-3-wsa+renesas@sang-engineering.com

module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.

Fixes: 2066facc ("drm/kms: slave encoder interface.")
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200316163907.13709-2-wsa+renesas@sang-engineering.com

Using plain echo to set the "force" connector attribute fails with
-EINVAL, because echo appends a newline to the output.

Replace strcmp with sysfs_streq to also accept strings that end with a
newline.

v2: use sysfs_streq instead of stripping trailing whitespace
Signed-off-by: NMichael Tretter <m.tretter@pengutronix.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817104307.17124-1-m.tretter@pengutronix.de

If the "handles" allocation or the copy_from_user() fails then we leak
"objs".  It's supposed to be freed in panfrost_job_cleanup().

Fixes: c117aa4d ("drm: Add a drm_gem_objects_lookup helper")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200320132334.GC95012@mwanda

The function vop_cfg_done() is a simple VOP_REG_SET(). As such it should
be done under a reg_lock. A quick look through the driver shows that all
other instances (apart from driver init) have the lock. Do the same here

Cc: Sandy Huang <hjc@rock-chips.com>
Cc: Heiko Stübner <heiko@sntech.de>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Reviewed-by: NSandy Huang <hjc@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200505151613.2932456-1-emil.l.velikov@gmail.com

Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514191001.457441-3-sam@ravnborg.org

Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Zheng Bin <zhengbin13@huawei.com>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Enrico Weigelt <info@metux.net>
Cc: Allison Randal <allison@lohutok.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200514191001.457441-2-sam@ravnborg.org

The main DRM device is actually a virtual device so it doesn't have the
iommus property, which is instead on the DMA masters, in this case the
mixers.

Add a call to of_dma_configure with the mixers DT node but on the DRM
virtual device to configure it in the same way than the mixers.
Reviewed-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.maxime@cerno.tech

The H6 mixer is attached to an IOMMU, so let's allow that property to be
set in the bindings.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/7941e0c02794e6336da75fcac950ecd43be7fd97.1589378833.git-series.maxime@cerno.tech

This fixes the following use-after-free problem in case an MST down
message times out, while waiting for the response for it:

[  449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0
[  449.022898] ------------[ cut here ]------------
[  449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140).
[  449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70
[  449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers
[  449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1
[  449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019
[  449.022976] Workqueue: events_long drm_dp_mst_link_probe_work
[  449.022982] RIP: 0010:__list_add_valid+0x4d/0x70
[  449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8
[  449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286
[  449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001
[  449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff
[  449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000
[  449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400
[  449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540
[  449.023013] FS:  0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000
[  449.023017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0
[  449.023025] PKRU: 55555554
[  449.023028] Call Trace:
[  449.023034]  drm_dp_queue_down_tx+0x59/0x110
[  449.023041]  ? rcu_read_lock_sched_held+0x4d/0x80
[  449.023050]  ? kmem_cache_alloc_trace+0x2a6/0x2d0
[  449.023060]  drm_dp_send_link_address+0x74/0x870
[  449.023065]  ? __slab_free+0x3e1/0x5c0
[  449.023071]  ? lockdep_hardirqs_on+0xe0/0x1c0
[  449.023078]  ? lockdep_hardirqs_on+0xe0/0x1c0
[  449.023097]  drm_dp_check_and_send_link_address+0x9a/0xc0
[  449.023106]  drm_dp_mst_link_probe_work+0x9e/0x160
[  449.023117]  process_one_work+0x268/0x600
[  449.023124]  ? __schedule+0x307/0x8d0
[  449.023139]  worker_thread+0x37/0x380
[  449.023149]  ? process_one_work+0x600/0x600
[  449.023153]  kthread+0x140/0x160
[  449.023159]  ? kthread_park+0x80/0x80
[  449.023169]  ret_from_fork+0x24/0x50

Fixes: d308a881 ("drm/dp_mst: Kill the second sideband tx slot, save the world")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: <stable@vger.kernel.org> # v3.17+
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200513103155.12336-1-imre.deak@intel.com

The R-Car DU driver calls drm_vblank_init via some helper functions in
probe(). From what I checked, most drivers do this as well. I have a
config now where DU always stays in deferred_probe state because of a
missing dependency. This means that every time I rebind another driver
like MMC, the vblank init message is displayed again when the DU driver
is retried. Because the message doesn't really carry a useful
information, I suggest to simply drop it.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200513201016.23047-1-wsa+renesas@sang-engineering.com

Now that atomic64_fetch_add() exists we can use it to return the base
context id, rather than the atomic64_add_return(N) - N concoction.
Suggested-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMaciej Patelczyk <maciej.patelczyk@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200513074809.18194-2-chris@chris-wilson.co.uk

The of_drm_find_bridge() function returns NULL on error, it doesn't return
error pointers so this check doesn't work.

Fixes: 5fc537bf ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200430073145.52321-1-weiyongjun1@huawei.com

Storing the connector instance in struct mga_device avoids some
dynamic memory allocation. On errors, the connector's initializer
function now destroys the i2c structure. Done in preparation of
converting mgag200 to simple-KMS helpers.

v2:
	* improved commit message (Michael)
	* fixed error message for mgag200_vga_connector_init() (Sam)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMichael J. Ruhl <michael.j.ruhl@intel.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-7-tzimmermann@suse.de

The fields mode_info, num_crtcs and mode in struct mga_device serve
no purpose. Remove them.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-6-tzimmermann@suse.de

Mode configuration is now cleanued up automatically. While at it,
move all mode-config code into mgag200_mode.c. Done in preparation
of switching mgag200 to simple-KMS helpers.

v2:
	* improve commit message (Sam)
	* rebased during cherry pick
	* also move bpp_shift initialization
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Tested-by: NJohn Donnelly <John.p.donnelly@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-5-tzimmermann@suse.de

Done to simplify initialization code before embedding the DRM device
instance in struct mga_device.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-4-tzimmermann@suse.de

Done in preparation of embedding the DRM device in struct mga_device.
This patch makes the patch for embedding more readable.

v2:
	* improved commit message (Daniel)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-3-tzimmermann@suse.de

Mgag200 uses dev_private to look up struct mga_device for instances
of struct drm_device. Use of dev_private is deprecated, so hide it in
the helper function to_mga_device().

v2:
	* make to_mga_device() a function (Sam)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507090315.21274-2-tzimmermann@suse.de

No other functions use the return value of pxa168fb_init_mode() and the
return value is always 0 now. Make it return void. This fixes the
following coccicheck warning:

drivers/video/fbdev/pxa168fb.c:565:5-8: Unneeded variable: "ret". Return
"0" on line 597
Signed-off-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
[fixed indent]
Link: https://patchwork.freedesktop.org/patch/msgid/20200506061745.19451-1-yanaijie@huawei.com

Fix the following sparse warning:

drivers/gpu/drm/i2c/tda998x_drv.c:1136:5: warning:
symbol 'tda998x_audio_digital_mute' was not declared. Should it be static?
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NSamuel Zou <zou_wei@huawei.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1588819768-11818-1-git-send-email-zou_wei@huawei.com

People use panel-simple when they have panels that are builtin to
their device.  In these cases the HPD (Hot Plug Detect) signal isn't
really used for hotplugging devices but instead is used for power
sequencing.  Panel timing diagrams (especially for eDP panels) usually
have the HPD signal in them and it acts as an indicator that the panel
is ready for us to talk to it.

Sometimes the HPD signal is hooked up to a normal GPIO on a system.
In this case we need to poll it in the correct place to know that the
panel is ready for us.  In some system designs the right place for
this is panel-simple.

When adding this support, we'll account for the case that there might
be a circular dependency between panel-simple and the provider of the
GPIO.  The case this was designed for was for the "ti-sn65dsi86"
bridge chip.  If HPD is hooked up to one of the GPIOs provided by the
bridge chip then in our probe function we'll always get back
-EPROBE_DEFER.  Let's handle this by allowing this GPIO to show up
late if we saw -EPROBE_DEFER during probe.  NOTE: since the
gpio_get_optional() is used, if the "hpd-gpios" isn't there our
variable will just be NULL and we won't do anything in prepare().
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.3.I53fed5b501a31e7a7fa13268ebcdd6b77bd0cadd@changeid

In the cases where there is no connector in a system there's no great
place to put "hpd-gpios".  As per discussion [1] the best place to put
it is in the panel.  Add this to the device tree bindings.

[1] https://lore.kernel.org/r/20200417180819.GE5861@pendragon.ideasonboard.comSigned-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.2.I1976736b400a3b30e46efa47782248b86b3bc627@changeid

All info I could find about this panel show that it behaves the same
as the BOE NV133FHM-N61.  However, it definitely appears to be a
unique panel because reading the EDID shows "NV133FHM-N62".  We'll add
a string match for the new panel but until we find something unique
about it we'll just point at the N61's structures.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.3.I525ebd471f5340a6a369af7bde06ef04174d2f41@changeid