All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.

All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those drivers.
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-2-maxime@cerno.tech

All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.

Provide a helper for it as well
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-1-maxime@cerno.tech

In commit 5c209d80 ("drm/gma500: psb_spank() doesn't need it's
own file"), accel_2d.c was deleted and psb_spank() was moved into
psb_drv.c. Fix the comment here.
Signed-off-by: NWan Jiabing <wanjiabing@vivo.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506112851.20315-1-wanjiabing@vivo.com

Since

commit 890880dd
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: nouveau@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vetter@ffwll.ch

Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.

Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Acked-by: NPekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-5-daniel.vetter@ffwll.ch

Since

commit 890880dd
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.

v2: Rebase.
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Kalyan Thota <kalyant@codeaurora.org>
Cc: Jordan Crouse <jordan@cosmicpenguin.net>
Cc: Eric Anholt <eric@anholt.net>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-4-daniel.vetter@ffwll.ch

Since

commit 890880dd
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: "José Roberto de Souza" <jose.souza@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-3-daniel.vetter@ffwll.ch

Since

commit 890880dd
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here.
Acked-by: NPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: Yannick Fertre <yannick.fertre@foss.st.com>
Cc: Philippe Cornu <philippe.cornu@foss.st.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-7-daniel.vetter@ffwll.ch

Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Acked-by: NPekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-2-daniel.vetter@ffwll.ch

Since

commit 890880dd
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date:   Fri Jan 4 09:56:10 2019 +0100

    drm: Auto-set allow_fb_modifiers when given modifiers at plane init

this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is the case here for both komeda and
malidp.
Acked-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Cc: "James (Qian) Wang" <james.qian.wang@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Mihail Atanassov <mihail.atanassov@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-1-daniel.vetter@ffwll.ch

Replace the open coded drm_mode_is_420_only() with the real thing.

No functional changes.

Cc: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210504102742.7005-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

LONTIUM_LT8912B uses "drm_display_mode_to_videomode" from
DRM framework that needs VIDEOMODE_HELPERS to be enabled.

Fixes: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Reported-by: NMichal Suchánek <msuchanek@suse.de>
Signed-off-by: NAdrien Grassein <adrien.grassein@gmail.com>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210504220207.4004511-1-adrien.grassein@gmail.com

Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: NDavid M Nieto <David.Nieto@amd.com>
Signed-off-by: NRoy Sun <Roy.Sun@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210426062701.39732-2-Roy.Sun@amd.com

Update the timestamp of scheduled fence on HW
completion of the previous fences

This allow more accurate tracking of the fence
execution in HW

v2 (chk): drop the flag check and improve the comment
Signed-off-by: NDavid M Nieto <david.nieto@amd.com>
Signed-off-by: NRoy Sun <Roy.Sun@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210426062701.39732-1-Roy.Sun@amd.com

TTM uses drm-misc now.  Update the tree.

Cc: David Ward <david.ward@gatech.edu>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210503134736.1467003-1-alexander.deucher@amd.com

The ti_sn_gpio_unregister() is not just called from the remove path
but also from the error handling of the init path. That means it can't
have the __exit annotation.

Fixes: bf73537f ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210504073845.1.Ibf4194f4252846edaa0c6a6c7b86588f75ad5529@changeid

Include the header for the prototype.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210503142710.153369-1-christian.koenig@amd.com

It doesn't make sense to go out to the bus and read the EDID over and
over again. Let's cache it and throw away the cache when we turn power
off from the panel. Autosuspend means that even if there are several
calls to read the EDID before we officially turn the power on then we
should get good use out of this cache.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.18.If050957eaa85cf45b10bcf61e6f7fa61c9750ebf@changeid

I don't believe that it ever makes sense to read the EDID when a panel
is not powered and the powering on of the panel is the job of
prepare(). Let's make sure that this happens before we try to read the
EDID. We use the pm_runtime functions directly rather than directly
calling the normal prepare() function because the pm_runtime functions
are definitely refcounted whereas it's less clear if the prepare() one
is.

NOTE: I'm not 100% sure how EDID reading was working for folks in the
past, but I can only assume that it was failing on the initial attempt
and then working only later. This patch, presumably, will fix that. If
some panel out there really can read the EDID without powering up and
it's a big advantage to preserve the old behavior we can add a
per-panel flag. It appears that providing the DDC bus to the panel in
the past was somewhat uncommon in any case.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.17.Ibd31b8f7c73255d68c5c9f5b611b4bfaa036f727@changeid

As of commit 5186421c ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.16.Icb581b0273d95cc33ca38676c61ae6d7d2e75357@changeid

Let's reorganize how we init and turn on the reference clock in the
code to allow us to turn it on early (even before pre_enable()) so
that we can read the EDID early. This is handy for eDP because:
- We always assume that a panel is there.
- Once we report that a panel is there we get asked to read the EDID.
- Pre-enable isn't called until we know what pixel clock we want to
  use and we're ready to turn everything on. That's _after_ we get
  asked to read the EDID.

NOTE: the above only works out OK if we "refclk" is provided. Though I
don't have access to any hardware that uses ti-sn65dsi86 and _doesn't_
provide a "refclk", I believe that we'll have trouble reading the EDID
at bootup in that case. Specifically I believe that if there's no
"refclk" we need the MIPI source clock to be active before we can
successfully read the EDID. My evidence here is that, in testing, I
couldn't read the EDID until I turned on the DPPLL in the bridge chip
and that the DPPLL needs the input clock to be active.

Since this is hard to support, let's punt trying to handle this case
if there's no "refclk". In that case we'll enable comms in
pre_enable() like we always did.

I don't believe there are any users of the ti-sn65dsi86 bridge chip
that _don't_ use "refclk". The bridge chip is _very_ inflexible in
that mode. The only time I've seen that mode used was for some really
early prototype hardware that was thrown in the e-waste bin years ago
when we realized how inflexible it was.

Even if someone is using the bridge chip without the "refclk" they're
in no worse shape than they were before the (fairly recent) commit
58074b08 ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.13.Ie8cf556114953c6e7634564cc0d3ddbd103cb96c@changeid

No functional changes--this just makes the diffstat of a future change
easier to understand.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.12.I047b8c7c6a3fc60eaca473da7a374f171fb021c2@changeid

Let's make the bridge use autosuspend with a 500ms delay. This is in
preparation for promoting DP AUX transfers to their own sub-driver so
that we're not constantly powering up and down the device as we
transfer all the chunks.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.11.I4c0b4a87e4dc19e5023b4d0a21bbfa6d9c09ebd8@changeid

When I added support for the hpd-gpio to simple-panel in commit
48834e60 ("drm/panel-simple: Support hpd-gpios for delaying
prepare()"), I added a special case to handle a circular dependency I
was running into on the ti-sn65dsi86 bridge chip. On my board the
hpd-gpio is actually provided by the bridge chip. That was causing
some circular dependency problems that I had to work around by getting
the hpd-gpio late.

I've now reorganized the ti-sn65dsi86 bridge chip driver to be a
collection of sub-drivers. Now the GPIO part can probe separately and
that breaks the chain. Let's get rid of the old code to clean things
up.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.10.I40eeedc23459d1e3fc96fa6cdad775d88c6e706c@changeid

Let's use the newly minted aux bus to break up the driver into sub
drivers. We're not doing a full breakup here: all the code is still in
the same file and remains largely untouched. The big goal here of
using sub-drivers is to allow part of our code to finish probing even
if some other code needs to defer. This can solve some chicken-and-egg
problems. Specifically:
- In commit 48834e60 ("drm/panel-simple: Support hpd-gpios for
  delaying prepare()") we had to add a bit of a hack to simpel-panel
  to support HPD showing up late. We can get rid of that hack now
  since the GPIO part of our driver can finish probing early.
- We have a desire to expose our DDC bus to simple-panel (and perhaps
  to a backlight driver?). That will end up with the same
  chicken-and-egg problem. A future patch to move this to a sub-driver
  will fix it.
- If/when we support the PWM functionality present in the bridge chip
  for a backlight we'll end up with another chicken-and-egg
  problem. If we allow the PWM to be a sub-driver too then it solves
  this problem.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.9.I3e68fa38c4ccbdbdf145cad2b01e83a1e5eac302@changeid

This is just code motion of the probe routine to move all the things
that are for the "whole chip" (instead of the GPIO parts or the
MIPI-to-eDP parts) together at the start of probe. This is in
preparation for breaking the driver into sub-drivers.

Since we're using devm for all of the "whole chip" stuff this is
actually quite easy now.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.8.Ide8ba40feb2e43bc98a11edbb08d696d62dcd83e@changeid

Let's:
- Set the drvdata as soon as it's allocated. This just sets up a
  pointer so there's no downside here.
- Remove the useless call to i2c_set_clientdata() which is literally
  the same thing as dev_set_drvdata().

No functional changes intended.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.7.If5d4d4e22e97bebcd493b76765c1759527705620@changeid

Tiny cleanup for probe so we don't keep having to specify
"&client->dev" or "pdata->dev". No functional changes intended.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.6.I83925d8ca228bdc5f55b17854c90754efc6a470e@changeid

Let's cleanup the debugfs code to:
- Check for errors.
- Use devm to manage freeing, which also means we don't need to store
  a pointer in our structure.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.5.I5fe072753290c6a77eda736ebd5778e17b7cb0fb@changeid

There's no devm_runtime_enable(), but it's easy to use
devm_add_action_or_reset() and means we don't need to worry about the
disable in our remove() routine or in error paths.

No functional changes intended by this change.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.4.I1e627eb5f316c0cf6595b120e6e262f5bf890300@changeid

Like the previous patch ("drm/bridge: ti-sn65dsi86: Rename the main
driver data structure") this is just a no-op rename in preparation for
splitting the driver up a bit.

Here I've attempted to rename functions / structures making sure that
anything applicable to the whole chip (instead of just the MIPI to eDP
bridge part) included "sn65dsi86" somewhere in the name instead of
just "ti_sn_bridge".
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.3.I4b28c737933a44548662df42ccd37db89ec739c1@changeid

In preparation for splitting this driver into sub-drivers, let's
rename the main data structure so it's clear that it's holding data
for the whole device and not just the MIPI-eDP bridge part.

This is a no-op change.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.2.Ib03e88304a9ea1c503f1b9567be5cbf8b7c5761c@changeid

The field pdev in struct drm_device is unused. Remove it. The
value can be obtained by upcasting from the structure's dev field.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-8-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-7-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-6-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-5-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-4-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-3-tzimmermann@suse.de

Replace all references to struct drm_device's pdev field with
an upcast from dev.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-2-tzimmermann@suse.de

Drop the special handling here.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-3-christian.koenig@amd.com