summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-05-10drm/radeon: Move AGP helpers into radeon driverThomas Zimmermann3-8/+104
Radeon calls DRMs core AGP helpers. These helpers are only required by legacy drivers. Reimplement the code in radeon to uncouple radeon from the legacy code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507185709.22797-2-tzimmermann@suse.de
2021-05-07drm/dp: Drop open-coded drm_dp_is_branch() in drm_dp_read_downstream_info()Lyude Paul1-3/+1
Noticed this while fixing another issue in drm_dp_read_downstream_info(), the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what we already do in drm_dp_is_branch(), so just get rid of it. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430223428.10514-2-lyude@redhat.com
2021-05-07drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()Lyude Paul1-0/+7
While the DP specification isn't entirely clear on if this should be allowed or not, some branch devices report having downstream ports present while also reporting a downstream port count of 0. So to avoid breaking those devices, we need to handle this in drm_dp_read_downstream_info(). So, to do this we assume there's no downstream port info when the downstream port count is 0. Signed-off-by: Lyude Paul <lyude@redhat.com> Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416 Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()") Cc: <stable@vger.kernel.org> # v5.10+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430223428.10514-1-lyude@redhat.com
2021-05-07video: fbdev: imxfb: Fix an error messageChristophe JAILLET1-1/+1
'ret' is known to be 0 here. No error code is available, so just remove it from the error message. Fixes: 72330b0eeefc ("i.MX Framebuffer: Use readl/writel instead of direct pointer deref") Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/d7b25026f82659da3c6f7159eea480faa9d738be.1620327302.git.christophe.jaillet@wanadoo.fr
2021-05-07drm/vc4: hdmi: Signal the proper colorimetry info in the infoframeMaxime Ripard1-2/+8
Our driver while supporting HDR didn't send the proper colorimetry info in the AVI infoframe. Let's add the property needed so that the userspace can let us know what the colorspace is supposed to be. Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-5-maxime@cerno.tech
2021-05-07drm/connector: Add a helper to attach the colorspace propertyMaxime Ripard3-4/+23
The intel driver uses the same logic to attach the Colorspace property in multiple places and we'll need it in vc4 too. Let's move that common code in a helper. Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-4-maxime@cerno.tech
2021-05-07drm/vc4: Add HDR metadata property to the VC5 HDMI connectorsDave Stevenson2-0/+56
Now that we can export deeper colour depths, add in the signalling for HDR metadata. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-3-maxime@cerno.tech
2021-05-07drm/connector: Add helper to compare HDR metadataMaxime Ripard5-49/+34
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: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-2-maxime@cerno.tech
2021-05-07drm/connector: Create a helper to attach the hdr_output_metadata propertyMaxime Ripard5-7/+25
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: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210430094451.2145002-1-maxime@cerno.tech
2021-05-06drm/gma500: update comment of psb_spank()Wan Jiabing1-1/+1
In commit 5c209d8056b9 ("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: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210506112851.20315-1-wanjiabing@vivo.com
2021-05-06drm/nouveau: Don't set allow_fb_modifiers explicitlyDaniel Vetter1-1/+0
Since commit 890880ddfdbe256083170866e49c87618b706ac7 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: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org # v5.1 + Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Daniel 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
2021-05-06drm/msm/mdp4: Fix modifier support enablingDaniel Vetter2-3/+7
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: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Lyude 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: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-5-daniel.vetter@ffwll.ch
2021-05-06drm/msm/dpu1: Don't set allow_fb_modifiers explicitlyDaniel Vetter1-5/+0
Since commit 890880ddfdbe256083170866e49c87618b706ac7 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: Lyude Paul <lyude@redhat.com> Signed-off-by: Daniel 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
2021-05-06drm/i915: Don't set allow_fb_modifiers explicitlyDaniel Vetter1-2/+0
Since commit 890880ddfdbe256083170866e49c87618b706ac7 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: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Daniel 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
2021-05-06drm/stm: Don't set allow_fb_modifiers explicitlyDaniel Vetter1-2/+0
Since commit 890880ddfdbe256083170866e49c87618b706ac7 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: Philippe Cornu <philippe.cornu@st.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Daniel 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
2021-05-06drm/arm/malidp: Always list modifiersDaniel Vetter1-2/+7
Even when all we support is linear, make that explicit. Otherwise the uapi is rather confusing. Acked-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Lyude 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: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-2-daniel.vetter@ffwll.ch
2021-05-05drm/arm: Don't set allow_fb_modifiers explicitlyDaniel Vetter2-2/+0
Since commit 890880ddfdbe256083170866e49c87618b706ac7 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: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Daniel 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
2021-05-05drm: Use drm_mode_is_420_only() instead of open coding itVille Syrjälä1-9/+4
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210504102742.7005-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-05-05drm/bridge: fix LONTIUM_LT8912B dependenciesAdrien Grassein1-0/+1
LONTIUM_LT8912B uses "drm_display_mode_to_videomode" from DRM framework that needs VIDEOMODE_HELPERS to be enabled. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Reported-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210504220207.4004511-1-adrien.grassein@gmail.com
2021-05-05drm/amdgpu: Add show_fdinfo() interfaceRoy Sun11-2/+288
Tracking devices, process info and fence info using /proc/pid/fdinfo Signed-off-by: David M Nieto <David.Nieto@amd.com> Signed-off-by: Roy Sun <Roy.Sun@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210426062701.39732-2-Roy.Sun@amd.com
2021-05-05drm/scheduler: Change scheduled fence track v2Roy Sun1-1/+8
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: David M Nieto <david.nieto@amd.com> Signed-off-by: Roy Sun <Roy.Sun@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210426062701.39732-1-Roy.Sun@amd.com
2021-05-04MAINTAINERS: Fix TTM treeAlex Deucher1-1/+1
TTM uses drm-misc now. Update the tree. Cc: David Ward <david.ward@gatech.edu> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210503134736.1467003-1-alexander.deucher@amd.com
2021-05-04drm/bridge: ti-sn65dsi86: Remove __exit from GPIO sub-driver remove helperDouglas Anderson1-1/+1
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: bf73537f411b ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210504073845.1.Ibf4194f4252846edaa0c6a6c7b86588f75ad5529@changeid
2021-05-04drm/ttm: fix warning in new sys manChristian König1-0/+2
Include the header for the prototype. Signed-off-by: Christian König <christian.koenig@amd.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210503142710.153369-1-christian.koenig@amd.com
2021-05-03drm/panel: panel-simple: Cache the EDID as long as we retain powerDouglas Anderson1-7/+10
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.18.If050957eaa85cf45b10bcf61e6f7fa61c9750ebf@changeid
2021-05-03drm/panel: panel-simple: Power the panel when reading the EDIDDouglas Anderson1-1/+7
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.17.Ibd31b8f7c73255d68c5c9f5b611b4bfaa036f727@changeid
2021-05-03drm/panel: panel-simple: Remove extra call: drm_connector_update_edid_property()Douglas Anderson1-1/+0
As of commit 5186421cbfe2 ("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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.16.Icb581b0273d95cc33ca38676c61ae6d7d2e75357@changeid
2021-05-03drm/bridge: ti-sn65dsi86: If refclk, DP AUX can happen w/out pre-enableDouglas Anderson1-35/+94
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 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"). Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.13.Ie8cf556114953c6e7634564cc0d3ddbd103cb96c@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Code motion of refclk management functionsDouglas Anderson1-58/+58
No functional changes--this just makes the diffstat of a future change easier to understand. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.12.I047b8c7c6a3fc60eaca473da7a374f171fb021c2@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Use pm_runtime autosuspendDouglas Anderson1-6/+8
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.11.I4c0b4a87e4dc19e5023b4d0a21bbfa6d9c09ebd8@changeid
2021-05-03drm/panel: panel-simple: Get rid of hacky HPD chicken-and-egg codeDouglas Anderson1-19/+5
When I added support for the hpd-gpio to simple-panel in commit 48834e6084f1 ("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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.10.I40eeedc23459d1e3fc96fa6cdad775d88c6e706c@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-driversDouglas Anderson2-53/+200
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 48834e6084f1 ("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: Douglas Anderson <dianders@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.9.I3e68fa38c4ccbdbdf145cad2b01e83a1e5eac302@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Move all the chip-related init to the startDouglas Anderson1-13/+13
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.8.Ide8ba40feb2e43bc98a11edbb08d696d62dcd83e@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Cleanup managing of drvdataDouglas Anderson1-6/+2
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.7.If5d4d4e22e97bebcd493b76765c1759527705620@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Add local var for "dev" to simplify probeDouglas Anderson1-14/+12
Tiny cleanup for probe so we don't keep having to specify "&client->dev" or "pdata->dev". No functional changes intended. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.6.I83925d8ca228bdc5f55b17854c90754efc6a470e@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Clean debugfs codeDouglas Anderson1-12/+21
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: Douglas Anderson <dianders@chromium.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.5.I5fe072753290c6a77eda736ebd5778e17b7cb0fb@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Use devm to do our runtime_disableDouglas Anderson1-5/+9
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.4.I1e627eb5f316c0cf6595b120e6e262f5bf890300@changeid
2021-05-03drm/bridge: ti-sn65dsi86: More renames in prep for sub-devicesDouglas Anderson1-42/+42
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.3.I4b28c737933a44548662df42ccd37db89ec739c1@changeid
2021-05-03drm/bridge: ti-sn65dsi86: Rename the main driver data structureDouglas Anderson1-43/+43
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: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.2.Ib03e88304a9ea1c503f1b9567be5cbf8b7c5761c@changeid
2021-05-03drm: Remove pdev field from struct drm_deviceThomas Zimmermann2-4/+0
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: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-8-tzimmermann@suse.de
2021-05-03drm/via: Remove references to drm_device.pdevThomas Zimmermann2-7/+11
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-7-tzimmermann@suse.de
2021-05-03drm/sis: Remove references to struct drm_device.pdevThomas Zimmermann1-1/+2
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-6-tzimmermann@suse.de
2021-05-03drm/savage: Remove references to struct drm_device.pdevThomas Zimmermann1-12/+14
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-5-tzimmermann@suse.de
2021-05-03drm/r128: Remove references to struct drm_device.pdevThomas Zimmermann3-7/+11
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-4-tzimmermann@suse.de
2021-05-03drm/mga: Remove references to struct drm_device.pdevThomas Zimmermann2-7/+9
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-3-tzimmermann@suse.de
2021-05-03drm/i810: Remove references to struct drm_device.pdevThomas Zimmermann1-3/+5
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210502104953.21768-2-tzimmermann@suse.de
2021-05-03drm/ttm: properly allocate sys resource during swapoutChristian König1-5/+7
Drop the special handling here. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-3-christian.koenig@amd.com
2021-05-03drm/ttm: always initialize the full ttm_resource v2Christian König4-27/+16
Init all fields in ttm_resource_alloc() when we create a new resource. v2: use place->mem_type instead of res->mem_type Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-2-christian.koenig@amd.com
2021-05-03drm/ttm: add ttm_sys_manager v3Christian König5-25/+47
Add a separate manager for the system domain and make function tables mandatory. v2: debug is still optional v3: return void during init Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210430092508.60710-1-christian.koenig@amd.com
2021-05-03drm/ttm: cleanup ttm_agp_backendChristian König1-4/+4
Audit the includes and stop accessing the internal drm_mm_node. The ttm_resource::start is the same value as the drm_mm_node::start. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210426175824.122557-1-christian.koenig@amd.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-05 18:00:02 +0000