- 07 May, 2021 7 commits
-
-
Lyude Paul authored
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: 3d3721cc ("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
-
Christophe JAILLET authored
'ret' is known to be 0 here. No error code is available, so just remove it from the error message. Fixes: 72330b0e ("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
-
Maxime Ripard authored
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
-
Maxime Ripard authored
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:
-
Dave Stevenson authored
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 authored
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 authored
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:
-
- 06 May, 2021 7 commits
-
-
Wan Jiabing authored
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:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Daniel Vetter authored
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:
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
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Daniel Vetter authored
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:
Philippe Cornu <philippe.cornu@st.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
- 05 May, 2021 5 commits
-
-
Daniel Vetter authored
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:
-
Ville Syrjälä authored
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:
-
Adrien Grassein authored
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:
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:
-
Roy Sun authored
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:
-
Roy Sun authored
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:
-
- 04 May, 2021 3 commits
-
-
Alex Deucher authored
TTM uses drm-misc now. Update the tree. Cc: David Ward <david.ward@gatech.edu> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210503134736.1467003-1-alexander.deucher@amd.com
-
Douglas Anderson authored
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:
kernel test robot <lkp@intel.com> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
Christian König authored
Include the header for the prototype. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210503142710.153369-1-christian.koenig@amd.com
-
- 03 May, 2021 18 commits
-
-
Douglas Anderson authored
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:
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
-
Douglas Anderson authored
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 authored
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:
-
Douglas Anderson authored
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:
-
Douglas Anderson authored
No functional changes--this just makes the diffstat of a future change easier to understand. Signed-off-by:
-
Douglas Anderson authored
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 authored
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:
-
Douglas Anderson authored
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:
-
Douglas Anderson authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Thomas Zimmermann authored
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:
-
Thomas Zimmermann authored
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by:
-
Thomas Zimmermann authored
Replace all references to struct drm_device's pdev field with an upcast from dev. Signed-off-by:
-
