Re: [PATCH 07/22] drm/i2c/tda998x: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i2c/tda998x_drv.c:2018:8: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror,-Wimplicit-function-declaration]
ret = drm_simple_encoder_init(drm, &priv->encoder,
^
drivers/gpu/drm/i2c/tda998x_drv.c:2018:8: note: did you mean
'drm_encoder_init'?
include/drm/drm_encoder.h:189:5: note: 'drm_encoder_init' declared here
int drm_encoder_init(struct drm_device *dev,
^
1 error generated.
vim +/drm_simple_encoder_init +2018 drivers/gpu/drm/i2c/tda998x_drv.c
2000
2001 static int tda998x_encoder_init(struct device *dev, struct drm_device
*drm)
2002 {
2003 struct tda998x_priv *priv = dev_get_drvdata(dev);
2004 u32 crtcs = 0;
2005 int ret;
2006
2007 if (dev->of_node)
2008 crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
2009
2010 /* If no CRTCs were found, fall back to our old behaviour */
2011 if (crtcs == 0) {
2012 dev_warn(dev, "Falling back to first CRTC\n");
2013 crtcs = 1 << 0;
2014 }
2015
2016 priv->encoder.possible_crtcs = crtcs;
2017
> 2018 ret = drm_simple_encoder_init(drm, &priv->encoder,
2019DRM_MODE_ENCODER_TMDS);
2020 if (ret)
2021 goto err_encoder;
2022
2023 ret = drm_bridge_attach(&priv->encoder, &priv->bridge, NULL, 0);
2024 if (ret)
2025 goto err_bridge;
2026
2027 return 0;
2028
2029 err_bridge:
2030 drm_encoder_cleanup(&priv->encoder);
2031 err_encoder:
2032 return ret;
2033 }
2034
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Add the load and unload for hibmc_driver
Hi
Am 06.03.20 um 04:42 schrieb Tian Tao:
> using the load and unload function provided by drm framework instead of
> doing the same work in the hibmc_pci_probe and do some code cleanup.
>
> Signed-off-by: Tian Tao
> Signed-off-by: Gong junjie
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 62
> +
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
> 2 files changed, 24 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 79a180a..51f1c70 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -23,7 +23,7 @@
> #include
> #include
> #include
> -
> +#include
> #include "hibmc_drm_drv.h"
> #include "hibmc_drm_regs.h"
>
> @@ -49,6 +49,8 @@ static irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>
> static struct drm_driver hibmc_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> + .load = hibmc_load,
> + .unload = hibmc_unload,
These callbacks are deprecated and not to be used. During the last weeks
and months, we've been working on removing them from the other remaining
drivers. Therefore nak.
Best regards
Thomas
> .fops = &hibmc_fops,
> .name = "hibmc",
> .date = "20160828",
> @@ -232,6 +234,21 @@ static int hibmc_hw_map(struct hibmc_drm_private *priv)
> return 0;
> }
>
> +static void hibmc_hw_unmap(struct hibmc_drm_private *priv)
> +{
> + struct drm_device *dev = priv->dev;
> +
> + if (priv->mmio) {
> + devm_iounmap(dev->dev, priv->mmio);
> + priv->mmio = NULL;
> + }
> +
> + if (priv->fb_map) {
> + devm_iounmap(dev->dev, priv->fb_map);
> + priv->fb_map = NULL;
> + }
> +}
> +
> static int hibmc_hw_init(struct hibmc_drm_private *priv)
> {
> int ret;
> @@ -245,7 +262,7 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
> return 0;
> }
>
> -static int hibmc_unload(struct drm_device *dev)
> +void hibmc_unload(struct drm_device *dev)
> {
> struct hibmc_drm_private *priv = dev->dev_private;
>
> @@ -258,11 +275,12 @@ static int hibmc_unload(struct drm_device *dev)
>
> hibmc_kms_fini(priv);
> hibmc_mm_fini(priv);
> + hibmc_hw_unmap(priv);
> dev->dev_private = NULL;
> return 0;
> }
>
> -static int hibmc_load(struct drm_device *dev)
> +int hibmc_load(struct drm_device *dev, unsigned long flags)
> {
> struct hibmc_drm_private *priv;
> int ret;
> @@ -332,43 +350,7 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
> if (ret)
> return ret;
>
> - dev = drm_dev_alloc(&hibmc_driver, &pdev->dev);
> - if (IS_ERR(dev)) {
> - DRM_ERROR("failed to allocate drm_device\n");
> - return PTR_ERR(dev);
> - }
> -
> - dev->pdev = pdev;
> - pci_set_drvdata(pdev, dev);
> -
> - ret = pci_enable_device(pdev);
> - if (ret) {
> - DRM_ERROR("failed to enable pci device: %d\n", ret);
> - goto err_free;
> - }
> -
> - ret = hibmc_load(dev);
> - if (ret) {
> - DRM_ERROR("failed to load hibmc: %d\n", ret);
> - goto err_disable;
> - }
> -
> - ret = drm_dev_register(dev, 0);
> - if (ret) {
> - DRM_ERROR("failed to register drv for userspace access: %d\n",
> - ret);
> - goto err_unload;
> - }
> - return 0;
> -
> -err_unload:
> - hibmc_unload(dev);
> -err_disable:
> - pci_disable_device(pdev);
> -err_free:
> - drm_dev_put(dev);
> -
> - return ret;
> + return drm_get_pci_dev(pdev, ent, &hibmc_driver);
> }
>
> static void hibmc_pci_remove(struct pci_dev *pdev)
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 50a0c1f..4e89cd7 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -37,6 +37,8 @@ void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> void hibmc_set_current_gate(struct hibmc_drm_private *priv,
> unsigned int gate);
>
> +int hibmc_load(struct drm_device *dev, unsigned long flags);
> +void hibmc_unload(struct drm_device *dev);
> int hibmc_de_init(struct hibmc_drm_private *priv);
> int hibmc_vdac_init(struct hibmc_drm_private *priv);
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.o
Re: [PATCH 06/22] drm/hisilicon/kirin: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu//drm/hisilicon/kirin/dw_drm_dsi.c:713:8: error: implicit
>> declaration of function 'drm_simple_encoder_init'
>> [-Werror,-Wimplicit-function-declaration]
ret = drm_simple_encoder_init(drm_dev, encoder,
DRM_MODE_ENCODER_DSI);
^
drivers/gpu//drm/hisilicon/kirin/dw_drm_dsi.c:713:8: note: did you mean
'drm_i2c_encoder_init'?
include/drm/drm_encoder_slave.h:104:5: note: 'drm_i2c_encoder_init' declared
here
int drm_i2c_encoder_init(struct drm_device *dev,
^
1 error generated.
vim +/drm_simple_encoder_init +713 drivers/gpu//drm/hisilicon/kirin/dw_drm_dsi.c
699
700 static int dw_drm_encoder_init(struct device *dev,
701 struct drm_device *drm_dev,
702 struct drm_encoder *encoder)
703 {
704 int ret;
705 u32 crtc_mask = drm_of_find_possible_crtcs(drm_dev,
dev->of_node);
706
707 if (!crtc_mask) {
708 DRM_ERROR("failed to find crtc mask\n");
709 return -EINVAL;
710 }
711
712 encoder->possible_crtcs = crtc_mask;
> 713 ret = drm_simple_encoder_init(drm_dev, encoder,
> DRM_MODE_ENCODER_DSI);
714 if (ret) {
715 DRM_ERROR("failed to init dsi encoder\n");
716 return ret;
717 }
718
719 drm_encoder_helper_add(encoder, &dw_encoder_helper_funcs);
720
721 return 0;
722 }
723
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Thu, Mar 05, 2020 at 05:11:57PM +0100, Karol Herbst wrote: > On Wed, Mar 4, 2020 at 10:33 AM Mika Westerberg > wrote: > > > > Hi, > > > > On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote: > > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher > > > device > > > states. > > > > I think it is good to explain bit more here why this fix is needed. > > > > is something like this fine? > > Fixes the infamous 'runpm' bug many users are facing on Laptops with Nvidia > Pascal GPUs by skipping PCI power state changes on the GPU. I would open up 'runpm' -> runtime PM. > It's still unknown why this issue exists, but this is a reliable workaround > and solves a very annoying issue for user having to choose between a > crashing kernel or higher power consumption of their Laptops. Also I think it would be good to include a short log snippet how this manifests and in what kind of scenario it happens. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/22] drm/exynos: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/exynos/exynos_drm_dsi.c:1705:2: error: implicit declaration
>> of function 'drm_simple_encoder_init'
>> [-Werror,-Wimplicit-function-declaration]
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
^
drivers/gpu/drm/exynos/exynos_drm_dsi.c:1705:2: note: did you mean
'drm_encoder_init'?
include/drm/drm_encoder.h:189:5: note: 'drm_encoder_init' declared here
int drm_encoder_init(struct drm_device *dev,
^
1 error generated.
--
>> drivers/gpu/drm/exynos/exynos_hdmi.c:1851:2: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror,-Wimplicit-function-declaration]
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
^
drivers/gpu/drm/exynos/exynos_hdmi.c:1851:2: note: did you mean
'drm_encoder_init'?
include/drm/drm_encoder.h:189:5: note: 'drm_encoder_init' declared here
int drm_encoder_init(struct drm_device *dev,
^
1 error generated.
vim +/drm_simple_encoder_init +1705 drivers/gpu/drm/exynos/exynos_drm_dsi.c
1695
1696 static int exynos_dsi_bind(struct device *dev, struct device *master,
1697 void *data)
1698 {
1699 struct drm_encoder *encoder = dev_get_drvdata(dev);
1700 struct exynos_dsi *dsi = encoder_to_dsi(encoder);
1701 struct drm_device *drm_dev = data;
1702 struct drm_bridge *in_bridge;
1703 int ret;
1704
> 1705 drm_simple_encoder_init(drm_dev, encoder,
> DRM_MODE_ENCODER_TMDS);
1706
1707 drm_encoder_helper_add(encoder,
&exynos_dsi_encoder_helper_funcs);
1708
1709 ret = exynos_drm_set_possible_crtcs(encoder,
EXYNOS_DISPLAY_TYPE_LCD);
1710 if (ret < 0)
1711 return ret;
1712
1713 if (dsi->in_bridge_node) {
1714 in_bridge = of_drm_find_bridge(dsi->in_bridge_node);
1715 if (in_bridge)
1716 drm_bridge_attach(encoder, in_bridge, NULL, 0);
1717 }
1718
1719 return mipi_dsi_host_register(&dsi->dsi_host);
1720 }
1721
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/4] RFC: drm/panfrost: devfreq: Add support for 2 regulators
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
devfreq, and provides OPP table with 2 sets of voltages.
TODO: This is incomplete as we'll need add support for setting
a pair of voltages as well. I also realized that the out-of-tree
driver has complex logic to ensure voltage delta between the
regulators stays within a specific range, so we'd need to port
that as well.
Signed-off-by: Nicolas Boichat
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbfccb..9c0987a3d71c597 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -79,6 +79,21 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ /* If we have 2 regulator, we need an OPP table with 2 voltages. */
+ if (pfdev->comp->num_supplies > 1) {
+ pfdev->devfreq.dev_opp_table =
+ dev_pm_opp_set_regulators(dev,
+ pfdev->comp->supply_names,
+ pfdev->comp->num_supplies);
+ if (IS_ERR(pfdev->devfreq.dev_opp_table)) {
+ ret = PTR_ERR(pfdev->devfreq.dev_opp_table);
+ pfdev->devfreq.dev_opp_table = NULL;
+ dev_err(dev,
+ "Failed to init devfreq opp table: %d\n", ret);
+ return ret;
+ }
+ }
+
ret = dev_pm_opp_of_add_table(dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
return 0;
@@ -119,6 +134,8 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
+ if (pfdev->devfreq.dev_opp_table)
+ dev_pm_opp_put_regulators(pfdev->devfreq.dev_opp_table);
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index c30c719a805940a..5009a8b7c853ea1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -110,6 +110,7 @@ struct panfrost_device {
struct {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ struct opp_table *dev_opp_table;
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
--
2.25.1.481.gfbce0eb801-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: komeda: Make rt_pm_ops dependent on CONFIG_PM
On Fri, Mar 06, 2020 at 02:42:55AM +0800, Liviu Dudau wrote:
> On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
> > komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
> > CONFIG_PM is enabled. Having it disabled triggers the following warning
> > at compile time:
> >
> > linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12:
> > warning: ‘komeda_rt_pm_resume’ defined but not used [-Wunused-function]
> > static int komeda_rt_pm_resume(struct device *dev)
> > ^~~
> > linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12:
> > warning: ‘komeda_rt_pm_suspend’ defined but not used [-Wunused-function]
> > static int komeda_rt_pm_suspend(struct device *dev)
> >
> > Make komeda_rt_pm_suspend() and komeda_rt_pm_resume() dependent on
> > CONFIG_PM to address the issue.
> >
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Mihail Atanassov
> > Cc: Brian Starkey
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Signed-off-by: Vincenzo Frascino
>
Hi Vincenzo:
Thanks for the patch.
and Vincenzo & Liviu, sorry
Since there is a patch for this problem already:
https://patchwork.freedesktop.org/series/71721/
And I have pushed that old fix to drm-misc-fixes just before I saw
this mail. sorry.
> Acked-by: Liviu Dudau
>
> Thanks for the patch, I will push it into drm-misc-fixes tomorrow.
>
> Best regards,
> Liviu
>
> > ---
> > drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > index ea5cd1e17304..dd3ae3d88687 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> > @@ -146,6 +146,7 @@ static const struct of_device_id komeda_of_match[] = {
> >
> > MODULE_DEVICE_TABLE(of, komeda_of_match);
> >
> > +#ifdef CONFIG_PM
> > static int komeda_rt_pm_suspend(struct device *dev)
> > {
> > struct komeda_drv *mdrv = dev_get_drvdata(dev);
> > @@ -159,6 +160,7 @@ static int komeda_rt_pm_resume(struct device *dev)
> >
> > return komeda_dev_resume(mdrv->mdev);
> > }
> > +#endif /* CONFIG_PM */
> >
> > static int __maybe_unused komeda_pm_suspend(struct device *dev)
> > {
> > --
> > 2.25.1
> >
>
> --
>
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---
> ¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat Reviewed-by: Alyssa Rosenzweig --- v5: - Rename "2d" power domain to "core2" v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) v3: - No change .../bindings/gpu/arm,mali-bifrost.yaml| 25 +++ 1 file changed, 25 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index e8b99adcb1bd292..c5ceca513192f99 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -62,6 +63,30 @@ allOf: minItems: 2 required: - resets + - if: + properties: +compatible: + contains: +const: mediatek,mt8183-mali +then: + properties: +sram-supply: true +power-domains: + description: +List of phandle and PM domain specifier as documented in +Documentation/devicetree/bindings/power/power_domain.txt + minItems: 3 + maxItems: 3 +power-domain-names: + items: +- const: core0 +- const: core1 +- const: core2 + + required: +- sram-supply +- power-domains +- power-domains-names examples: - | -- 2.25.1.481.gfbce0eb801-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/4] Add dts for mt8183 GPU (and misc panfrost patches)
Hi! Follow-up on the v4: https://patchwork.kernel.org/cover/11369777/, some of the core patches got merged already (thanks Rob!). The main purpose of this series is to upstream the dts change and the binding document, but I wanted to see how far I could probe the GPU, to check that the binding is indeed correct. The rest of the patches are RFC/work-in-progress. So this is tested on MT8183 with a chromeos-4.19 kernel, and a ton of backports to get the latest panfrost driver (I should probably try on linux-next at some point but this was the path of least resistance). I tested it as a module as it's more challenging (originally probing would work built-in, on boot, but not as a module, as I didn't have the power domain changes, and all power domains are on by default during boot). Probing logs looks like this, currently. They look sane. [ 501.319728] panfrost 1304.gpu: clock rate = 51170 [ 501.320041] panfrost 1304.gpu: Linked as a consumer to regulator.14 [ 501.320102] panfrost 1304.gpu: Linked as a consumer to regulator.31 [ 501.320651] panfrost 1304.gpu: Linked as a consumer to genpd:0:1304.gpu [ 501.320954] panfrost 1304.gpu: Linked as a consumer to genpd:1:1304.gpu [ 501.321062] panfrost 1304.gpu: Linked as a consumer to genpd:2:1304.gpu [ 501.321734] panfrost 1304.gpu: mali-g72 id 0x6221 major 0x0 minor 0x3 status 0x0 [ 501.321741] panfrost 1304.gpu: features: ,13de77ff, issues: ,0400 [ 501.321747] panfrost 1304.gpu: Features: L2:0x07120206 Shader:0x Tiler:0x0809 Mem:0x1 MMU:0x2830 AS:0xff JS:0x7 [ 501.321752] panfrost 1304.gpu: shader_present=0x7 l2_present=0x1 [ 501.324951] [drm] Initialized panfrost 1.1.0 20180908 for 1304.gpu on minor 2 Some more changes are still required to get devfreq working, and of course I do not have a userspace driver to test this with. I believe at least patches 1 & 2 can be merged (2 depends on another patch series, so maybe we could start with 1 only for now...). Thanks! Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU RFC: drm/panfrost: Add mt8183-mali compatible string RFC: drm/panfrost: devfreq: Add support for 2 regulators .../bindings/gpu/arm,mali-bifrost.yaml| 25 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++ arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 17 +++ drivers/gpu/drm/panfrost/panfrost_device.h| 1 + drivers/gpu/drm/panfrost/panfrost_drv.c | 11 ++ 6 files changed, 166 insertions(+) -- 2.25.1.481.gfbce0eb801-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/4] arm64: dts: mt8183: Add node for the Mali GPU
Add a basic GPU node for mt8183.
Signed-off-by: Nicolas Boichat
Reviewed-by: Alyssa Rosenzweig
---
Upstreaming what matches existing bindings from our Chromium OS tree:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1411
The evb part of this change depends on this patch to add PMIC dtsi:
https://patchwork.kernel.org/patch/10928161/
The binding we use with out-of-tree Mali drivers includes more
clocks, this is used for devfreq: the out-of-tree driver switches
clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then
switches clk_mux back to clk_main_parent:
(see
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423)
clocks =
<&topckgen CLK_TOP_MFGPLL_CK>,
<&topckgen CLK_TOP_MUX_MFG>,
<&clk26m>,
<&mfgcfg CLK_MFG_BG3D>;
clock-names =
"clk_main_parent",
"clk_mux",
"clk_sub_parent",
"subsys_mfg_cg";
(based on discussions, this probably belongs in the clock core)
v5:
- Rename "2d" power domain to "core2" (keep R-B again).
v4:
- Add power-domain-names to describe the 3 domains.
(kept Alyssa's reviewed-by as the change is minor)
v3:
- No changes
v2:
- Use sram instead of mali_sram as SRAM supply name.
- Rename mali@ to gpu@.
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 7 ++
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 105
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 1fb195c683c3d01..7d609e0cd9b4975 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "mt8183.dtsi"
+#include "mt6358.dtsi"
/ {
model = "MediaTek MT8183 evaluation board";
@@ -30,6 +31,12 @@ &auxadc {
status = "okay";
};
+&gpu {
+ supply-names = "mali", "sram";
+ mali-supply = <&mt6358_vgpu_reg>;
+ sram-supply = <&mt6358_vsram_gpu_reg>;
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c_pins_0>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 97863adb7bc02b4..fc690c54988c8cc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -652,6 +652,111 @@ mfgcfg: syscon@1300 {
#clock-cells = <1>;
};
+ gpu: gpu@1304 {
+ compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
+ reg = <0 0x1304 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ;
+ interrupt-names = "job", "mmu", "gpu";
+
+ clocks = <&topckgen CLK_TOP_MFGPLL_CK>;
+
+ power-domains =
+ <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>,
+ <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>,
+ <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
+ power-domain-names = "core0", "core1", "core2";
+
+ operating-points-v2 = <&gpu_opp_table>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <625000>, <85>;
+ };
+
+ opp-32000 {
+ opp-hz = /bits/ 64 <32000>;
+ opp-microvolt = <631250>, <85>;
+ };
+
+ opp-34000 {
+ opp-hz = /bits/ 64 <34000>;
+ opp-microvolt = <637500>, <85>;
+ };
+
+ opp-36000 {
+ opp-hz = /bits/ 64 <36000>;
+ opp-microvolt = <643750>, <85>;
+ };
+
+ opp-38000 {
+ opp-hz = /bits/ 64 <38000>;
+ opp-microvolt = <65>, <85>;
+ };
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <656250>, <85>;
+ };
+
+ opp-42000 {
+ opp-hz = /bits/ 64 <42000>;
+ opp-microvolt = <662500>, <85>;
+ };
+
+
[PATCH v5 3/4] RFC: drm/panfrost: Add mt8183-mali compatible string
For testing only, the driver doesn't really work yet, AFAICT.
Signed-off-by: Nicolas Boichat
---
v5:
- Change power domain name from 2d to core2.
v4:
- Add power domain names.
v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
drivers/gpu/drm/panfrost/panfrost_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index a6e162236d67fdf..ff76b29b373e105 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -667,6 +667,15 @@ static const struct panfrost_compatible default_data = {
.pm_domain_names = NULL,
};
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2"
};
+static const struct panfrost_compatible mediatek_mt8183_data = {
+ .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+ .supply_names = mediatek_mt8183_supplies,
+ .num_pm_domains = 3,
+ .pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t604", .data = &default_data, },
{ .compatible = "arm,mali-t624", .data = &default_data, },
@@ -677,6 +686,8 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t830", .data = &default_data, },
{ .compatible = "arm,mali-t860", .data = &default_data, },
{ .compatible = "arm,mali-t880", .data = &default_data, },
+ { .compatible = "mediatek,mt8183-mali",
+ .data = &mediatek_mt8183_data },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.25.1.481.gfbce0eb801-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/komeda: mark PM functions as __maybe_unused
On Tue, Jan 07, 2020 at 10:53:19PM +0100, Arnd Bergmann wrote:
> Without this, we get a couple of warnings when CONFIG_PM
> is disabled:
>
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12: error:
> 'komeda_rt_pm_resume' defined but not used [-Werror=unused-function]
> static int komeda_rt_pm_resume(struct device *dev)
> ^~~
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12: error:
> 'komeda_rt_pm_suspend' defined but not used [-Werror=unused-function]
> static int komeda_rt_pm_suspend(struct device *dev)
> ^~~~
>
> Fixes: efb465088518 ("drm/komeda: Add runtime_pm support")
> Signed-off-by: Arnd Bergmann
> Reviewed-by: James Qian Wang (Arm Technology China)
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index ea5cd1e17304..e7933930a657 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -146,14 +146,14 @@ static const struct of_device_id komeda_of_match[] = {
>
> MODULE_DEVICE_TABLE(of, komeda_of_match);
>
> -static int komeda_rt_pm_suspend(struct device *dev)
> +static int __maybe_unused komeda_rt_pm_suspend(struct device *dev)
> {
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>
> return komeda_dev_suspend(mdrv->mdev);
> }
>
> -static int komeda_rt_pm_resume(struct device *dev)
> +static int __maybe_unused komeda_rt_pm_resume(struct device *dev)
> {
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>
Applied to drm-misc-fixes 9803aac7b5508718989e4cde11b854fc01037b01
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
On Fri, Mar 6, 2020 at 10:34 AM Nick Fan wrote:
>
> Sorry for my late reply.
> I have checked internally.
> The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> domain.
>
> If the naming too confusing, we can change this name to
> MT8183_POWER_DOMAIN_MFG_CORE2 for consistency.
Thanks! I think I'll keep MT8183_POWER_DOMAIN_MFG_2D (that's fine if
that's the domain name you use internally in your HW design), but I'll
modify power-domain-names to core0/1/2 in the binding.
> Thanks
>
> Nick Fan
>
> On Wed, 2020-02-26 at 08:55 +0800, Nicolas Boichat wrote:
>
> > +Nick Fan +Sj Huang @ MTK
> >
> > On Wed, Feb 26, 2020 at 1:16 AM Rob Herring wrote:
> > >
> > > On Fri, Feb 07, 2020 at 01:26:21PM +0800, Nicolas Boichat wrote:
> > > > Define a compatible string for the Mali Bifrost GPU found in
> > > > Mediatek's MT8183 SoCs.
> > > >
> > > > Signed-off-by: Nicolas Boichat
> > > > Reviewed-by: Alyssa Rosenzweig
> > > > ---
> > > >
> > > > v4:
> > > > - Add power-domain-names description
> > > >(kept Alyssa's reviewed-by as the change is minor)
> > > > v3:
> > > > - No change
> > > >
> > > > .../bindings/gpu/arm,mali-bifrost.yaml| 25 +++
> > > > 1 file changed, 25 insertions(+)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > > > b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > > > index 4ea6a8789699709..0d93b3981445977 100644
> > > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> > > > @@ -17,6 +17,7 @@ properties:
> > > > items:
> > > >- enum:
> > > >- amlogic,meson-g12a-mali
> > > > + - mediatek,mt8183-mali
> > > >- realtek,rtd1619-mali
> > > >- rockchip,px30-mali
> > > >- const: arm,mali-bifrost # Mali Bifrost GPU model/revision is
> > > > fully discoverable
> > > > @@ -62,6 +63,30 @@ allOf:
> > > >minItems: 2
> > > >required:
> > > > - resets
> > > > + - if:
> > > > + properties:
> > > > +compatible:
> > > > + contains:
> > > > +const: mediatek,mt8183-mali
> > > > +then:
> > > > + properties:
> > > > +sram-supply: true
> > > > +power-domains:
> > > > + description:
> > > > +List of phandle and PM domain specifier as documented in
> > > > +Documentation/devicetree/bindings/power/power_domain.txt
> > > > + minItems: 3
> > > > + maxItems: 3
> > > > +power-domain-names:
> > > > + items:
> > > > +- const: core0
> > > > +- const: core1
> > > > +- const: 2d
> > >
> > > AFAIK, there's no '2d' block in bifrost GPUs. A power domain for each
> > > core group is correct though.
> >
> > Good question... Hopefully Nick/SJ@MTK can comment, the non-upstream DTS
> > has:
> > gpu: mali@1304 {
> > compatible = "mediatek,mt8183-mali", "arm,mali-bifrost";
> > power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_CORE0>;
> > ...
> > }
> >
> > gpu_core1: mali_gpu_core1 {
> > compatible = "mediatek,gpu_core1";
> > power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_CORE1>;
> > };
> >
> > gpu_core2: mali_gpu_core2 {
> > compatible = "mediatek,gpu_core2";
> > power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_2D>;
> > };
> >
> > So I picked core0/core1/2d as names, but looking at this, it's likely
> > core2 is more appropriate (and MT8183_POWER_DOMAIN_MFG_2D might just
> > be a internal/legacy name, if there is no real 2d domain).
> >
> > Thanks.
> >
> > > Rob
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.6-rc5
Hi Linus, Weekly fixes round, looks like a few people woke up, got a bunch of fixes across the drivers. Bit bigger than I'd like but they all seem fine and hopefully it quiets down now. sun4i, kirin, mediatek and exynos on the ARM side. virtio-gpu and core have some mmap fixes, and there is a dma-buf leak. one ttm fence leak is also fixed. Otherwise it's mostly amdgpu and i915. One of the i915 fixes is for a very long latency I was seeing (using latencytop) running gnome-shell locally when using firefox and eating nearly all my RAM, it really helps with desktop responsiveness esp when firefox is chewing a lot. Dave. drm-fixes-2020-03-06: drm fixes for 5.6-rc5 dma-buf: - fix memory leak core: - shmem object mmap fix. ttm: - Fix fence leak in ttm_buffer_object_transfer(). amdgpu: - Gfx reset fix for gfx9, 10 - Fix for gfx10 - DP MST fix - DCC fix - Renoir power fixes - Navi power fix i915: - Break up long lists of object reclaim with cond_resched() - PSR probe fix - TGL workarounds - Selftest return value fix - Drop timeline mutex while waiting for retirement - Wait for OA configuration completion before writes to OA buffer virtio: - Fix resource id creation race in virtio. - mmap fixes sun4i: - Fixes for sun4i VI layer format support. kirin: - kirin: Revert "Fix for hikey620 display offset problem" exynos: - fix a kernel oops problem in case that driver is loaded as module. - fix a regulator warning issue when I2C DDC adapter cannot be gathered. - print out an error message only in error case excepting -EPROBE_DEFER. mediatek: - overlay, cursor and gce fixes. ` The following changes since commit 98d54f81e36ba3bf92172791eba5ca5bd813989b: Linux 5.6-rc4 (2020-03-01 16:38:46 -0600) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-03-06 for you to fetch changes up to 2ac4853e295bba53209917e14af701c45c99ce04: Merge tag 'amd-drm-fixes-5.6-2020-03-05' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-03-06 11:06:33 +1000) drm fixes for 5.6-rc5 dma-buf: - fix memory leak core: - shmem object mmap fix. ttm: - Fix fence leak in ttm_buffer_object_transfer(). amdgpu: - Gfx reset fix for gfx9, 10 - Fix for gfx10 - DP MST fix - DCC fix - Renoir power fixes - Navi power fix i915: - Break up long lists of object reclaim with cond_resched() - PSR probe fix - TGL workarounds - Selftest return value fix - Drop timeline mutex while waiting for retirement - Wait for OA configuration completion before writes to OA buffer virtio: - Fix resource id creation race in virtio. - mmap fixes sun4i: - Fixes for sun4i VI layer format support. kirin: - kirin: Revert "Fix for hikey620 display offset problem" exynos: - fix a kernel oops problem in case that driver is loaded as module. - fix a regulator warning issue when I2C DDC adapter cannot be gathered. - print out an error message only in error case excepting -EPROBE_DEFER. mediatek: - overlay, cursor and gce fixes. ` Ahzo (1): drm/ttm: fix leaking fences via ttm_buffer_object_transfer Bhawanpreet Lakha (1): drm/amd/display: Clear link settings on MST disable connector Bibby Hsieh (4): drm/mediatek: Add plane check in async_check function drm/mediatek: Add fb swap in async_update drm/mediatek: Move gce event property to mutex device node drm/mediatek: Make sure previous message done or be aborted before send Chris Wilson (4): drm/i915/gem: Break up long lists of object reclaim drm/i915: Protect i915_request_await_start from early waits drm/i915/perf: Reintroduce wait on OA configuration completion drm/i915/gt: Drop the timeline->mutex as we wait for retirement Cong Wang (1): dma-buf: free dmabuf->name in dma_buf_release() Dan Carpenter (1): drm/i915/selftests: Fix return in assert_mmap_offset() Dave Airlie (5): Merge tag 'exynos-drm-fixes-for-v5.6-rc5' of git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes Merge tag 'mediatek-drm-fixes-5.6' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes Merge tag 'drm-misc-fixes-2020-03-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2020-03-05' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.6-2020-03-05' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Evan Benn (1): drm/mediatek: Find the cursor plane instead of hard coding it Gerd Hoffmann (3): drm/shmem: add support for per object caching flags. drm/virtio: fix mmap page attributes drm/shmem: drop pgprot_decrypted() Hersen Wu (1): drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3 (v2) Icenowy Zheng (1): drm/bridge: analogix-anx6345: fix set of link bandwidth Jernej Skrabec
Re: [PATCH v3 3/3] drm/panel: add panel driver for Elida KD35T133 panels
Am Samstag, 29. Februar 2020, 16:15:06 CET schrieb Heiko Stuebner: > From: Heiko Stuebner > > Panel driver for the KD35T133 display from Elida, used for example > in the rk3326-based Odroid Go Advance handheld. > > changes in v3: > - add missing return value assignment (Francesco) > - re-sort header includes (Sam) > changes in v2: > - rename dsi_generic_write_seq macro to dsi_dcs_write_seq to honor > the underlying mipi_dsi_dcs_write (Robin) > > Signed-off-by: Heiko Stuebner > Reviewed-by: Sam Ravnborg applied to drm-misc-next with Sam's Review ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/edid: Name the detailed monitor range flags
This patch adds defines for the detailed monitor
range flags as per the EDID specification.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Signed-off-by: Manasi Navare
---
include/drm/drm_edid.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index f0b03d401c27..f89c97623845 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -91,6 +91,11 @@ struct detailed_data_string {
u8 str[13];
} __attribute__((packed));
+#define EDID_DEFAULT_GTF_SUPPORT_FLAG 0x00
+#define EDID_RANGE_LIMITS_ONLY_FLAG 0x01
+#define EDID_SECONDARY_GTF_SUPPORT_FLAG 0x02
+#define EDID_CVT_SUPPORT_FLAG 0x04
+
struct detailed_data_monitor_range {
u8 min_vfreq;
u8 max_vfreq;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
amdgpu_dm_update_freesync_caps() to make it generic and be used
across all DRM drivers
v4:
* Use is_display_descriptor() (Ville)
* Name the monitor range flags (Ville)
v3:
* Remove the edid parsing restriction for just DP (Nicholas)
* Use drm_for_each_detailed_block (Ville)
* Make the drm_get_adaptive_sync_range function static (Harry, Jani)
v2:
* Change vmin and vmax to use u8 (Ville)
* Dont store pixel clock since that is just a max dotclock
and not related to VRR mode (Manasi)
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Clinton A Taylor
Cc: Kazlauskas Nicholas
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 22 +++
2 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ad41764a4ebe..61ed544d9535 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
}
}
+static
+void get_adaptive_sync_range(struct detailed_timing *timing,
+void *info_adaptive_sync)
+{
+ struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync;
+ const struct detailed_non_pixel *data = &timing->data.other_data;
+ const struct detailed_data_monitor_range *range = &data->data.range;
+
+ if (!is_display_descriptor((const u8 *)timing,
EDID_DETAIL_MONITOR_RANGE))
+ return;
+
+ /*
+* Check for flag range limits only. If flag == 1 then
+* no additional timing information provided.
+* Default GTF, GTF Secondary curve and CVT are not
+* supported
+*/
+ if (range->flags != EDID_RANGE_LIMITS_ONLY_FLAG)
+ return;
+
+ adaptive_sync->min_vfreq = range->min_vfreq;
+ adaptive_sync->max_vfreq = range->max_vfreq;
+}
+
+static
+void drm_get_adaptive_sync_range(struct drm_connector *connector,
+const struct edid *edid)
+{
+ struct drm_display_info *info = &connector->display_info;
+
+ if (!version_greater(edid, 1, 1))
+ return;
+
+ drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range,
+ &info->adaptive_sync);
+
+ DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n",
+ info->adaptive_sync.min_vfreq,
+ info->adaptive_sync.max_vfreq);
+}
+
/* A connector has no EDID information, so we've got no EDID to compute quirks
from. Reset
* all of the values which would have been set from EDID
*/
@@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector)
memset(&info->hdmi, 0, sizeof(info->hdmi));
info->non_desktop = 0;
+ memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync));
}
u32 drm_add_display_info(struct drm_connector *connector, const struct edid
*edid)
@@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector,
const struct edid *edi
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
+ drm_get_adaptive_sync_range(connector, edid);
+
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
if (edid->revision < 3)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 0df7a95ca5d9..2b22c0fa42c4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -254,6 +254,23 @@ enum drm_panel_orientation {
DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+/**
+ * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for
+ * &drm_display_info
+ *
+ * This struct is used to store a Panel's Adaptive Sync capabilities
+ * as parsed from EDID's detailed monitor range descriptor block.
+ *
+ * @min_vfreq: This is the min supported refresh rate in Hz from
+ * EDID's detailed monitor range.
+ * @max_vfreq: This is the max supported refresh rate in Hz from
+ * EDID's detailed monitor range
+ */
+struct drm_adaptive_sync_info {
+ u8 min_vfreq;
+ u8 max_vfreq;
+};
+
/*
* This is a consolidated colorimetry list supported by HDMI and
* DP protocol standard. The respective connectors will register
@@ -473,6 +490,11 @@ struct drm_display_info {
* @non_desktop: Non desktop display (HMD).
*/
bool non_desktop;
+
+ /**
+* @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink
+*/
+ struct drm_adaptive_sync_info adaptive_sync;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
--
2.19.1
_
Re: [PATCH v3 2/3] dt-bindings: display: panel: Add binding document for Elida KD35T133
Am Samstag, 29. Februar 2020, 16:15:05 CET schrieb Heiko Stuebner: > From: Heiko Stuebner > > The KD35T133 is a 3.5" 320x480 DSI display used in the RK3326-based > Odroid Go Advance handheld device. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Sam Ravnborg applied to drm-misc-next with Rob's review ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/22] drm/writeback: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: mips-randconfig-a001-20200306 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 5.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=5.5.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_writeback.c: In function 'drm_writeback_connector_init':
>> drivers/gpu/drm/drm_writeback.c:191:8: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
^
cc1: some warnings being treated as errors
vim +/drm_simple_encoder_init +191 drivers/gpu/drm/drm_writeback.c
149
150 /**
151 * drm_writeback_connector_init - Initialize a writeback connector and
its properties
152 * @dev: DRM device
153 * @wb_connector: Writeback connector to initialize
154 * @con_funcs: Connector funcs vtable
155 * @enc_helper_funcs: Encoder helper funcs vtable to be used by the
internal encoder
156 * @formats: Array of supported pixel formats for the writeback engine
157 * @n_formats: Length of the formats array
158 *
159 * This function creates the writeback-connector-specific properties if
they
160 * have not been already created, initializes the connector as
161 * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the
property
162 * values. It will also create an internal encoder associated with the
163 * drm_writeback_connector and set it to use the @enc_helper_funcs
vtable for
164 * the encoder helper.
165 *
166 * Drivers should always use this function instead of
drm_connector_init() to
167 * set up writeback connectors.
168 *
169 * Returns: 0 on success, or a negative error code
170 */
171 int drm_writeback_connector_init(struct drm_device *dev,
172 struct drm_writeback_connector
*wb_connector,
173 const struct drm_connector_funcs
*con_funcs,
174 const struct drm_encoder_helper_funcs
*enc_helper_funcs,
175 const u32 *formats, int n_formats)
176 {
177 struct drm_property_blob *blob;
178 struct drm_connector *connector = &wb_connector->base;
179 struct drm_mode_config *config = &dev->mode_config;
180 int ret = create_writeback_properties(dev);
181
182 if (ret != 0)
183 return ret;
184
185 blob = drm_property_create_blob(dev, n_formats *
sizeof(*formats),
186 formats);
187 if (IS_ERR(blob))
188 return PTR_ERR(blob);
189
190 drm_encoder_helper_add(&wb_connector->encoder,
enc_helper_funcs);
> 191 ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
192DRM_MODE_ENCODER_VIRTUAL);
193 if (ret)
194 goto fail;
195
196 connector->interlace_allowed = 0;
197
198 ret = drm_connector_init(dev, connector, con_funcs,
199 DRM_MODE_CONNECTOR_WRITEBACK);
200 if (ret)
201 goto connector_fail;
202
203 ret = drm_connector_attach_encoder(connector,
204 &wb_connector->encoder);
205 if (ret)
206 goto attach_fail;
207
208 INIT_LIST_HEAD(&wb_connector->job_queue);
209 spin_lock_init(&wb_connector->job_lock);
210
211 wb_connector->fence_context = dma_fence_context_alloc(1);
212 spin_lock_init(&wb_connector->fence_lock);
213 snprintf(wb_connector->timeline_name,
214 sizeof(wb_connector->timeline_name),
215
Re: [PATCH 03/22] drm/exynos: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/exynos/exynos_drm_dpi.c: In function 'exynos_dpi_bind':
>> drivers/gpu/drm/exynos/exynos_drm_dpi.c:201:2: error: implicit declaration
>> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
^~~
drm_encoder_init
cc1: some warnings being treated as errors
--
drivers/gpu/drm/exynos/exynos_dp.c: In function 'exynos_dp_bind':
>> drivers/gpu/drm/exynos/exynos_dp.c:174:2: error: implicit declaration of
>> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +201 drivers/gpu/drm/exynos/exynos_drm_dpi.c
196
197 int exynos_dpi_bind(struct drm_device *dev, struct drm_encoder *encoder)
198 {
199 int ret;
200
> 201 drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
202
203 drm_encoder_helper_add(encoder,
&exynos_dpi_encoder_helper_funcs);
204
205 ret = exynos_drm_set_possible_crtcs(encoder,
EXYNOS_DISPLAY_TYPE_LCD);
206 if (ret < 0)
207 return ret;
208
209 ret = exynos_dpi_create_connector(encoder);
210 if (ret) {
211 DRM_DEV_ERROR(encoder_to_dpi(encoder)->dev,
212"failed to create connector ret = %d\n",
ret);
213 drm_encoder_cleanup(encoder);
214 return ret;
215 }
216
217 return 0;
218 }
219
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/22] drm/writeback: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: x86_64-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-5) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_writeback.c: In function 'drm_writeback_connector_init':
>> drivers/gpu/drm/drm_writeback.c:191:8: error: implicit declaration of
>> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +191 drivers/gpu/drm/drm_writeback.c
149
150 /**
151 * drm_writeback_connector_init - Initialize a writeback connector and
its properties
152 * @dev: DRM device
153 * @wb_connector: Writeback connector to initialize
154 * @con_funcs: Connector funcs vtable
155 * @enc_helper_funcs: Encoder helper funcs vtable to be used by the
internal encoder
156 * @formats: Array of supported pixel formats for the writeback engine
157 * @n_formats: Length of the formats array
158 *
159 * This function creates the writeback-connector-specific properties if
they
160 * have not been already created, initializes the connector as
161 * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the
property
162 * values. It will also create an internal encoder associated with the
163 * drm_writeback_connector and set it to use the @enc_helper_funcs
vtable for
164 * the encoder helper.
165 *
166 * Drivers should always use this function instead of
drm_connector_init() to
167 * set up writeback connectors.
168 *
169 * Returns: 0 on success, or a negative error code
170 */
171 int drm_writeback_connector_init(struct drm_device *dev,
172 struct drm_writeback_connector
*wb_connector,
173 const struct drm_connector_funcs
*con_funcs,
174 const struct drm_encoder_helper_funcs
*enc_helper_funcs,
175 const u32 *formats, int n_formats)
176 {
177 struct drm_property_blob *blob;
178 struct drm_connector *connector = &wb_connector->base;
179 struct drm_mode_config *config = &dev->mode_config;
180 int ret = create_writeback_properties(dev);
181
182 if (ret != 0)
183 return ret;
184
185 blob = drm_property_create_blob(dev, n_formats *
sizeof(*formats),
186 formats);
187 if (IS_ERR(blob))
188 return PTR_ERR(blob);
189
190 drm_encoder_helper_add(&wb_connector->encoder,
enc_helper_funcs);
> 191 ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
192DRM_MODE_ENCODER_VIRTUAL);
193 if (ret)
194 goto fail;
195
196 connector->interlace_allowed = 0;
197
198 ret = drm_connector_init(dev, connector, con_funcs,
199 DRM_MODE_CONNECTOR_WRITEBACK);
200 if (ret)
201 goto connector_fail;
202
203 ret = drm_connector_attach_encoder(connector,
204 &wb_connector->encoder);
205 if (ret)
206 goto attach_fail;
207
208 INIT_LIST_HEAD(&wb_connector->job_queue);
209 spin_lock_init(&wb_connector->job_lock);
210
211 wb_connector->fence_context = dma_fence_context_alloc(1);
212 spin_lock_init(&wb_connector->fence_lock);
213 snprintf(wb_connector->timeline_name,
214 sizeof(wb_connector->timeline_name),
215 "CONNECTOR:%d-%s", connector->base.id,
connector->name);
216
Re: [PATCH 05/22] drm/gma500: Use simple encoder
Hi Thomas, I love your patch! Yet something to improve: [auto build test ERROR on next-20200305] [also build test ERROR on v5.6-rc4] [cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931 base:47466dcf84ee66a973ea7d2fca7e582fe9328932 config: x86_64-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.5.0-5) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/psb_intel_lvds.c: In function 'psb_intel_lvds_init': >> drivers/gpu/drm/gma500/psb_intel_lvds.c:676:2: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_LVDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/cdv_intel_crt.c: In function 'cdv_intel_crt_init': >> drivers/gpu/drm/gma500/cdv_intel_crt.c:267:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/cdv_intel_hdmi.c: In function 'cdv_hdmi_init': >> drivers/gpu/drm/gma500/cdv_intel_hdmi.c:315:2: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/cdv_intel_dp.c: In function 'cdv_intel_dp_init': >> drivers/gpu/drm/gma500/cdv_intel_dp.c:2010:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/cdv_intel_lvds.c: In function 'cdv_intel_lvds_init': >> drivers/gpu/drm/gma500/cdv_intel_lvds.c:611:2: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_LVDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 'oaktrail_lvds_init': >> drivers/gpu/drm/gma500/oaktrail_lvds.c:316:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_LVDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/oaktrail_hdmi.c: In function 'oaktrail_hdmi_init': >> drivers/gpu/drm/gma500/oaktrail_hdmi.c:646:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c: In function 'mdfld_dsi_dpi_init': >> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:998:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_LVDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors vim +676 drivers/gpu/drm/gma500/psb_intel_lvds.c 625 626 /** 627
Re: [PATCH 02/22] drm/atmel-hlcdc: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu//drm/atmel-hlcdc/atmel_hlcdc_output.c: In function
'atmel_hlcdc_attach_endpoint':
>> drivers/gpu//drm/atmel-hlcdc/atmel_hlcdc_output.c:98:8: error: implicit
>> declaration of function 'drm_simple_encoder_init'; did you mean
>> 'drm_encoder_init'? [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(dev, &output->encoder,
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +98 drivers/gpu//drm/atmel-hlcdc/atmel_hlcdc_output.c
65
66 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int
endpoint)
67 {
68 struct atmel_hlcdc_rgb_output *output;
69 struct device_node *ep;
70 struct drm_panel *panel;
71 struct drm_bridge *bridge;
72 int ret;
73
74 ep = of_graph_get_endpoint_by_regs(dev->dev->of_node, 0,
endpoint);
75 if (!ep)
76 return -ENODEV;
77
78 ret = drm_of_find_panel_or_bridge(dev->dev->of_node, 0,
endpoint,
79&panel, &bridge);
80 if (ret) {
81 of_node_put(ep);
82 return ret;
83 }
84
85 output = devm_kzalloc(dev->dev, sizeof(*output), GFP_KERNEL);
86 if (!output) {
87 of_node_put(ep);
88 return -ENOMEM;
89 }
90
91 output->bus_fmt = atmel_hlcdc_of_bus_fmt(ep);
92 of_node_put(ep);
93 if (output->bus_fmt < 0) {
94 dev_err(dev->dev, "endpoint %d: invalid bus width\n",
endpoint);
95 return -EINVAL;
96 }
97
> 98 ret = drm_simple_encoder_init(dev, &output->encoder,
99DRM_MODE_ENCODER_NONE);
100 if (ret)
101 return ret;
102
103 output->encoder.possible_crtcs = 0x1;
104
105 if (panel) {
106 bridge = drm_panel_bridge_add_typed(panel,
107
DRM_MODE_CONNECTOR_Unknown);
108 if (IS_ERR(bridge))
109 return PTR_ERR(bridge);
110 }
111
112 if (bridge) {
113 ret = drm_bridge_attach(&output->encoder, bridge, NULL,
0);
114 if (!ret)
115 return 0;
116
117 if (panel)
118 drm_panel_bridge_remove(bridge);
119 }
120
121 drm_encoder_cleanup(&output->encoder);
122
123 return ret;
124 }
125
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/22] drm/vkms: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: mips-randconfig-a001-20200306 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 5.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=5.5.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/vkms/vkms_output.c: In function 'vkms_output_init':
>> drivers/gpu/drm/vkms/vkms_output.c:70:8: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
^
cc1: some warnings being treated as errors
vim +/drm_simple_encoder_init +70 drivers/gpu/drm/vkms/vkms_output.c
34
35 int vkms_output_init(struct vkms_device *vkmsdev, int index)
36 {
37 struct vkms_output *output = &vkmsdev->output;
38 struct drm_device *dev = &vkmsdev->drm;
39 struct drm_connector *connector = &output->connector;
40 struct drm_encoder *encoder = &output->encoder;
41 struct drm_crtc *crtc = &output->crtc;
42 struct drm_plane *primary, *cursor = NULL;
43 int ret;
44
45 primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY,
index);
46 if (IS_ERR(primary))
47 return PTR_ERR(primary);
48
49 if (enable_cursor) {
50 cursor = vkms_plane_init(vkmsdev,
DRM_PLANE_TYPE_CURSOR, index);
51 if (IS_ERR(cursor)) {
52 ret = PTR_ERR(cursor);
53 goto err_cursor;
54 }
55 }
56
57 ret = vkms_crtc_init(dev, crtc, primary, cursor);
58 if (ret)
59 goto err_crtc;
60
61 ret = drm_connector_init(dev, connector, &vkms_connector_funcs,
62 DRM_MODE_CONNECTOR_VIRTUAL);
63 if (ret) {
64 DRM_ERROR("Failed to init connector\n");
65 goto err_connector;
66 }
67
68 drm_connector_helper_add(connector, &vkms_conn_helper_funcs);
69
> 70 ret = drm_simple_encoder_init(dev, encoder,
DRM_MODE_ENCODER_VIRTUAL);
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/22] drm/fsl-dcu: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function
'fsl_dcu_drm_encoder_create':
>> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:33:8: error: implicit declaration
>> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'?
>> [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(fsl_dev->drm, encoder,
^~~
drm_encoder_init
cc1: some warnings being treated as errors
vim +33 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
20
21 int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
22 struct drm_crtc *crtc)
23 {
24 struct drm_encoder *encoder = &fsl_dev->encoder;
25 int ret;
26
27 encoder->possible_crtcs = 1;
28
29 /* Use bypass mode for parallel RGB/LVDS encoder */
30 if (fsl_dev->tcon)
31 fsl_tcon_bypass_enable(fsl_dev->tcon);
32
> 33 ret = drm_simple_encoder_init(fsl_dev->drm, encoder,
34DRM_MODE_ENCODER_LVDS);
35 if (ret < 0)
36 return ret;
37
38 return 0;
39 }
40
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/22] drm/rockchip: Use simple encoder
Hi Thomas, I love your patch! Yet something to improve: [auto build test ERROR on next-20200305] [cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2 v5.6-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931 base:47466dcf84ee66a973ea7d2fca7e582fe9328932 config: sparc-allyesconfig (attached as .config) compiler: sparc64-linux-gcc (GCC) 7.5.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.5.0 make.cross ARCH=sparc If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/gpu/drm/rockchip/analogix_dp-rockchip.c: In function 'rockchip_dp_drm_create_encoder': >> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:309:8: error: implicit >> declaration of function 'drm_simple_encoder_init'; did you mean >> 'drm_encoder_init'? [-Werror=implicit-function-declaration] ret = drm_simple_encoder_init(drm_dev, encoder, ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/cdn-dp-core.c: In function 'cdn_dp_bind': >> drivers/gpu/drm/rockchip/cdn-dp-core.c:1030:8: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] ret = drm_simple_encoder_init(drm_dev, encoder, ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c: In function 'dw_hdmi_rockchip_bind': >> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:546:2: error: implicit >> declaration of function 'drm_simple_encoder_init'; did you mean >> 'drm_encoder_init'? [-Werror=implicit-function-declaration] drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c: In function 'rockchip_dsi_drm_create_encoder': >> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c:802:8: error: implicit >> declaration of function 'drm_simple_encoder_init'; did you mean >> 'drm_encoder_init'? [-Werror=implicit-function-declaration] ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/inno_hdmi.c: In function 'inno_hdmi_register': >> drivers/gpu/drm/rockchip/inno_hdmi.c:617:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 'rockchip_lvds_bind': >> drivers/gpu/drm/rockchip/rockchip_lvds.c:607:8: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_LVDS); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/rockchip_rgb.c: In function 'rockchip_rgb_init': >> drivers/gpu/drm/rockchip/rockchip_rgb.c:125:8: error: implicit declaration >> of function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=implicit-function-declaration] ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_NONE); ^~~ drm_encoder_init cc1: some warnings being treated as errors -- drivers/gpu/drm/rockchip/rk3066_hdmi.c: In function 'rk3066_hdmi_register': >> drivers/gpu/drm/rockchip/rk3066_hdmi.c:557:2: error: implicit declaration of >> function 'drm_simple_encoder_init'; did you mean 'drm_encoder_init'? >> [-Werror=imp
Re: [PATCH 01/22] drm/arc: Use simple encoder
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200305]
[also build test ERROR on v5.6-rc4]
[cannot apply to rockchip/for-next shawnguo/for-next sunxi/sunxi/for-next
tegra/for-next linus/master v5.6-rc4 v5.6-rc3 v5.6-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Convert-drivers-to-drm_simple_encoder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: mips-randconfig-a001-20200306 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 5.5.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=5.5.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/arc/arcpgu_hdmi.c: In function 'arcpgu_drm_hdmi_init':
>> drivers/gpu/drm/arc/arcpgu_hdmi.c:34:8: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
^
cc1: some warnings being treated as errors
--
drivers/gpu/drm/arc/arcpgu_sim.c: In function 'arcpgu_drm_sim_init':
>> drivers/gpu/drm/arc/arcpgu_sim.c:68:8: error: implicit declaration of
>> function 'drm_simple_encoder_init' [-Werror=implicit-function-declaration]
ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_VIRTUAL);
^
cc1: some warnings being treated as errors
vim +/drm_simple_encoder_init +34 drivers/gpu/drm/arc/arcpgu_hdmi.c
15
16 int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
17 {
18 struct drm_encoder *encoder;
19 struct drm_bridge *bridge;
20
21 int ret = 0;
22
23 encoder = devm_kzalloc(drm->dev, sizeof(*encoder), GFP_KERNEL);
24 if (encoder == NULL)
25 return -ENOMEM;
26
27 /* Locate drm bridge from the hdmi encoder DT node */
28 bridge = of_drm_find_bridge(np);
29 if (!bridge)
30 return -EPROBE_DEFER;
31
32 encoder->possible_crtcs = 1;
33 encoder->possible_clones = 0;
> 34 ret = drm_simple_encoder_init(drm, encoder,
DRM_MODE_ENCODER_TMDS);
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix pageflip event race condition for DCN.
On Mon, Mar 2, 2020 at 2:57 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-03-02 1:17 a.m., Mario Kleiner wrote:
> > Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
> > events at vsartup for DCN")' introduces a new way of pageflip
> > completion handling for DCN, and some trouble.
> >
> > The current implementation introduces a race condition, which
> > can cause pageflip completion events to be sent out one vblank
> > too early, thereby confusing userspace and causing flicker:
> >
> > prepare_flip_isr():
> >
> > 1. Pageflip programming takes the ddev->event_lock.
> > 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
> > 3. Releases ddev->event_lock.
> >
> > --> Deadline for surface address regs double-buffering passes on
> > target pipe.
> >
> > 4. dc_commit_updates_for_stream() MMIO programs the new pageflip
> > into hw, but too late for current vblank.
> >
> > => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
> > in current vblank due to missing the double-buffering deadline
> > by a tiny bit.
> >
> > 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
> > dm_dcn_crtc_high_irq() gets called.
> >
> > 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
> > pageflip has been completed/will complete in this vblank and
> > sends out pageflip completion event to userspace and resets
> > pflip_status = AMDGPU_FLIP_NONE.
> >
> > => Flip completion event sent out one vblank too early.
> >
> > This behaviour has been observed during my testing with measurement
> > hardware a couple of time.
> >
> > The commit message says that the extra flip event code was added to
> > dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
> > in case the pflip irq doesn't fire, because the "DCH HUBP" component
> > is clock gated and doesn't fire pflip irqs in that state. Also that
> > this clock gating may happen if no planes are active. This suggests
> > that the problem addressed by that commit can't happen if planes
> > are active.
> >
> > The proposed solution is therefore to only execute the extra pflip
> > completion code iff the count of active planes is zero and otherwise
> > leave pflip completion handling to the pflip irq handler, for a
> > more race-free experience.
> >
> > Note that i don't know if this fixes the problem the original commit
> > tried to address, as i don't know what the test scenario was. It
> > does fix the observed too early pageflip events though and points
> > out the problem introduced.
>
> This looks like a valid race condition that should be addressed.
Indeed! And if possible in any way, before Linux 5.6 is released. For
my use cases, neuroscience/medical research, this is a serious problem
which would make DCN gpu's basically unusable for most work. Problems
affecting flip timing / flip completion / timestamping are always
worst case problems for my users.
>
> Unfortunately this also doesn't fix the problem the original commit was
> trying to address.
>
> HUBP interrupts only trigger when it's not clock gated. But there are
> cases (for example, PSR) where the HUBP can be clock gated but the
> active plane count is greater than zero.
>
> The clock gating switch can typically happens outside of x86 control
> flow so we're not really going to understand in advance whether or not
> we'll be able to receive the pflip IRQ.
>
Oh dear! So how can that happen? Could explain to me in more detail,
how this works? What's the job of HUBP, apart from (not) triggering
pflip interrupts reliably? Is the scenario here that the desktop is
detected idle for a while (how?) and PSR kicks in and HUBP gets clock
gated, but somehow vblank interrupts are still active? I thought panel
self refresh only enables on long idle display, so scanout from the
gpu can be basically disabled while the panel refreshes itself? Is a
programmed pageflip then automatically (no host cpu involvement)
putting the panel out of self refresh and turning scanout on and the
pageflip completion enables HUBP again, but HUBP doesn't trigger the
pflip irq because it somehow missed that due to being clock-gated at
time of flip completion?
I'd really like to understand in more detail how this stuff works on
your recent hw, and also which irqs / events / trigger points are
associated with what actions of the hw. I have the feeling there will
be more "fun" lingering in the future. I also wanted to experiment
more with some VRR ideas, so any details about which hw events happen
when and fire which irq's and which double-buffered registers
double-buffer when are greatly appreciated.
> While we do have plane status/flip pending bits available to check in
> the VSTARTUP IRQ handler, this obviously doesn't work for resolving the
> core of the issue - that we probably don't know whether or not the HUBP
> will be on before sending out the event.
>
> Maybe we can guess based on what features are enabled.>
Ok, that's your domain of knowledge. I jus
[PATCH] drm/amd/display: Fix pageflip event race condition for DCN. (v2)
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
events at vsartup for DCN")' introduces a new way of pageflip
completion handling for DCN, and some trouble.
The current implementation introduces a race condition, which
can cause pageflip completion events to be sent out one vblank
too early, thereby confusing userspace and causing flicker:
prepare_flip_isr():
1. Pageflip programming takes the ddev->event_lock.
2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
3. Releases ddev->event_lock.
--> Deadline for surface address regs double-buffering passes on
target pipe.
4. dc_commit_updates_for_stream() MMIO programs the new pageflip
into hw, but too late for current vblank.
=> pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
in current vblank due to missing the double-buffering deadline
by a tiny bit.
5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
dm_dcn_crtc_high_irq() gets called.
6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
pageflip has been completed/will complete in this vblank and
sends out pageflip completion event to userspace and resets
pflip_status = AMDGPU_FLIP_NONE.
=> Flip completion event sent out one vblank too early.
This behaviour has been observed during my testing with measurement
hardware a couple of time.
The commit message says that the extra flip event code was added to
dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
in case the pflip irq doesn't fire, because the "DCH HUBP" component
is clock gated and doesn't fire pflip irqs in that state. Also that
this clock gating may happen if no planes are active. According to
Nicholas, the clock gating can also happen if psr is active, and the
gating is controlled independently by the hardware, so difficult to
detect if and when the completion code in above commit is needed.
This patch tries the following solution: It only executes the extra pflip
completion code in dm_dcn_crtc_high_irq() iff the hardware reports
that there aren't any surface updated pending in the double-buffered
surface scanout address registers. Otherwise it leaves pflip completion
to the pflip irq handler, for a more race-free experience.
This would only guard against the order of events mentioned above.
If Step 5 (VSTARTUP trigger) happens before step 4 then this won't help
at all, because 1-3 + 5 might happen even without the hw being programmed
at all, ie. no surface update pending because none yet programmed into hw.
Therefore this patch also changes locking in amdgpu_dm_commit_planes(),
so that prepare_flip_isr() and dc_commit_updates_for_stream() are done
under event_lock protection within the same critical section.
v2: Take Nicholas comments into account, try a different solution.
Lightly tested on Polaris (locking) and Raven (the whole DCN stuff).
Seems to work without causing obvious new trouble.
Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup
for DCN")
Signed-off-by: Mario Kleiner
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 80 ---
1 file changed, 67 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d7df1a85e72f..aa4e941b276f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -287,6 +287,28 @@ static inline bool amdgpu_dm_vrr_active(struct
dm_crtc_state *dm_state)
dm_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED;
}
+/**
+ * dm_crtc_is_flip_pending() - Is a pageflip pending on this crtc?
+ *
+ * Returns true if any plane on the crtc has a flip pending, false otherwise.
+ */
+static bool dm_crtc_is_flip_pending(struct dm_crtc_state *acrtc_state)
+{
+ struct dc_stream_status *status =
dc_stream_get_status(acrtc_state->stream);
+ const struct dc_plane_status *plane_status;
+ int i;
+ bool pending = false;
+
+ for (i = 0; i < status->plane_count; i++) {
+ plane_status = dc_plane_get_status(status->plane_states[i]);
+ pending |= plane_status->is_flip_pending;
+ DRM_DEBUG_DRIVER("plane:%d, flip_pending=%d\n",
+i, plane_status->is_flip_pending);
+ }
+
+ return pending;
+}
+
/**
* dm_pflip_high_irq() - Handle pageflip interrupt
* @interrupt_params: ignored
@@ -435,6 +457,11 @@ static void dm_vupdate_high_irq(void *interrupt_params)
spin_unlock_irqrestore(&adev->ddev->event_lock,
flags);
}
}
+
+ if (acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED) {
+ DRM_DEBUG_DRIVER("%s:crtc:%d, flip_pending=%d\n",
__func__,
+ acrtc->crtc_id,
dm_crtc_is_flip_pending(acrtc_state));
+ }
}
}
@@ -489,6 +516,11 @@ st
Re: [PATCH v11 2/5] dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller
Quoting Enric Balletbo i Serra (2020-03-02 03:01:25) > The mmsys system controller is not only a pure clock controller, so > update the binding documentation to reflect that apart from providing > clocks, it also provides routing and miscellaneous control registers. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Matthias Brugger > Reviewed-by: CK Hu > --- Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 3/5] soc: mediatek: Move mt8173 MMSYS to platform driver
Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> From: Matthias Brugger
>
> There is no strong reason for this to use CLK_OF_DECLARE instead of
> being a platform driver.
Cool.
> Plus, this driver provides clocks but also
> a shared register space for the mediatek-drm and the mediatek-mdp
> driver. So move to drivers/soc/mediatek as a platform driver.
>
> Signed-off-by: Matthias Brugger
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: CK Hu
> ---
>
> Changes in v11: None
> Changes in v10:
> - Renamed to be generic mtk-mmsys
> - Add driver data support to be able to support diferent SoCs
>
> Changes in v9:
> - Move mmsys to drivers/soc/mediatek (CK)
>
> Changes in v8:
> - Be a builtin_platform_driver like other mediatek mmsys drivers.
>
> Changes in v7:
> - Free clk_data->clks as well
> - Get rid of private data structure
>
> drivers/clk/mediatek/clk-mt8173.c | 104
> drivers/soc/mediatek/Kconfig | 7 ++
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-mmsys.c | 154 ++
Can you generate with -M so that we can see what has actually changed?
> 4 files changed, 162 insertions(+), 104 deletions(-)
> create mode 100644 drivers/soc/mediatek/mtk-mmsys.c
>
> diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
> index 2114b563478c..7a156944d50e 100644
> --- a/drivers/soc/mediatek/Kconfig
> +++ b/drivers/soc/mediatek/Kconfig
> @@ -44,4 +44,11 @@ config MTK_SCPSYS
> Say yes here to add support for the MediaTek SCPSYS power domain
> driver.
>
> +config MTK_MMSYS
> + bool "MediaTek MMSYS Support"
> + depends on COMMON_CLK_MT8173
Does it need some default so that defconfig updates don't break things?
> + help
> + Say yes here to add support for the MediaTek Multimedia
> + Subsystem (MMSYS).
> +
> endmenu
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index b01733074ad6..01f9f873634a 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
> obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
> obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
> obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> new file mode 100644
> index ..473cdf732fb5
> --- /dev/null
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + * Author: James Liao
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "../../clk/mediatek/clk-gate.h"
> +#include "../../clk/mediatek/clk-mtk.h"
Why not use include/linux/clk/?
But I also don't understand why the clk driver is moved outside of
drivers/clk/ into drivers/soc/. Commit text saying that it has shared
registers doesn't mean it can't still keep the clk driver part in the
drivers/clk/ area.
> +
> +#include
> +
> +static const struct mtk_gate_regs mm0_cg_regs = {
> + .set_ofs = 0x0104,
> + .clr_ofs = 0x0108,
> + .sta_ofs = 0x0100,
> +};
> +
> +static const struct mtk_gate_regs mm1_cg_regs = {
> + .set_ofs = 0x0114,
> + .clr_ofs = 0x0118,
> + .sta_ofs = 0x0110,
> +};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] drm/radeon: don't use ttm bo->offset
On 2020-03-05 14:37, Ho, Kenny wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
>
> I believe bo->tbo.mem.mem_type is of uint32_t type and not an enum, is the
> index lookup method safe? (i.e., how do you deal with the possibility of
> having value TTM_PL_PRIV or above or are you suggesting those are not
> possible for this function.)
Hi Kenny,
Good question. I'm not suggesting that those are not possible
with this function. The driver provides this map.
The format of the map is set by the infrastructure (TTM),
it could be as simple as "u64 *mem_start_map; int map_size;" in an embedding
struture or something more fancy.
However the map array and values themselves are set by the driver when it
answers
about its capabilities, etc, when it first registers with TTM.
Notice how badly the switch statment below is written. (Inverview question.)
It's missing a "default:" label! (it's why switch-case is powerful).
If you add a "default:" label, you see that the rest of the values
in the map are 0s.
While TTM knows only of TTM_PL_PRIV number of maps (3), the driver
can add more, allocate and initialize the map, and return it back
to TTM, guaranteeing at least TTM_PL_PRIV maps in indices 0, 1, and 2.
I think it is not a good idea to use a compare-branch for a
simple lookup like this. One naturally asks, "why isn't this
a simple map lookup?"
Consider the following thought experiment: we continue to add switch-case
and if-else for all sorts of simple things as we've seen being suggested
in recent patches. In a few years, we'll not be able to understand the code.
Regards,
Luben
P.S. Code obfuscation isn't necessarily a bad thing--it causes a complete
rewrite! :-D
>
> Kenny
> --
> *From:* Tuikov, Luben
> *Sent:* Thursday, March 5, 2020 2:19 PM
> *To:* Nirmoy Das ; dri-devel@lists.freedesktop.org
>
> *Cc:* Zhou, David(ChunMing) ; thellst...@vmware.com
> ; airl...@linux.ie ; Ho, Kenny
> ; brian.we...@intel.com ;
> maarten.lankho...@linux.intel.com ;
> amd-...@lists.freedesktop.org ; Das, Nirmoy
> ; linux-graphics-maintai...@vmware.com
> ; bske...@redhat.com
> ; dan...@ffwll.ch ; Deucher, Alexander
> ; s...@poorly.run ; Koenig,
> Christian ; kra...@redhat.com
> *Subject:* Re: [PATCH 2/8] drm/radeon: don't use ttm bo->offset
>
> On 2020-03-05 08:29, Nirmoy Das wrote:
>> Calculate GPU offset in radeon_bo_gpu_offset without depending on
>> bo->offset.
>>
>> Signed-off-by: Nirmoy Das
>> Reviewed-and-tested-by: Christian König
>> ---
>> drivers/gpu/drm/radeon/radeon.h | 1 +
>> drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
>> drivers/gpu/drm/radeon/radeon_ttm.c | 4 +---
>> 3 files changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 30e32adc1fc6..b7c3fb2bfb54 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
>> radeon_device *rdev, u64 size
>> extern void radeon_program_register_sequence(struct radeon_device *rdev,
>> const u32 *registers,
>> const u32 array_size);
>> +struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
>>
>> /*
>> * vm
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
>> b/drivers/gpu/drm/radeon/radeon_object.h
>> index d23f2ed4126e..60275b822f79 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.h
>> +++ b/drivers/gpu/drm/radeon/radeon_object.h
>> @@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo
>> *bo)
>> */
>> static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
>> {
>> - return bo->tbo.offset;
>> + struct radeon_device *rdev;
>> + u64 start = 0;
>> +
>> + rdev = radeon_get_rdev(bo->tbo.bdev);
>> +
>> + switch (bo->tbo.mem.mem_type) {
>> + case TTM_PL_TT:
>> + start = rdev->
[PATCH v5 16/16] drm/i915: Add HDCP 1.4 support for MST connectors
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
#v4
Changes in v2:
-Toggle HDCP from encoder disable/enable
-Don't disable HDCP on MST connector destroy, leave that for encoder
disable, just ensure the check_work routine isn't running any longer
Changes in v3:
-Place the shim in the new intel_dp_hdcp.c file (Ville)
Changes in v4:
-Actually use the mst shim for mst connections (Juston)
-Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
Changes in v5:
-Add sleep on disable signalling to match hdmi delay
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 105 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 14 +++
2 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 549f02f622b45..69b5412736467 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -7,10 +7,12 @@
*/
#include
+#include
#include
#include
#include "intel_display_types.h"
+#include "intel_ddi.h"
#include "intel_dp.h"
#include "intel_hdcp.h"
@@ -589,6 +591,104 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.protocol = HDCP_PROTOCOL_DP,
};
+static int
+intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
+ bool enable)
+{
+ int ret;
+
+ if (!enable)
+ usleep_range(6, 60); /* Bspec says >= 6us */
+
+ ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
+ cpu_transcoder, enable);
+ if (ret)
+ DRM_DEBUG_KMS("%s HDCP signalling failed (%d)\n",
+ enable ? "Enable" : "Disable", ret);
+ return ret;
+}
+
+static
+int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
+void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
+ u8 msg_id, void *buf, size_t size)
+{
+ return -EOPNOTSUPP;
+}
+
+static int
+intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port
*intel_dig_port,
+ bool is_repeater, u8 content_type)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
+{
+ return -EOPNOTSUPP;
+}
+
+static
+int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
+ bool *capable)
+{
+ *capable = false;
+ return 0;
+}
+
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
+{
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct drm_dp_query_stream_enc_status_ack_reply reply;
+ int ret;
+
+ if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
+ return false;
+
+ ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
+ connector->port, &reply);
+ if (ret) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] failed QSES ret=%d\n",
+ connector->base.base.id, connector->base.name,
+ ret);
+ return false;
+ }
+
+ return reply.auth_completed && reply.encryption_enabled;
+}
+
+static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
+ .write_an_aksv = intel_dp_hdcp_write_an_aksv,
+ .read_bksv = intel_dp_hdcp_read_bksv,
+ .read_bstatus = intel_dp_hdcp_read_bstatus,
+ .repeater_present = intel_dp_hdcp_repeater_present,
+ .read_ri_prime = intel_dp_hdcp_read_ri_prime,
+ .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
+ .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
+ .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
+ .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
+ .check_link = intel_dp_mst_hdcp_check_link,
+ .hdcp_capable = intel_dp_hdcp_capable,
+
+ .write_2_2_msg = intel_dp_mst_hdcp2_write_msg,
+ .read_2_2_msg = intel_dp_m
[PATCH v5 14/16] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Changes in v4:
-Added to the set
Changes in v5:
-None
---
drivers/gpu/drm/drm_dp_mst_topology.c | 117 ++
include/drm/drm_dp_helper.h | 3 +
include/drm/drm_dp_mst_helper.h | 44 ++
3 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 6c62ad8f44142..5bba5aac86f31 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -418,6 +419,22 @@ drm_dp_encode_sideband_req(const struct
drm_dp_sideband_msg_req_body *req,
memcpy(&buf[idx], req->u.i2c_write.bytes,
req->u.i2c_write.num_bytes);
idx += req->u.i2c_write.num_bytes;
break;
+ case DP_QUERY_STREAM_ENC_STATUS: {
+ const struct drm_dp_query_stream_enc_status *msg;
+
+ msg = &req->u.enc_status;
+ buf[idx] = msg->stream_id;
+ idx++;
+ memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
+ idx += sizeof(msg->client_id);
+ buf[idx] = 0;
+ buf[idx] |= msg->stream_event & GENMASK(1, 0);
+ buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
+ buf[idx] |= (msg->stream_behavior & GENMASK(1, 0)) << 3;
+ buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
+ idx++;
+ }
+ break;
}
raw->cur_len = idx;
}
@@ -930,6 +947,34 @@ static bool
drm_dp_sideband_parse_power_updown_phy_ack(struct drm_dp_sideband_ms
return true;
}
+static bool
+drm_dp_sideband_parse_query_stream_enc_status(
+ struct drm_dp_sideband_msg_rx *raw,
+ struct drm_dp_sideband_msg_reply_body *repmsg)
+{
+ struct drm_dp_query_stream_enc_status_ack_reply *reply;
+
+ reply = &repmsg->u.enc_status;
+
+ reply->stream_id = raw->msg[3];
+
+ reply->reply_signed = raw->msg[2] & BIT(0);
+
+ reply->hdcp_1x_device_present = raw->msg[2] & BIT(3);
+ reply->hdcp_2x_device_present = raw->msg[2] & BIT(4);
+
+ reply->query_capable_device_present = raw->msg[2] & BIT(5);
+ reply->legacy_device_present = raw->msg[2] & BIT(6);
+ reply->unauthorizable_device_present = raw->msg[2] & BIT(7);
+
+ reply->auth_completed = !!(raw->msg[1] & BIT(3));
+ reply->encryption_enabled = !!(raw->msg[1] & BIT(4));
+ reply->repeater_present = !!(raw->msg[1] & BIT(5));
+ reply->state = (raw->msg[1] & GENMASK(7, 6)) >> 6;
+
+ return true;
+}
+
static bool drm_dp_sideband_parse_reply(struct drm_dp_sideband_msg_rx *raw,
struct drm_dp_sideband_msg_reply_body
*msg)
{
@@ -964,6 +1009,8 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
case DP_CLEAR_PAYLOAD_ID_TABLE:
return true; /* since there's nothing to parse */
+ case DP_QUERY_STREAM_ENC_STATUS:
+ return drm_dp_sideband_parse_query_stream_enc_status(raw, msg);
default:
DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
drm_dp_mst_req_type_str(msg->req_type));
@@ -1115,6 +1162,25 @@ static void build_power_updown_phy(struct
drm_dp_sideband_msg_tx *msg,
msg->path_msg = true;
}
+static int
+build_query_stream_enc_status(struct drm_dp_sideband_msg_tx *msg, u8 stream_id,
+ u8 *q_id)
+{
+ struct drm_dp_sideband_msg_req_body req;
+
+ req.req_type = DP_QUERY_STREAM_ENC_STATUS;
+ req.u.enc_status.stream_id = stream_id;
+ memcpy(req.u.enc_status.client_id, q_id,
+ sizeof(req.u.enc_status.client_id));
+ req.u.enc_status.stream_event = 0;
+ req.u.enc_status.valid_stream_event = false;
+ req.u.enc_status.stream_behavior = 0;
+ req.u.enc_status.valid_stream_behavior = false;
+
+ drm_dp_encode_sideband_req(&req, msg);
+ return 0;
+}
+
static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_vcpi *vcpi)
{
@@ -3151,6 +3217,57 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_send_power_updown_phy);
+int drm_dp_send_query_stream_enc_status(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port,
+ struct drm_dp_query_stream_enc_status_ack_reply *status)
+{
+ struct drm_dp_sideband_msg_tx *txmsg;
+ u8 nonce[7];
+
[PATCH v5 13/16] drm/i915: Add connector to hdcp_shim->check_link()
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
# v4
Changes in v4:
-Added to the set
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
4 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3cac51955f250..9cc43dcbb518f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -312,7 +312,8 @@ struct intel_hdcp_shim {
bool enable);
/* Ensures the link is still protected */
- bool (*check_link)(struct intel_digital_port *intel_dig_port);
+ bool (*check_link)(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index abcb53975e0d5..549f02f622b45 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -538,7 +538,8 @@ int intel_dp_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
ssize_t ret;
u8 bstatus;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fc3ce7586084c..e0418ad202d1f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -956,7 +956,7 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- if (hdcp->shim->check_link(intel_dig_port)) {
+ if (hdcp->shim->check_link(intel_dig_port, connector)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 8b32c3c986bca..288525a9fdf7c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1522,11 +1522,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
intel_digital_port *intel_dig_port,
}
static
-bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
+bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
- struct intel_connector *connector =
- intel_dig_port->hdmi.attached_connector;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
int ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 11/16] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-Created intel_dp_hdcp.c for the shared functions to live (Ville)
Changes in v4:
-Rebased on new drm logging change
Changes in v5:
-None
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 585 +-
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 607 +++
4 files changed, 615 insertions(+), 581 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 991a8c537d123..cb4a7f137c0d9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -225,6 +225,7 @@ i915-y += \
display/intel_ddi.o \
display/intel_dp.o \
display/intel_dp_aux_backlight.o \
+ display/intel_dp_hdcp.o \
display/intel_dp_link_training.o \
display/intel_dp_mst.o \
display/intel_dsi.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4a38012a1fb03..306e4ccac5bb4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5958,580 +5958,6 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
edp_panel_vdd_off_sync(intel_dp);
}
-static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int timeout)
-{
- long ret;
-
-#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
- ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
- msecs_to_jiffies(timeout));
-
- if (!ret)
- DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
-}
-
-static
-int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
- u8 *an)
-{
- u8 aksv[DRM_HDCP_KSV_LEN] = {};
- ssize_t dpcd_ret;
-
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
-an, DRM_HDCP_AN_LEN);
- if (dpcd_ret != DRM_HDCP_AN_LEN) {
- DRM_DEBUG_KMS("Failed to write An over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
-
- /*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So we
-* send an empty buffer of the correct length through the DP helpers. On
-* the other side, in the transfer hook, we'll generate a flag based on
-* the destination address which will tickle the hardware to output the
-* Aksv on our behalf after the header is sent.
-*/
- dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AKSV,
-aksv, DRM_HDCP_KSV_LEN);
- if (dpcd_ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Failed to write Aksv over DP/AUX (%zd)\n",
- dpcd_ret);
- return dpcd_ret >= 0 ? -EIO : dpcd_ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
- u8 *bksv)
-{
- ssize_t ret;
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BKSV, bksv,
- DRM_HDCP_KSV_LEN);
- if (ret != DRM_HDCP_KSV_LEN) {
- DRM_DEBUG_KMS("Read Bksv from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static int intel_dp_hdcp_read_bstatus(struct intel_digital_port
*intel_dig_port,
- u8 *bstatus)
-{
- ssize_t ret;
- /*
-* For some reason the HDMI and DP HDCP specs call this register
-* definition by different names. In the HDMI spec, it's called BSTATUS,
-* but in DP it's called BINFO.
-*/
- ret = drm_dp_dpcd_read(&intel_dig_port->dp.aux, DP_AUX_HDCP_BINFO,
- bstatus, DRM_HDCP_BSTATUS_LEN);
- if (ret != DRM_HDCP_BSTATUS_LEN) {
- DRM_DEBUG_KMS("Read bstatus from DP/AUX failed (%zd)\n", ret);
- return ret >= 0 ? -EIO : ret;
- }
- return 0;
-}
-
-static
-int intel_dp_hdcp_read_bcaps(struct intel_digital_port *intel_dig_port,
-
[PATCH v5 15/16] drm/i915: Print HDCP version info for all connectors
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200227185714.171466-1-s...@poorly.run
#v4
Changes in v4:
- Added to the set
Changes in v5:
-Print "No connector support" for hdcp sink capability as well (Ram)
---
.../drm/i915/display/intel_display_debugfs.c | 21 ---
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1e6eb7f2f72db..25f03da30ed49 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -597,6 +597,11 @@ static void intel_hdcp_info(struct seq_file *m,
{
bool hdcp_cap, hdcp2_cap;
+ if (!intel_connector->hdcp.shim) {
+ seq_puts(m, "No Connector Support");
+ goto out;
+ }
+
hdcp_cap = intel_hdcp_capable(intel_connector);
hdcp2_cap = intel_hdcp2_capable(intel_connector);
@@ -608,6 +613,7 @@ static void intel_hdcp_info(struct seq_file *m,
if (!hdcp_cap && !hdcp2_cap)
seq_puts(m, "None");
+out:
seq_puts(m, "\n");
}
@@ -624,10 +630,6 @@ static void intel_dp_info(struct seq_file *m,
drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
&intel_dp->aux);
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_dp_mst_info(struct seq_file *m,
@@ -651,10 +653,6 @@ static void intel_hdmi_info(struct seq_file *m,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(intel_encoder);
seq_printf(m, "\taudio support: %s\n", yesno(intel_hdmi->has_audio));
- if (intel_connector->hdcp.shim) {
- seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
- }
}
static void intel_lvds_info(struct seq_file *m,
@@ -710,6 +708,9 @@ static void intel_connector_info(struct seq_file *m,
break;
}
+ seq_puts(m, "\tHDCP version: ");
+ intel_hdcp_info(m, intel_connector);
+
seq_printf(m, "\tmodes:\n");
list_for_each_entry(mode, &connector->modes, head)
intel_seq_print_mode(m, 2, mode);
@@ -1975,10 +1976,6 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
if (connector->status != connector_status_connected)
return -ENODEV;
- /* HDCP is supported by connector */
- if (!intel_connector->hdcp.shim)
- return -EINVAL;
-
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
intel_hdcp_info(m, intel_connector);
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 04/16] drm/i915: Intercept Aksv writes in the aux hooks
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an LG monitor on my desk, I noticed it was passing
back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
auth was failing as a result. Instead of copy/pasting all of the retry
logic and delays from drm dp helpers, let's just use the helpers and hide
the aksv select as best as we can.
Reviewed-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
#v4
Changes in v2:
-Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
-Bundle Aksv if statement together (Ville)
-Rename 'txbuf' to 'aksv' (Ville)
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_dp.c | 62 -
1 file changed, 29 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a417cd2af2bc..1f80a1244abbb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1534,12 +1534,27 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
txbuf[3] = msg->size - 1;
}
+static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
+{
+ /*
+* If we're trying to send the HDCP Aksv, we need to set a the Aksv
+* select bit to inform the hardware to send the Aksv after our header
+* since we can't access that data from software.
+*/
+ if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
+ msg->address == DP_AUX_HDCP_AKSV)
+ return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+
+ return 0;
+}
+
static ssize_t
intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
u8 txbuf[20], rxbuf[20];
size_t txsize, rxsize;
+ u32 flags = intel_dp_aux_xfer_flags(msg);
int ret;
intel_dp_aux_header(txbuf, msg);
@@ -1560,7 +1575,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
@@ -1583,7 +1598,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -E2BIG;
ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
- rxbuf, rxsize, 0);
+ rxbuf, rxsize, flags);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -5959,17 +5974,9 @@ static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
{
- struct intel_dp *intel_dp =
enc_to_intel_dp(to_intel_encoder(&intel_dig_port->base.base));
- static const struct drm_dp_aux_msg msg = {
- .request = DP_AUX_NATIVE_WRITE,
- .address = DP_AUX_HDCP_AKSV,
- .size = DRM_HDCP_KSV_LEN,
- };
- u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
+ u8 aksv[DRM_HDCP_KSV_LEN] = {};
ssize_t dpcd_ret;
- int ret;
- /* Output An first, that's easy */
dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux, DP_AUX_HDCP_AN,
an, DRM_HDCP_AN_LEN);
if (dpcd_ret != DRM_HDCP_AN_LEN) {
@@ -5979,29 +5986,18 @@ int intel_dp_hdcp_write_an_aksv(struct
intel_digital_port *intel_dig_port,
}
/*
-* Since Aksv is Oh-So-Secret, we can't access it in software. So in
-* order to get it on the wire, we need to create the AUX header as if
-* we were writing the data, and then tickle the hardware to output the
-* data once the header is sent out.
+* Since Aksv is Oh-So-Secret, we can't access it in software. So we
+* send an empty buffer of the correct length through the DP helpers. On
+* the other side, in the transfer hook, we'll generate a flag based on
+* the destinat
[PATCH v5 06/16] drm/i915: Factor out hdcp->value assignments
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-7-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-7-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-7-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-7-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on top of drm_* logging changes
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 67 ---
1 file changed, 46 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index d61bfea3fd28f..dfa792ee90ecd 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -880,6 +880,21 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
return container_of(hdcp, struct intel_connector, hdcp);
}
+static void intel_hdcp_update_value(struct intel_connector *connector,
+ u64 value, bool update_property)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ drm_WARN_ON(connector->base.dev, !mutex_is_locked(&hdcp->mutex));
+
+ if (hdcp->value == value)
+ return;
+
+ hdcp->value = value;
+ if (update_property)
+ schedule_work(&hdcp->prop_work);
+}
+
/* Implements Part 3 of the HDCP authorization procedure */
static int intel_hdcp_check_link(struct intel_connector *connector)
{
@@ -907,15 +922,16 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
connector->base.name, connector->base.base.id,
intel_de_read(dev_priv, HDCP_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
if (hdcp->shim->check_link(intel_dig_port)) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
}
goto out;
}
@@ -927,16 +943,18 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
ret = _intel_hdcp_disable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = _intel_hdcp_enable(connector);
if (ret) {
drm_err(&dev_priv->drm, "Failed to enable hdcp (%d)\n", ret);
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
@@ -1771,16 +1789,18 @@ static int intel_hdcp2_check_link(struct
intel_connector *connector)
"HDCP2.2 link stopped the encryption, %x\n",
intel_de_read(dev_priv, HDCP2_STATUS(dev_priv,
cpu_transcoder, port)));
ret = -ENXIO;
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
goto out;
}
ret = hdcp->shim->check_2_2_link(intel_dig_port);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- hdcp->value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
- schedule_work(&hdcp->prop_work);
+ intel_hdcp_update_value(connector,
+
[PATCH v5 05/16] drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-6-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-6-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-6-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-s/hdcp/hdmi/ in commit msg (Ram)
Changes in v4:
-Rebased on intel_de_(read|write) change
Changes in v5:
-Update hdcp->cpu_transcoder in intel_hdcp_enable so it works with pipe != 0
---
drivers/gpu/drm/i915/display/intel_ddi.c | 13 +++--
drivers/gpu/drm/i915/display/intel_ddi.h | 2 ++
.../gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c| 16 +---
drivers/gpu/drm/i915/display/intel_hdmi.c| 16 +++-
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4aff5717e9428..d27f74c8f55d0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1614,12 +1614,12 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
intel_wakeref_t wakeref;
- enum pipe pipe = 0;
int ret = 0;
u32 tmp;
@@ -1628,19 +1628,12 @@ int intel_ddi_toggle_hdcp_signalling(struct
intel_encoder *intel_encoder,
if (drm_WARN_ON(dev, !wakeref))
return -ENXIO;
- if (drm_WARN_ON(dev,
- !intel_encoder->get_hw_state(intel_encoder, &pipe))) {
- ret = -EIO;
- goto out;
- }
-
- tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(pipe));
+ tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
tmp |= TRANS_DDI_HDCP_SIGNALLING;
else
tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe), tmp);
-out:
+ intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index 55fd72b901fe4..cd1342a557e4f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -16,6 +16,7 @@ struct intel_crtc_state;
struct intel_dp;
struct intel_dpll_hw_state;
struct intel_encoder;
+enum transcoder;
void intel_ddi_fdi_post_disable(struct intel_encoder *intel_encoder,
const struct intel_crtc_state *old_crtc_state,
@@ -43,6 +44,7 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
+enum transcoder cpu_transcoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077f..bd577f143469c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -308,6 +308,7 @@ struct intel_hdcp_shim {
/* Enables HDCP signalling on the port */
int (*toggle_signalling)(struct intel_digital_port *intel_dig_port,
+enum transcoder cpu_transcoder,
bool enable);
/* Ensures the link is still protected */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1f80a1244abbb..b2e92ecd1e0ff 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6138,6 +6138,7 @@ int intel_dp_hdcp_read_v_prime_part(struct
intel_digital_port *intel_dig_port,
static
int intel_dp_hdcp_toggle_signalling(struct intel_digital_port *intel_dig_port,
+ enum transcoder cpu_transcoder,
[PATCH v5 01/16] drm/i915: Fix sha_text population code
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being placed on the wrong half of sha_text, overlapping the leftover
ksv value
3- In the sha_leftovers == 2 case, we need to manually terminate the
byte stream with 0x80 since the hardware doesn't have enough room to
add it after writing M0
The upside is that all of the HDCP supported HDMI repeaters I could
find on Amazon just strip HDCP anyways, so it turns out to be _really_
hard to hit any of these cases without an MST hub, which is not (yet)
supported. Oh, and the sha_leftovers == 1 case works perfectly!
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Rebased on intel_de_write changes
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
include/drm/drm_hdcp.h| 3 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ee0f27ea2810d..defa8654e7ac5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -338,8 +338,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Fill up the empty slots in sha_text and write it out */
sha_empty = sizeof(sha_text) - sha_leftovers;
- for (j = 0; j < sha_empty; j++)
- sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
+ for (j = 0; j < sha_empty; j++) {
+ u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
8);
+ sha_text |= ksv[j] << off;
+ }
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
@@ -437,7 +439,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
/* Write 32 bits of text */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
+ sha_text |= bstatus[0] << 8 | bstatus[1];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
@@ -452,17 +454,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
*connector,
return ret;
sha_idx += sizeof(sha_text);
}
+
+ /*
+* Terminate the SHA-1 stream by hand. For the other leftover
+* cases this is appended by the hardware.
+*/
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ rep_ctl | HDCP_SHA1_TEXT_32);
+ sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
+ ret = intel_write_sha_text(dev_priv, sha_text);
+ if (ret < 0)
+ return ret;
+ sha_idx += sizeof(sha_text);
} else if (sha_leftovers == 3) {
- /* Write 32 bits of text */
+ /* Write 32 bits of text (filled from LSB) */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_32);
- sha_text |= bstatus[0] << 24;
+ sha_text |= bstatus[0];
ret = intel_write_sha_text(dev_priv, sha_text);
if (ret < 0)
return ret;
sha_idx += sizeof(sha_text);
- /* Write 8 bits of text, 24 bits of M0 */
+ /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
intel_de_write(dev_priv, HDCP_REP_CTL,
rep_ctl | HDCP_SHA1_TEXT_8);
ret = intel_write_sha_text(dev_priv, bstatus[1]);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index c6bab4986a658..fe58dbb46962a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -29,6 +29,9 @@
/* Slave address for the HDCP registers in the recei
[PATCH v5 12/16] drm/i915: Plumb port through hdcp init
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
Changes in v5:
-Added to the set
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index f41fe9e9d6f89..abcb53975e0d5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -601,7 +601,8 @@ int intel_dp_init_hdcp(struct intel_digital_port
*intel_dig_port,
return 0;
if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
+ return intel_hdcp_init(intel_connector, port,
+ &intel_dp_hdcp_shim);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 0ee29f88bab2d..fc3ce7586084c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1959,6 +1959,7 @@ enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder
cpu_transcoder)
}
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1966,8 +1967,7 @@ static inline int initialize_hdcp_port_data(struct
intel_connector *connector,
struct hdcp_port_data *data = &hdcp->port_data;
if (INTEL_GEN(dev_priv) < 12)
- data->fw_ddi =
-
intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
+ data->fw_ddi = intel_get_mei_fw_ddi_index(port);
else
/*
* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
@@ -2034,14 +2034,14 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector,
+static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, shim);
+ ret = initialize_hdcp_port_data(connector, port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2051,6 +2051,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector,
}
int intel_hdcp_init(struct intel_connector *connector,
+ enum port port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2061,7 +2062,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv))
- intel_hdcp2_init(connector, shim);
+ intel_hdcp2_init(connector, port, shim);
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 7c12ad609b1fe..713dc20853745 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -21,7 +21,7 @@ enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector,
+int intel_hdcp_init(struct intel_connector *connector, enum port port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
enum transcoder cpu_transcoder, u8 content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 29149b59f9e40..8b32c3c986bca 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3189,7 +3189,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_hdmi->attached_connector = intel_connector;
if (is_hdcp_supported(dev_priv, port)) {
- int ret = intel_hdcp_init(intel_connector,
+ int ret = intel_hdcp_init(in
[PATCH v5 08/16] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP will
also bring down HDCP on the port.
In order to achieve this, we need to keep a refcount in intel_digital_port
and protect it using a new hdcp_mutex.
Cc: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
#v4
Changes in v2:
-Move the toggle_signalling call into _intel_hdcp_disable so it's called from
check_work
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 ++
.../drm/i915/display/intel_display_types.h| 5 ++
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 53 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +
5 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d27f74c8f55d0..48910a2ce 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4452,6 +4452,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_encoder_init(&dev_priv->drm, &encoder->base, &intel_ddi_funcs,
DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
+ mutex_init(&intel_dig_port->hdcp_mutex);
+ intel_dig_port->num_hdcp_streams = 0;
+
encoder->hotplug = intel_ddi_hotplug;
encoder->compute_output_type = intel_ddi_compute_output_type;
encoder->compute_config = intel_ddi_compute_config;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index bd577f143469c..04161993e2038 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1388,6 +1388,11 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ /* protects num_hdcp_streams reference count */
+ struct mutex hdcp_mutex;
+ /* the number of pipes using HDCP signalling out of this port */
+ unsigned int num_hdcp_streams;
+
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2e92ecd1e0ff..4a38012a1fb03 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7800,6 +7800,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
intel_encoder = &intel_dig_port->base;
encoder = &intel_encoder->base;
+ mutex_init(&intel_dig_port->hdcp_mutex);
+
if (drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
&intel_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
"DP %c", port_name(port)))
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 9523ab6c65e0d..0ee29f88bab2d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -803,6 +803,19 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ /*
+* If there are other connectors on this port using HDCP, don't disable
+* it. Instead, toggle the HDCP signalling off on that particular
+* connector/pipe and exit.
+*/
+ if (intel_dig_port->num_hdcp_streams > 0) {
+ ret = hdcp->shim->toggle_signalling(intel_dig_port,
+ cpu_transcoder, false);
+ if (ret)
+ DRM_ERROR("Failed to disable HDCP signalling\n");
+ return ret;
+ }
+
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
@@ -883,6 +896,8 @@ struct intel_connector *intel_hdcp_to_connector(struct
intel_hdcp *hdcp)
static void intel_hdcp_update_value(struct intel_connector *connector,
u64 value
[PATCH v5 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors
From: Sean Paul Hello friends, Another version of HDCP over MST rebased on -tip (pls stop refactoring stuff!). I've also added a couple of fixes to fix bugs found when I did some testing I on a non-CrOS laptop. PTAL, Sean Sean Paul (16): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drm/i915: WARN if HDCP signalling is enabled upon disable drm/i915: Intercept Aksv writes in the aux hooks drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP signalling drm/i915: Factor out hdcp->value assignments drm/i915: Protect workers against disappearing connectors drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it drm/i915: Support DP MST in enc_to_dig_port() function drm/i915: Use ddi_update_pipe in intel_dp_mst drm/i915: Factor out HDCP shim functions from dp for use by dp_mst drm/i915: Plumb port through hdcp init drm/i915: Add connector to hdcp_shim->check_link() drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message drm/i915: Print HDCP version info for all connectors drm/i915: Add HDCP 1.4 support for MST connectors drivers/gpu/drm/drm_dp_mst_topology.c | 117 +++ drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 27 +- drivers/gpu/drm/i915/display/intel_ddi.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 30 +- drivers/gpu/drm/i915/display/intel_dp.c | 624 +-- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 712 ++ drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 + drivers/gpu/drm/i915/display/intel_hdcp.c | 217 -- drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 25 +- include/drm/drm_dp_helper.h | 3 + include/drm/drm_dp_mst_helper.h | 44 ++ include/drm/drm_hdcp.h| 3 + 16 files changed, 1155 insertions(+), 695 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 03/16] drm/i915: WARN if HDCP signalling is enabled upon disable
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run
#v4
Changes in v2:
-Added to the set in lieu of just clearing the bit
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 73d0f4648c06a..4aff5717e9428 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1593,6 +1593,8 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
val = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
val &= ~TRANS_DDI_FUNC_ENABLE;
+ drm_WARN_ON(crtc->base.dev, val & TRANS_DDI_HDCP_SIGNALLING);
+
if (INTEL_GEN(dev_priv) >= 12) {
if (!intel_dp_mst_is_master_trans(crtc_state)) {
val &= ~(TGL_TRANS_DDI_PORT_MASK |
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 07/16] drm/i915: Protect workers against disappearing connectors
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do a synchronous wait since it needs
to take connection_mutex which could cause deadlock. Instead, we'll take
a reference on the connector when scheduling prop_work and give it up
once we're done.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-8-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-8-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-8-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-Change the WARN_ON condition in intel_hdcp_cleanup to allow for
initializing connectors as well
Changes in v4:
-None
Changes in v5:
-Change WARN_ON to drm_WARN_ON
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 44 ---
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index dfa792ee90ecd..9523ab6c65e0d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -891,8 +891,10 @@ static void intel_hdcp_update_value(struct intel_connector
*connector,
return;
hdcp->value = value;
- if (update_property)
+ if (update_property) {
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
+ }
}
/* Implements Part 3 of the HDCP authorization procedure */
@@ -984,6 +986,8 @@ static void intel_hdcp_prop_work(struct work_struct *work)
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev_priv->drm.mode_config.connection_mutex);
+
+ drm_connector_put(&connector->base);
}
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
@@ -1862,6 +1866,9 @@ static void intel_hdcp_check_work(struct work_struct
*work)
check_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
+ if (drm_connector_is_unregistered(&connector->base))
+ return;
+
if (!intel_hdcp2_check_link(connector))
schedule_delayed_work(&hdcp->check_work,
DRM_HDCP2_CHECK_PERIOD_MS);
@@ -2178,12 +2185,39 @@ void intel_hdcp_component_fini(struct drm_i915_private
*dev_priv)
void intel_hdcp_cleanup(struct intel_connector *connector)
{
- if (!connector->hdcp.shim)
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
return;
- mutex_lock(&connector->hdcp.mutex);
- kfree(connector->hdcp.port_data.streams);
- mutex_unlock(&connector->hdcp.mutex);
+ /*
+* If the connector is registered, it's possible userspace could kick
+* off another HDCP enable, which would re-spawn the workers.
+*/
+ drm_WARN_ON(connector->base.dev,
+ connector->base.registration_state == DRM_CONNECTOR_REGISTERED);
+
+ /*
+* Now that the connector is not registered, check_work won't be run,
+* but cancel any outstanding instances of it
+*/
+ cancel_delayed_work_sync(&hdcp->check_work);
+
+ /*
+* We don't cancel prop_work in the same way as check_work since it
+* requires connection_mutex which could be held while calling this
+* function. Instead, we rely on the connector references grabbed before
+* scheduling prop_work to ensure the connector is alive when prop_work
+* is run. So if we're in the destroy path (which is where this
+* function should be called), we're "guaranteed" that prop_work is not
+* active (tl;dr This Should Never Happen).
+*/
+ drm_WARN_ON(connector->base.dev, work_pending(&hdcp->prop_work));
+
+ mutex_lock(&hdcp->mutex);
+ kfree(hdcp->port_data.streams);
+ hdcp->shim = NULL;
+ mutex_unlock(&hdcp->mutex);
}
void intel_hdcp_atomic_check(struct drm_connector *connector,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 02/16] drm/i915: Clear the repeater bit on HDCP disable
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-...@lists.freedesktop.org
Cc: # v4.17+
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
#v4
Changes in v2:
-Added to the set
Changes in v3:
-None
I had previously agreed that clearing the rep_ctl bits on enable would
also be a good idea. However when I committed that idea to code, it
didn't look right. So let's rely on enables and disables being paired
and everything outside of that will be considered a bug
Changes in v4:
-s/I915_(READ|WRITE)/intel_de_(read|write)/
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index defa8654e7ac5..553f5ff617a15 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -797,6 +797,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
struct intel_hdcp *hdcp = &connector->hdcp;
enum port port = intel_dig_port->base.port;
enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ u32 repeater_ctl;
int ret;
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
@@ -812,6 +813,11 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return -ETIMEDOUT;
}
+ repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
+ port);
+ intel_de_write(dev_priv, HDCP_REP_CTL,
+ intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
+
ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
if (ret) {
drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n");
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 09/16] drm/i915: Support DP MST in enc_to_dig_port() function
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
.../drm/i915/display/intel_display_types.h| 21 ---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 04161993e2038..3cac51955f250 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1502,6 +1502,18 @@ static inline bool intel_encoder_is_dig_port(struct
intel_encoder *encoder)
}
}
+static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
+{
+ return encoder->type == INTEL_OUTPUT_DP_MST;
+}
+
+static inline struct intel_dp_mst_encoder *
+enc_to_mst(struct intel_encoder *encoder)
+{
+ return container_of(&encoder->base, struct intel_dp_mst_encoder,
+ base.base);
+}
+
static inline struct intel_digital_port *
enc_to_dig_port(struct intel_encoder *encoder)
{
@@ -1510,6 +1522,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
if (intel_encoder_is_dig_port(intel_encoder))
return container_of(&encoder->base, struct intel_digital_port,
base.base);
+ else if (intel_encoder_is_mst(intel_encoder))
+ return enc_to_mst(encoder)->primary;
else
return NULL;
}
@@ -1520,13 +1534,6 @@ intel_attached_dig_port(struct intel_connector
*connector)
return enc_to_dig_port(intel_attached_encoder(connector));
}
-static inline struct intel_dp_mst_encoder *
-enc_to_mst(struct intel_encoder *encoder)
-{
- return container_of(&encoder->base, struct intel_dp_mst_encoder,
- base.base);
-}
-
static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
{
return &enc_to_dig_port(encoder)->dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 10/16] drm/i915: Use ddi_update_pipe in intel_dp_mst
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-s...@poorly.run
#v2
Link:
https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-s...@poorly.run
#v3
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-s...@poorly.run
#v4
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-None
Changes in v5:
-None
---
drivers/gpu/drm/i915/display/intel_ddi.c| 9 +
drivers/gpu/drm/i915/display/intel_dp.h | 4
drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 48910a2ce..149937da20586 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3695,12 +3695,13 @@ static void intel_ddi_update_pipe_dp(struct
intel_encoder *encoder,
intel_panel_update_backlight(encoder, crtc_state, conn_state);
}
-static void intel_ddi_update_pipe(struct intel_encoder *encoder,
- const struct intel_crtc_state *crtc_state,
- const struct drm_connector_state *conn_state)
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_encoder_is_mst(encoder))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
intel_hdcp_update_pipe(encoder, crtc_state, conn_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 0c7be8ed1423a..ae4a1517632bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -123,4 +123,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int
lane_count)
u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
+void intel_ddi_update_pipe(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state);
+
#endif /* __INTEL_DP_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 39f5de9a8c7ce..af658c76125c1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -787,6 +787,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
intel_encoder->compute_config = intel_dp_mst_compute_config;
intel_encoder->disable = intel_mst_disable_dp;
intel_encoder->post_disable = intel_mst_post_disable_dp;
+ intel_encoder->update_pipe = intel_ddi_update_pipe;
intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
intel_encoder->pre_enable = intel_mst_pre_enable_dp;
intel_encoder->enable = intel_mst_enable_dp;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Thu, 2020-03-05 at 13:52 -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 20:29 +0200, Ville Syrjälä wrote:
> > On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> > > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > > > It's next to impossible for us to do connector probing on topologies
> > > > > without occasionally racing with userspace, since creating a
> > > > > connector
> > > > > itself causes a hotplug event which we have to send before probing
> > > > > the
> > > > > available PBN of a connector. Even if we didn't have this hotplug
> > > > > event
> > > > > sent, there's still always a chance that userspace started probing
> > > > > connectors before we finished probing the topology.
> > > > >
> > > > > This can be a problem when validating a new MST state since the
> > > > > connector will be shown as connected briefly, but without any
> > > > > available
> > > > > PBN - causing any atomic state which would enable said connector to
> > > > > fail
> > > > > with -ENOSPC. So, let's simply workaround this by telling userspace
> > > > > new
> > > > > MST connectors are disconnected until we've finished probing their
> > > > > PBN.
> > > > > Since we always send a hotplug event at the end of the link address
> > > > > probing process, userspace will still know to reprobe the connector
> > > > > when
> > > > > we're ready.
> > > > >
> > > > > Signed-off-by: Lyude Paul
> > > > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to
> > > > > MST
> > > > > atomic check")
> > > > > Cc: Mikita Lipski
> > > > > Cc: Alex Deucher
> > > > > Cc: Sean Paul
> > > > > Cc: Hans de Goede
> > > > > ---
> > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> > > > > 1 file changed, 13 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > index 207eef08d12c..7b0ff0cff954 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector
> > > > > *connector,
> > > > > ret = connector_status_connected;
> > > > > break;
> > > > > }
> > > > > +
> > > > > + /* We don't want to tell userspace the port is actually
> > > > > plugged into
> > > > > + * anything until we've finished probing it's available_pbn,
> > > > > otherwise
> > > >
> > > > "its"
> > > >
> > > > Why is the connector even registered before we've finished the probe?
> > > >
> > > Oops, I'm not sure how I did this by accident but the explanation I gave
> > > in
> > > the commit message was uh, completely wrong. I must have forgotten that
> > > I
> > > made
> > > sure we didn't expose connectors before probing their PBN back when I
> > > started
> > > my MST cleanup
> > >
> > > So: despite what I said before it's not actually when new connectors are
> > > created, it's when downstream hotplugs happen which means that the
> > > conenctor's
> > > always going to be there before we probe the available_pbn.
> >
> > Not sure I understand. You're saying this is going to change for already
> > existing connectors when something else gets plugged in, and either we
> > zero it out during the probe or it always was zero to begin with for
> > whatever reason?
>
> So: you just made me realize that I'm not actually sure whether there's any
> point to us clearing port->available_pbn here since the available_pbn (at
> least the value that we cache on initial link address probing for bandwidth
> constraint checking) shouldn't actually change on a port just because of a
> hotplug. I bet this is probably causing more problems on it's own as well,
> since reprobing the available_pbn might actually give us a value that
> reflects
> allocations on other ports that are already in place.
>
> So: I think what I'm going to do instead is make it so that we never clear
> port->available_pbn; mainly to make things less complicated during
> suspend/resume, since we want to make sure there's always some sort of PBN
> value populated even during the middle of reprobing the link address on
> resume. That way we don't have to pretend that it's ever disconnected
> either.
> Will send a respin in a bit.
Wait, nope, I believe I am the fool here - _supposedly_ available bw is
supposed to reflect the smallest link rate that occurs in a patch to a branch
device. I think, me and sean paul are looking at this a bit more closely. I
think I might need to do some more playing around with my hubs to make sure
this value is actually what we think it is because unfortunately the spec is
pretty vague on this from what I can tell :(
>
> > > I did just notice
> > > though that we send a hotplug on connection status notifications even
> > > before
> > > we've finished the PBN probe, so I might be able to
Re: [PATCH 2/8] drm/radeon: don't use ttm bo->offset
[AMD Official Use Only - Internal Distribution Only]
I believe bo->tbo.mem.mem_type is of uint32_t type and not an enum, is the
index lookup method safe? (i.e., how do you deal with the possibility of having
value TTM_PL_PRIV or above or are you suggesting those are not possible for
this function.)
Kenny
From: Tuikov, Luben
Sent: Thursday, March 5, 2020 2:19 PM
To: Nirmoy Das ; dri-devel@lists.freedesktop.org
Cc: Zhou, David(ChunMing) ; thellst...@vmware.com
; airl...@linux.ie ; Ho, Kenny
; brian.we...@intel.com ;
maarten.lankho...@linux.intel.com ;
amd-...@lists.freedesktop.org ; Das, Nirmoy
; linux-graphics-maintai...@vmware.com
; bske...@redhat.com
; dan...@ffwll.ch ; Deucher, Alexander
; s...@poorly.run ; Koenig,
Christian ; kra...@redhat.com
Subject: Re: [PATCH 2/8] drm/radeon: don't use ttm bo->offset
On 2020-03-05 08:29, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
> drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
> 3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 30e32adc1fc6..b7c3fb2bfb54 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
> radeon_device *rdev, u64 size
> extern void radeon_program_register_sequence(struct radeon_device *rdev,
> const u32 *registers,
> const u32 array_size);
> +struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
>
> /*
> * vm
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index d23f2ed4126e..60275b822f79 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo
> *bo)
> */
> static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
> {
> - return bo->tbo.offset;
> + struct radeon_device *rdev;
> + u64 start = 0;
> +
> + rdev = radeon_get_rdev(bo->tbo.bdev);
> +
> + switch (bo->tbo.mem.mem_type) {
> + case TTM_PL_TT:
> + start = rdev->mc.gtt_start;
> + break;
> + case TTM_PL_VRAM:
> + start = rdev->mc.vram_start;
> + break;
> + }
> +
> + return (bo->tbo.mem.start << PAGE_SHIFT) + start;
> }
You're removing a "return bo->tbo.offset" and adding a
switch-case statement. So, then, now instead of an instant
lookup, you're adding branching. You're adding comparison
and branching. Do you think that's better? Faster? Smaller?
I've written before about this for this patch: Why not create a map,
whose index is "mem_type" which references the desired
address? No comparison, no branching. Just an index-dereference
and a value:
return rdev->mc.mem_start_map[bo->tbo.mem.mem_type];
Obviously, you'll have to create "mem_start_map".
That's a NAK from me on this patch using comparison
and branching to return static data lookup value.
Regards,
Luben
>
> static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index badf1b6d1549..1c8303468e8f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -56,7 +56,7 @@
> static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
> static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
>
> -static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
> +struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
> {
>struct radeon_mman *mman;
>struct radeon_device *rdev;
> @@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
>break;
>case TTM_PL_TT:
>man->func = &ttm_bo_manager_func;
> - man->gpu_offset = rdev->mc.gtt_start;
>man->available_caching = TTM_PL_MASK_CACHING;
>man->default_caching = TTM_PL_FLAG_CACHED;
>man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> @@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
>case TTM_PL_VRAM:
>/* "On-card" video ram */
>man->func = &ttm_bo_manager_func;
> - man->gpu_offset = rdev->mc.vram_start;
>man->flags = TTM_MEMTYPE_FLAG_FIXED |
> TTM_MEMTYPE_FLAG_MAPPABLE;
>man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
Re: [PATCH 4/8] drm/nouveau: don't use ttm bo->offset v3
On 2020-03-05 08:29, Nirmoy Das wrote:
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
> drivers/gpu/drm/nouveau/nouveau_bo.c| 8
> drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
> drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
> 15 files changed, 35 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 1f08de4241e0..d06a93f2b38a 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
> fb = nouveau_framebuffer(crtc->primary->fb);
> }
>
> - nv_crtc->fb.offset = fb->nvbo->bo.offset;
> + nv_crtc->fb.offset = fb->nvbo->offset;
>
> if (nv_crtc->lut.depth != drm_fb->format->depth) {
> nv_crtc->lut.depth = drm_fb->format->depth;
> @@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
> drm_file *file_priv,
> nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
>
> nouveau_bo_unmap(cursor);
> - nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
> + nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
> nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
> nv_crtc->cursor.show(nv_crtc, true);
> out:
> @@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
> drm_framebuffer *fb,
> /* Initialize a page flip struct */
> *s = (struct nv04_page_flip_state)
> { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
> - new_bo->bo.offset };
> + new_bo->offset };
>
> /* Keep vblanks on during flip, for the target crtc of this flip */
> drm_crtc_vblank_get(crtc);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 44ee82d0c9b6..89a4ddfcc55f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume,
> bool runtime)
> continue;
>
> if (nv_crtc->cursor.set_offset)
> - nv_crtc->cursor.set_offset(nv_crtc,
> nv_crtc->cursor.nvbo->bo.offset);
> + nv_crtc->cursor.set_offset(nv_crtc,
> nv_crtc->cursor.nvbo->offset);
> nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
>nv_crtc->cursor_saved_y);
> }
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> index a3a0a73ae8ab..9529bd9053e7 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> @@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
>
> nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
> - nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
> + nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
> nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
> nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
> nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
> @@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> if (format & NV_PVIDEO_FORMAT_PLANAR) {
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
> - nv_fb->nvbo->bo.offset + fb->offsets[1]);
> + nv_fb->nvbo->offset + fb->offsets[1]);
> }
> nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
> nvif_wr32(dev, NV_PVIDEO_STOP, 0);
> @@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
>
> for (i = 0; i < 2; i++) {
> nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
> - nv_fb->nvbo->bo.offset);
> + nv_fb->nvbo->offset);
>
Re: [PATCH 2/8] drm/radeon: don't use ttm bo->offset
On 2020-03-05 08:29, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
> drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
> 3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 30e32adc1fc6..b7c3fb2bfb54 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
> radeon_device *rdev, u64 size
> extern void radeon_program_register_sequence(struct radeon_device *rdev,
>const u32 *registers,
>const u32 array_size);
> +struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
>
> /*
> * vm
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index d23f2ed4126e..60275b822f79 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo
> *bo)
> */
> static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
> {
> - return bo->tbo.offset;
> + struct radeon_device *rdev;
> + u64 start = 0;
> +
> + rdev = radeon_get_rdev(bo->tbo.bdev);
> +
> + switch (bo->tbo.mem.mem_type) {
> + case TTM_PL_TT:
> + start = rdev->mc.gtt_start;
> + break;
> + case TTM_PL_VRAM:
> + start = rdev->mc.vram_start;
> + break;
> + }
> +
> + return (bo->tbo.mem.start << PAGE_SHIFT) + start;
> }
You're removing a "return bo->tbo.offset" and adding a
switch-case statement. So, then, now instead of an instant
lookup, you're adding branching. You're adding comparison
and branching. Do you think that's better? Faster? Smaller?
I've written before about this for this patch: Why not create a map,
whose index is "mem_type" which references the desired
address? No comparison, no branching. Just an index-dereference
and a value:
return rdev->mc.mem_start_map[bo->tbo.mem.mem_type];
Obviously, you'll have to create "mem_start_map".
That's a NAK from me on this patch using comparison
and branching to return static data lookup value.
Regards,
Luben
>
> static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index badf1b6d1549..1c8303468e8f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -56,7 +56,7 @@
> static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
> static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
>
> -static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
> +struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
> {
> struct radeon_mman *mman;
> struct radeon_device *rdev;
> @@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> break;
> case TTM_PL_TT:
> man->func = &ttm_bo_manager_func;
> - man->gpu_offset = rdev->mc.gtt_start;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> @@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &ttm_bo_manager_func;
> - man->gpu_offset = rdev->mc.vram_start;
> man->flags = TTM_MEMTYPE_FLAG_FIXED |
>TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> --
> 2.25.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cluben.tuikov%40amd.com%7Cca6004a5ac7a400a030708d7c108bcde%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637190115619487827&sdata=EkSy4vpUIbTE%2B75CSO37JWiULKbRTYbcZUSEtRpcrTk%3D&reserved=0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo
On 2020-03-05 08:29, Nirmoy Das wrote:
> GPU address should belong to driver not in memory management.
> This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
>
> Signed-off-by: Nirmoy Das
> Acked-by: Huang Rui
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
> 4 files changed, 44 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 1791c084787d..52c7e579f2d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -918,7 +918,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
> domain,
> bo->pin_count++;
>
> if (max_offset != 0) {
> - u64 domain_start =
> bo->tbo.bdev->man[mem_type].gpu_offset;
> + u64 domain_start = amdgpu_ttm_domain_start(adev,
> mem_type);
> WARN_ON_ONCE(max_offset <
>(amdgpu_bo_gpu_offset(bo) - domain_start));
> }
> @@ -1483,7 +1483,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
> WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
>!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
>
> - return amdgpu_gmc_sign_extend(bo->tbo.offset);
> + return amdgpu_bo_gpu_offset_no_check(bo);
> +}
> +
> +/**
> + * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
> + * @bo: amdgpu object for which we query the offset
> + *
> + * Returns:
> + * current GPU offset of the object without raising warnings.
> + */
> +u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
> +{
> + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> + uint64_t offset;
> +
> +offset = (bo->tbo.mem.start << PAGE_SHIFT) +
> + amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
Align the above assignment, "offset" is out of alignment, as is the line
following it.
Regards,
Luben
> +
> + return amdgpu_gmc_sign_extend(offset);
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index 5e39ecd8cc28..32edd35d2ccf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -282,6 +282,7 @@ int amdgpu_bo_sync_wait_resv(struct amdgpu_device *adev,
> struct dma_resv *resv,
>bool intr);
> int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
> u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
> +u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
> int amdgpu_bo_validate(struct amdgpu_bo *bo);
> int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
>struct dma_fence **fence);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index fe131c21e8a3..87781fabf5f5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -96,7 +96,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_TT:
> /* GTT memory */
> man->func = &amdgpu_gtt_mgr_func;
> - man->gpu_offset = adev->gmc.gart_start;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
> @@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &amdgpu_vram_mgr_func;
> - man->gpu_offset = adev->gmc.vram_start;
> man->flags = TTM_MEMTYPE_FLAG_FIXED |
>TTM_MEMTYPE_FLAG_MAPPABLE;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> @@ -115,7 +113,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case AMDGPU_PL_OA:
> /* On-chip GDS memory*/
> man->func = &ttm_bo_manager_func;
> - man->gpu_offset = 0;
> man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
> man->available_caching = TTM_PL_FLAG_UNCACHED;
> man->default_caching = TTM_PL_FLAG_UNCACHED;
> @@ -263,7 +260,7 @@ static uint64_t amdgpu_mm_node_addr(struct
> ttm_buffer_object *bo,
>
> if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
> addr = mm_node->start << PAGE_SHIFT;
> - addr += bo->bdev->man[mem->mem_type].gpu_offset;
> + addr += amdgpu_ttm_domain_start
[pull] amdgpu 5.6 fixes
Hi Dave, Daniel, Fixes for 5.6. The following changes since commit 70b8ea1ab1d3ff3ad5c7491bf8995c912506da6c: Merge tag 'mediatek-drm-fixes-5.6' of https://github.com/ckhu-mediatek/linux.git-tags into drm-fixes (2020-03-05 12:59:44 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.6-2020-03-05 for you to fetch changes up to 09ed6ba43e659474878b22d40b141a01d09ec857: drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3 (v2) (2020-03-05 09:42:08 -0500) amd-drm-fixes-5.6-2020-03-05: amdgpu: - Gfx reset fix for gfx9, 10 - Fix for gfx10 - DP MST fix - DCC fix - Renoir power fixes - Navi power fix Bhawanpreet Lakha (1): drm/amd/display: Clear link settings on MST disable connector Hersen Wu (1): drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3 (v2) Josip Pavic (1): drm/amd/display: fix dcc swath size calculations on dcn1 Prike Liang (2): drm/amd/powerplay: fix pre-check condition for setting clock range drm/amd/powerplay: map mclk to fclk for COMBINATIONAL_BYPASS case Tianci.Yin (1): drm/amdgpu: disable 3D pipe 1 on Navi1x Yintian Tao (1): drm/amdgpu: clean wptr on wb when gpu recovery drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 98 -- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 69 +++ .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 1 + .../gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c| 4 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +- drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 6 +- drivers/gpu/drm/amd/powerplay/smu_v12_0.c | 3 - 8 files changed, 129 insertions(+), 55 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Thu, 2020-03-05 at 20:29 +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > > It's next to impossible for us to do connector probing on topologies
> > > > without occasionally racing with userspace, since creating a connector
> > > > itself causes a hotplug event which we have to send before probing the
> > > > available PBN of a connector. Even if we didn't have this hotplug
> > > > event
> > > > sent, there's still always a chance that userspace started probing
> > > > connectors before we finished probing the topology.
> > > >
> > > > This can be a problem when validating a new MST state since the
> > > > connector will be shown as connected briefly, but without any
> > > > available
> > > > PBN - causing any atomic state which would enable said connector to
> > > > fail
> > > > with -ENOSPC. So, let's simply workaround this by telling userspace
> > > > new
> > > > MST connectors are disconnected until we've finished probing their
> > > > PBN.
> > > > Since we always send a hotplug event at the end of the link address
> > > > probing process, userspace will still know to reprobe the connector
> > > > when
> > > > we're ready.
> > > >
> > > > Signed-off-by: Lyude Paul
> > > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to
> > > > MST
> > > > atomic check")
> > > > Cc: Mikita Lipski
> > > > Cc: Alex Deucher
> > > > Cc: Sean Paul
> > > > Cc: Hans de Goede
> > > > ---
> > > > drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 207eef08d12c..7b0ff0cff954 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector
> > > > *connector,
> > > > ret = connector_status_connected;
> > > > break;
> > > > }
> > > > +
> > > > + /* We don't want to tell userspace the port is actually
> > > > plugged into
> > > > +* anything until we've finished probing it's available_pbn,
> > > > otherwise
> > >
> > > "its"
> > >
> > > Why is the connector even registered before we've finished the probe?
> > >
> > Oops, I'm not sure how I did this by accident but the explanation I gave
> > in
> > the commit message was uh, completely wrong. I must have forgotten that I
> > made
> > sure we didn't expose connectors before probing their PBN back when I
> > started
> > my MST cleanup
> >
> > So: despite what I said before it's not actually when new connectors are
> > created, it's when downstream hotplugs happen which means that the
> > conenctor's
> > always going to be there before we probe the available_pbn.
>
> Not sure I understand. You're saying this is going to change for already
> existing connectors when something else gets plugged in, and either we
> zero it out during the probe or it always was zero to begin with for
> whatever reason?
So: you just made me realize that I'm not actually sure whether there's any
point to us clearing port->available_pbn here since the available_pbn (at
least the value that we cache on initial link address probing for bandwidth
constraint checking) shouldn't actually change on a port just because of a
hotplug. I bet this is probably causing more problems on it's own as well,
since reprobing the available_pbn might actually give us a value that reflects
allocations on other ports that are already in place.
So: I think what I'm going to do instead is make it so that we never clear
port->available_pbn; mainly to make things less complicated during
suspend/resume, since we want to make sure there's always some sort of PBN
value populated even during the middle of reprobing the link address on
resume. That way we don't have to pretend that it's ever disconnected either.
Will send a respin in a bit.
>
> > I did just notice
> > though that we send a hotplug on connection status notifications even
> > before
> > we've finished the PBN probe, so I might be able to improve on that as
> > well.
> > We still definitely want to report the connector as disconnected before we
> > have the available PBN though, in case another probe was already going
> > before
> > we got the connection status notification.
> >
> > I'll make sure to fixup the explanation in the commit message on the next
> > respin
> >
> > > > +* userspace will see racy atomic check failures
> > > > +*
> > > > +* Since we always send a hotplug at the end of probing
> > > > topology
> > > > +* state, we can just let userspace reprobe this connector
> > > > later.
> > > > +*/
> > > > + if (ret == connector_status_connected && !port
Re: [PATCH] drm: komeda: Make rt_pm_ops dependent on CONFIG_PM
On Wed, Mar 04, 2020 at 02:54:12PM +, Vincenzo Frascino wrote:
> komeda_rt_pm_suspend() and komeda_rt_pm_resume() are compiled only when
> CONFIG_PM is enabled. Having it disabled triggers the following warning
> at compile time:
>
> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:156:12:
> warning: ‘komeda_rt_pm_resume’ defined but not used [-Wunused-function]
> static int komeda_rt_pm_resume(struct device *dev)
> ^~~
> linux/drivers/gpu/drm/arm/display/komeda/komeda_drv.c:149:12:
> warning: ‘komeda_rt_pm_suspend’ defined but not used [-Wunused-function]
> static int komeda_rt_pm_suspend(struct device *dev)
>
> Make komeda_rt_pm_suspend() and komeda_rt_pm_resume() dependent on
> CONFIG_PM to address the issue.
>
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Vincenzo Frascino
Acked-by: Liviu Dudau
Thanks for the patch, I will push it into drm-misc-fixes tomorrow.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index ea5cd1e17304..dd3ae3d88687 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -146,6 +146,7 @@ static const struct of_device_id komeda_of_match[] = {
>
> MODULE_DEVICE_TABLE(of, komeda_of_match);
>
> +#ifdef CONFIG_PM
> static int komeda_rt_pm_suspend(struct device *dev)
> {
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
> @@ -159,6 +160,7 @@ static int komeda_rt_pm_resume(struct device *dev)
>
> return komeda_dev_resume(mdrv->mdev);
> }
> +#endif /* CONFIG_PM */
>
> static int __maybe_unused komeda_pm_suspend(struct device *dev)
> {
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > It's next to impossible for us to do connector probing on topologies
> > > without occasionally racing with userspace, since creating a connector
> > > itself causes a hotplug event which we have to send before probing the
> > > available PBN of a connector. Even if we didn't have this hotplug event
> > > sent, there's still always a chance that userspace started probing
> > > connectors before we finished probing the topology.
> > >
> > > This can be a problem when validating a new MST state since the
> > > connector will be shown as connected briefly, but without any available
> > > PBN - causing any atomic state which would enable said connector to fail
> > > with -ENOSPC. So, let's simply workaround this by telling userspace new
> > > MST connectors are disconnected until we've finished probing their PBN.
> > > Since we always send a hotplug event at the end of the link address
> > > probing process, userspace will still know to reprobe the connector when
> > > we're ready.
> > >
> > > Signed-off-by: Lyude Paul
> > > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > > atomic check")
> > > Cc: Mikita Lipski
> > > Cc: Alex Deucher
> > > Cc: Sean Paul
> > > Cc: Hans de Goede
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index 207eef08d12c..7b0ff0cff954 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector
> > > *connector,
> > > ret = connector_status_connected;
> > > break;
> > > }
> > > +
> > > + /* We don't want to tell userspace the port is actually plugged into
> > > + * anything until we've finished probing it's available_pbn, otherwise
> >
> > "its"
> >
> > Why is the connector even registered before we've finished the probe?
> >
> Oops, I'm not sure how I did this by accident but the explanation I gave in
> the commit message was uh, completely wrong. I must have forgotten that I made
> sure we didn't expose connectors before probing their PBN back when I started
> my MST cleanup
>
> So: despite what I said before it's not actually when new connectors are
> created, it's when downstream hotplugs happen which means that the conenctor's
> always going to be there before we probe the available_pbn.
Not sure I understand. You're saying this is going to change for already
existing connectors when something else gets plugged in, and either we
zero it out during the probe or it always was zero to begin with for
whatever reason?
> I did just notice
> though that we send a hotplug on connection status notifications even before
> we've finished the PBN probe, so I might be able to improve on that as well.
> We still definitely want to report the connector as disconnected before we
> have the available PBN though, in case another probe was already going before
> we got the connection status notification.
>
> I'll make sure to fixup the explanation in the commit message on the next
> respin
>
> > > + * userspace will see racy atomic check failures
> > > + *
> > > + * Since we always send a hotplug at the end of probing topology
> > > + * state, we can just let userspace reprobe this connector later.
> > > + */
> > > + if (ret == connector_status_connected && !port->available_pbn) {
> > > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] not ready yet (PBN not
> > > probed)\n",
> > > + connector->base.id, connector->name);
> > > + ret = connector_status_disconnected;
> > > + }
> > > out:
> > > drm_dp_mst_topology_put_port(port);
> > > return ret;
> > > --
> > > 2.24.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> Cheers,
> Lyude Paul (she/her)
> Associate Software Engineer at Red Hat
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/bridge: anx7688: Add anx7688 bridge driver support
On Thu, Mar 5, 2020 at 7:28 AM Enric Balletbo i Serra wrote: > > Hi Vasily, CC: Icenowy and Ondrej > > Would you mind to check which firmware version is running the anx7688 in > PinePhone, I think should be easy to check with i2c-tools. Icenowy, Ondrej, can you guys please check anx7688 firmware version? > Thanks in advance, > Enric > > [snip] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > It's next to impossible for us to do connector probing on topologies
> > without occasionally racing with userspace, since creating a connector
> > itself causes a hotplug event which we have to send before probing the
> > available PBN of a connector. Even if we didn't have this hotplug event
> > sent, there's still always a chance that userspace started probing
> > connectors before we finished probing the topology.
> >
> > This can be a problem when validating a new MST state since the
> > connector will be shown as connected briefly, but without any available
> > PBN - causing any atomic state which would enable said connector to fail
> > with -ENOSPC. So, let's simply workaround this by telling userspace new
> > MST connectors are disconnected until we've finished probing their PBN.
> > Since we always send a hotplug event at the end of the link address
> > probing process, userspace will still know to reprobe the connector when
> > we're ready.
> >
> > Signed-off-by: Lyude Paul
> > Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> > atomic check")
> > Cc: Mikita Lipski
> > Cc: Alex Deucher
> > Cc: Sean Paul
> > Cc: Hans de Goede
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 207eef08d12c..7b0ff0cff954 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector
> > *connector,
> > ret = connector_status_connected;
> > break;
> > }
> > +
> > + /* We don't want to tell userspace the port is actually plugged into
> > +* anything until we've finished probing it's available_pbn, otherwise
>
> "its"
>
> Why is the connector even registered before we've finished the probe?
>
Oops, I'm not sure how I did this by accident but the explanation I gave in
the commit message was uh, completely wrong. I must have forgotten that I made
sure we didn't expose connectors before probing their PBN back when I started
my MST cleanup
So: despite what I said before it's not actually when new connectors are
created, it's when downstream hotplugs happen which means that the conenctor's
always going to be there before we probe the available_pbn. I did just notice
though that we send a hotplug on connection status notifications even before
we've finished the PBN probe, so I might be able to improve on that as well.
We still definitely want to report the connector as disconnected before we
have the available PBN though, in case another probe was already going before
we got the connection status notification.
I'll make sure to fixup the explanation in the commit message on the next
respin
> > +* userspace will see racy atomic check failures
> > +*
> > +* Since we always send a hotplug at the end of probing topology
> > +* state, we can just let userspace reprobe this connector later.
> > +*/
> > + if (ret == connector_status_connected && !port->available_pbn) {
> > + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] not ready yet (PBN not
> > probed)\n",
> > + connector->base.id, connector->name);
> > + ret = connector_status_disconnected;
> > + }
> > out:
> > drm_dp_mst_topology_put_port(port);
> > return ret;
> > --
> > 2.24.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Cheers,
Lyude Paul (she/her)
Associate Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction.
On Wed, Feb 19, 2020 at 6:00 AM Lin, Wayne wrote: > > [AMD Public Use] > > > > > -Original Message- > > From: Sean Paul > > Sent: Wednesday, February 19, 2020 1:15 AM > > To: Lin, Wayne > > Cc: Sean Paul ; dri-devel@lists.freedesktop.org; > > ly...@redhat.com; Sean Paul ; Maarten Lankhorst > > ; Maxime Ripard ; > > David Airlie > > Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction. > > > > On Tue, Feb 18, 2020 at 10:52:06AM -0500, Sean Paul wrote: > > > On Mon, Feb 17, 2020 at 07:08:37AM +, Lin, Wayne wrote: > > > > [AMD Public Use] > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Sean Paul > > > > > Sent: Saturday, February 15, 2020 12:09 AM > > > > > To: Lin, Wayne > > > > > Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul > > > > > ; Maarten Lankhorst > > > > > ; Maxime Ripard > > > > > ; David Airlie > > > > > Subject: Re: [PATCH 3/3] drm/dp_mst: Remove single tx msg restriction. > > > > > > > > > > On Fri, Feb 14, 2020 at 12:58 AM Lin, Wayne > > wrote: > > > > > > > > > > > > [AMD Public Use] > > > > > > > > > > > > Hi Paul, > > > > > > > > > > > > Thanks for the mail! > > > > > > > > > > > > I tried to solve this problem by having restriction on sending > > > > > > one msg at a > > > > > time due to hub/dock compatibility problems. > > > > > > From my experience, some branch devices don't handle well on > > > > > > interleaved replies (Dock from HP I think) > > > > > > > > > > Hi Wayne, > > > > > Hmm, that's interesting, do you have a part number of the failing > > > > > dock so I can test it? > > > > > > > > > Hi Paul, > > > > > > > > Sorry but it's been quite a while. I can't exactly tell the part number. > > > > If I remember correctly, when the specific branch device receives > > > > interleaved replies, it just doesn't reply to any requests. > > > > > > > > > > As the result of that, correct me if I'm wrong, I remember most > > > > > > gpu vendors > > > > > just send one down request at a time now in windows environment. > > > > > > I would suggest the original solution :) > > > > > > > > > > I can't really say what happens on the Windows side of the world, > > > > > but I suppose that makes sense if this is a widespread issue with > > > > > docks. I do worry about the performance hit. > > > > > > > > > > If indeed this is a problem, could we ratelimit per branch device > > > > > instead of globally? Even that would be better than serializing > > > > > everything. > > > > > > > > > Since the problem was because some branch devices can't > > > > simultaneously handle two replies, I'm afraid that we might still > > > > encounter > > the same problem? > > > > > > > > > > Hi Wayne, > > > Thanks for clarifying. I'm a bit hesitant to scrap this idea without > > > solid evidence that this is a common problem. Do you have any hubs > > > around AMD that you could try my patchset with? > Hi Paul, > Sure! I will see what I have at hand and try your patch set. It might take > me some time but I will update this as soon as possible. :) > Hi Wayne, I'm seeing spurious timeouts even with your serialization patch on mainline. Have you had a chance to test this set? At least on my machines it seems to be working better. Sean > Thanks! > > > > Oh, if you can test the set, you'll also need this patch as well :-) > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > > b/drivers/gpu/drm/drm_dp_mst_topology.c > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > > @@ -3814,7 +3814,9 @@ static bool drm_dp_get_one_sb_msg(struct > > drm_dp_mst_topology_mgr *mgr, bool up, > > int basereg = up ? DP_SIDEBAND_MSG_UP_REQ_BASE : > >DP_SIDEBAND_MSG_DOWN_REP_BASE; > > > > - *mstb = NULL; > > + if (mstb) > > + *mstb = NULL; > > + > > *seqno = -1; > > > > len = min(mgr->max_dpcd_transaction_bytes, 16); > > > > > > > Perhaps we could get some hard data? I'm happy to test things on my > > > end, but I probably shouldn't just start buying a bunch of random HP > > > docks in hopes one of them exhibits the issue :) > > > > > > To add anecdote to anecdote, everything on my desk seems to work with > > > interleaved replies. > > > > > > Since HDCP spec requires the host to verify each channel's encryption > > > every <2s, we're going to be increasing the amount of sideband traffic > > > a fair amount, so I would like to ensure we're doing everything > > > possible to maximize our sideband bandwidth. > > > > > > Sean > > > > > > > Thanks! > > > > > Sean > > > > > > > > > > > > > > > > > Thanks! > > > > > > > -Original Message- > > > > > > > From: Sean Paul > > > > > > > Sent: Friday, February 14, 2020 5:15 AM > > > > > > > To: dri-devel@lists.freedesktop.org > > > > > > > Cc: ly...@redhat.com; Lin, Wayne ; Sean > > > > > > > Paul ; Maarten Lankhorst > > > > > > > ; Maxime Ripard > > > > > > > ; David Airlie > > > >
[PATCH AUTOSEL 5.4 36/58] drm/amdgpu: fix memory leak during TDR test(v2)
From: Monk Liu [ Upstream commit 4829f89855f1d3a3d8014e74cceab51b421503db ] fix system memory leak v2: fix coding style Signed-off-by: Monk Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c index c5257ae3188a3..0922d9cd858a0 100644 --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c @@ -988,8 +988,12 @@ static int smu_v11_0_init_max_sustainable_clocks(struct smu_context *smu) struct smu_11_0_max_sustainable_clocks *max_sustainable_clocks; int ret = 0; - max_sustainable_clocks = kzalloc(sizeof(struct smu_11_0_max_sustainable_clocks), + if (!smu->smu_table.max_sustainable_clocks) + max_sustainable_clocks = kzalloc(sizeof(struct smu_11_0_max_sustainable_clocks), GFP_KERNEL); + else + max_sustainable_clocks = smu->smu_table.max_sustainable_clocks; + smu->smu_table.max_sustainable_clocks = (void *)max_sustainable_clocks; max_sustainable_clocks->uclock = smu->smu_table.boot_values.uclk / 100; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.5 41/67] drm/amdgpu: fix memory leak during TDR test(v2)
From: Monk Liu [ Upstream commit 4829f89855f1d3a3d8014e74cceab51b421503db ] fix system memory leak v2: fix coding style Signed-off-by: Monk Liu Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c index 8b13d18c6414c..e4149e6b68b39 100644 --- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c +++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c @@ -948,8 +948,12 @@ int smu_v11_0_init_max_sustainable_clocks(struct smu_context *smu) struct smu_11_0_max_sustainable_clocks *max_sustainable_clocks; int ret = 0; - max_sustainable_clocks = kzalloc(sizeof(struct smu_11_0_max_sustainable_clocks), + if (!smu->smu_table.max_sustainable_clocks) + max_sustainable_clocks = kzalloc(sizeof(struct smu_11_0_max_sustainable_clocks), GFP_KERNEL); + else + max_sustainable_clocks = smu->smu_table.max_sustainable_clocks; + smu->smu_table.max_sustainable_clocks = (void *)max_sustainable_clocks; max_sustainable_clocks->uclock = smu->smu_table.boot_values.uclk / 100; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/22] drm/vc4: Use simple encoder
On Thu, Mar 5, 2020 at 8:00 AM Thomas Zimmermann wrote: > > The vc4 driver uses empty implementations for its encoders. Replace > the code with the generic simple encoder. Acked-by: Eric Anholt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/dp_mst: Fix bandwidth checking regressions from DSC patches
Hi Lyude, On 3/4/20 11:36 PM, Lyude Paul wrote: AMD's patch series for adding DSC support to the MST helpers unfortunately introduced a few regressions into the kernel that I didn't get around to fixing until just now. I would have reverted the changes earlier, but seeing as that would have reverted all of amd's DSC support + everything that was done on top of that I really wanted to avoid doing that. Anyway, this should fix everything as far as I can tell. Note that I don't have any DSC displays locally yet, so if someone from AMD could sanity check this I would appreciate it ♥. Thank you for trying to fix this, unfortunately for me this is not fixed, with this series. My setup: 5.6-rc4 + your 3 patches (+ some unrelated patches outside of drm) -Lenovo x1 7th gen + Lenovo TB3 dock gen 2 + 2 external 1920x1080@60 monitors connected to the 2 HDMI interfaces on the dock -System booted with the LID closed, so that the firmware/BIOS has already initialized both monitors when the kernel boots This should be fairly easy to reproduce on a similar setup, other users are seeing similar problems when connecting more then 1 monitor to DP-MST docks, see e.g. : https://bugzilla.redhat.com/show_bug.cgi?id=1809681 https://bugzilla.redhat.com/show_bug.cgi?id=1810070 Let me know if you want me to collect some drm.debug logs, I guess if you do, you want me to use drm.debug=0x114 ? Regards, Hans Cc: Mikita Lipski Cc: Alex Deucher Cc: Sean Paul Cc: Hans de Goede Lyude Paul (3): drm/dp_mst: Rename drm_dp_mst_is_dp_mst_end_device() to be less redundant drm/dp_mst: Don't show connectors as connected before probing available PBN drm/dp_mst: Rewrite and fix bandwidth limit checks drivers/gpu/drm/drm_dp_mst_topology.c | 124 -- 1 file changed, 96 insertions(+), 28 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Wed, Mar 4, 2020 at 10:33 AM Mika Westerberg
wrote:
>
> Hi,
>
> On Tue, Mar 03, 2020 at 11:10:52AM +0100, Karol Herbst wrote:
> > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device
> > states.
>
> I think it is good to explain bit more here why this fix is needed.
>
is something like this fine?
Fixes the infamous 'runpm' bug many users are facing on Laptops with Nvidia
Pascal GPUs by skipping PCI power state changes on the GPU.
It's still unknown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
> > v2: convert to pci_dev quirk
> > put a proper technical explanation of the issue as a in-code comment
> > v3: disable it only for certain combinations of intel and nvidia hardware
> > v4: simplify quirk by setting flag on the GPU itself
> > v5: restructure quirk to make it easier to add new IDs
> > fix whitespace issues
> > fix potential NULL pointer access
> > update the quirk documentation
> > v6: move quirk into nouveau
>
> This information typically goes under the '---' line.
>
> > Signed-off-by: Karol Herbst
> > Cc: Bjorn Helgaas
> > Cc: Lyude Paul
> > Cc: Rafael J. Wysocki
> > Cc: Mika Westerberg
>
> I have few minor comments but regardless,
>
> Reviewed-by: Mika Westerberg
>
> > Cc: linux-...@vger.kernel.org
> > Cc: linux...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: nouv...@lists.freedesktop.org
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
> > ---
> > drivers/gpu/drm/nouveau/nouveau_drm.c | 56 +++
> > drivers/pci/pci.c | 8
> > include/linux/pci.h | 1 +
> > 3 files changed, 65 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index 2cd83849600f..51d3a7ba7731 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -618,6 +618,59 @@ nouveau_drm_device_fini(struct drm_device *dev)
> > kfree(drm);
> > }
> >
> > +/*
> > + * On some Intel PCIe bridge controllers doing a
> > + * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
> > + * Skipping the intermediate D3hot step seems to make it work again. Thise
> > is
> ^
> Thise -> This
>
> > + * probably caused by not meeting the expectation the involved AML code has
> > + * when the GPU is put into D3hot state before invoking it.
> > + *
> > + * This leads to various manifestations of this issue:
> > + * - AML code execution to power on the GPU hits an infinite loop (as the
> > + *code waits on device memory to change).
> > + * - kernel crashes, as all PCI reads return -1, which most code isn't
> > able
> > + *to handle well enough.
> > + *
> > + * In all cases dmesg will contain at least one line like this:
> > + * 'nouveau :01:00.0: Refused to change power state, currently in D3'
> > + * followed by a lot of nouveau timeouts.
> > + *
> > + * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the
> > not
> > + * documented PCI config space register 0x248 of the Intel PCIe bridge
> > + * controller (0x1901) in order to change the state of the PCIe link
> > between
> > + * the PCIe port and the GPU. There are alternative code paths using other
> > + * registers, which seem to work fine (executed pre Windows 8):
> > + * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
> > + * - 0xb0 bit 0x10 (link disable)
> > + * Changing the conditions inside the firmware by poking into the relevant
> > + * addresses does resolve the issue, but it seemed to be ACPI private
> > memory
> > + * and not any device accessible memory at all, so there is no portable
> > way of
> > + * changing the conditions.
> > + * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
> > + *
> > + * The only systems where this behavior can be seen are hybrid graphics
> > laptops
> > + * with a secondary Nvidia Maxwell, Pascal or Turing GPU. Its unclear
> > wheather
> ^^^
>
> Its -> It's
> wheather -> whether
>
> > + * this issue only occurs in combination with listed Intel PCIe bridge
> > + * controllers and the mentioned GPUs or other devices as well.
> > + *
> > + * documentation on the PCIe bridge controller can be found in the
> > + * "7th Generation Intel® Processor Families for H Platforms Datasheet
> > Volume 2"
> > + * Section "12 PCI Express* Controller (x16) Registers"
> > + */
> > +
> > +static void quirk_broken_nv_runpm(struct pci_dev *dev)
> > +{
> > + struct pci_dev *bridge = pci_upstream_bridge(dev);
> > +
> > + if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
> > + return;
> > +
>
[PATCH 09/22] drm/ingenic: Use simple encoder
The ingenic driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
b/drivers/gpu/drm/ingenic/ingenic-drm.c
index 9dfe7cb530e1..9f7983a97392 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#define JZ_REG_LCD_CFG 0x00
@@ -592,10 +593,6 @@ static const struct drm_mode_config_funcs
ingenic_drm_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
-static const struct drm_encoder_funcs ingenic_drm_encoder_funcs = {
- .destroy= drm_encoder_cleanup,
-};
-
static void ingenic_drm_free_dma_hwdesc(void *d)
{
struct ingenic_drm *priv = d;
@@ -730,8 +727,8 @@ static int ingenic_drm_probe(struct platform_device *pdev)
drm_encoder_helper_add(&priv->encoder,
&ingenic_drm_encoder_helper_funcs);
- ret = drm_encoder_init(drm, &priv->encoder, &ingenic_drm_encoder_funcs,
- DRM_MODE_ENCODER_DPI, NULL);
+ ret = drm_simple_encoder_init(drm, &priv->encoder,
+ DRM_MODE_ENCODER_DPI);
if (ret) {
dev_err(dev, "Failed to init encoder: %i", ret);
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/22] drm/tegra: Use simple encoder
The tegra driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tegra/drm.h| 2 --
drivers/gpu/drm/tegra/dsi.c| 10 +++---
drivers/gpu/drm/tegra/hdmi.c | 9 +++--
drivers/gpu/drm/tegra/output.c | 6 +-
drivers/gpu/drm/tegra/rgb.c| 8 ++--
drivers/gpu/drm/tegra/sor.c| 8 ++--
6 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index ed99b67deb29..804869799305 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -152,8 +152,6 @@ enum drm_connector_status
tegra_output_connector_detect(struct drm_connector *connector, bool force);
void tegra_output_connector_destroy(struct drm_connector *connector);
-void tegra_output_encoder_destroy(struct drm_encoder *encoder);
-
/* from dpaux.c */
struct drm_dp_aux *drm_dp_aux_find_by_of_node(struct device_node *np);
enum drm_connector_status drm_dp_aux_detect(struct drm_dp_aux *aux);
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 88b9d64c77bf..76369b128e5d 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "dc.h"
#include "drm.h"
@@ -824,10 +825,6 @@ static const struct drm_connector_helper_funcs
tegra_dsi_connector_helper_funcs
.mode_valid = tegra_dsi_connector_mode_valid,
};
-static const struct drm_encoder_funcs tegra_dsi_encoder_funcs = {
- .destroy = tegra_output_encoder_destroy,
-};
-
static void tegra_dsi_unprepare(struct tegra_dsi *dsi)
{
int err;
@@ -1058,9 +1055,8 @@ static int tegra_dsi_init(struct host1x_client *client)
&tegra_dsi_connector_helper_funcs);
dsi->output.connector.dpms = DRM_MODE_DPMS_OFF;
- drm_encoder_init(drm, &dsi->output.encoder,
-&tegra_dsi_encoder_funcs,
-DRM_MODE_ENCODER_DSI, NULL);
+ drm_simple_encoder_init(drm, &dsi->output.encoder,
+ DRM_MODE_ENCODER_DSI);
drm_encoder_helper_add(&dsi->output.encoder,
&tegra_dsi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index 6f117628f257..8ec72546f330 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "hda.h"
#include "hdmi.h"
@@ -1136,10 +1137,6 @@ tegra_hdmi_connector_helper_funcs = {
.mode_valid = tegra_hdmi_connector_mode_valid,
};
-static const struct drm_encoder_funcs tegra_hdmi_encoder_funcs = {
- .destroy = tegra_output_encoder_destroy,
-};
-
static void tegra_hdmi_encoder_disable(struct drm_encoder *encoder)
{
struct tegra_output *output = encoder_to_output(encoder);
@@ -1445,8 +1442,8 @@ static int tegra_hdmi_init(struct host1x_client *client)
&tegra_hdmi_connector_helper_funcs);
hdmi->output.connector.dpms = DRM_MODE_DPMS_OFF;
- drm_encoder_init(drm, &hdmi->output.encoder, &tegra_hdmi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm, &hdmi->output.encoder,
+ DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(&hdmi->output.encoder,
&tegra_hdmi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index a264259b97a2..e36e5e7c2f69 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include "drm.h"
#include "dc.h"
@@ -79,11 +80,6 @@ void tegra_output_connector_destroy(struct drm_connector
*connector)
drm_connector_cleanup(connector);
}
-void tegra_output_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
static irqreturn_t hpd_irq(int irq, void *data)
{
struct tegra_output *output = data;
diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 4be4dfd4a68a..0562a7eb793f 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include "drm.h"
#include "dc.h"
@@ -110,10 +111,6 @@ static const struct drm_connector_helper_funcs
tegra_rgb_connector_helper_funcs
.mode_valid = tegra_rgb_connector_mode_valid,
};
-static const struct drm_encoder_funcs tegra_rgb_encoder_funcs = {
- .destroy = tegra_output_encoder_destroy,
-};
-
static void tegra_rgb_encoder_disable(struct drm_encoder *encoder)
{
struct tegra_output *output = encoder_to_output(encoder);
@@ -281,8 +278,7 @@ int tegra_dc_rgb_init(struct drm_devi
[PATCH 00/22] drm: Convert drivers to drm_simple_encoder_init()
A call to drm_simple_encoder_init() initializes an encoder without further functionality. It only provides the destroy callback to cleanup the encoder's state. Only few drivers implement more sophisticated encoders than that. Most drivers implement such a simple encoder and can use drm_simple_encoder_init() instead. The patchset converts drivers where the encoder's instance is embedded in a larger data structure. The driver releases the memory during cleanup. Each patch replaces drm_encoder_init() with drm_simple_encoder_init() and removes the (now unused) driver's encoder functions. While the patchset is fairly large, the indiviual patches are self- contained and can be merged independently from each other. The simple-encoder functionality is currently in drm-misc-next, where these patches could go as well. Future directions: There's another common case where the driver calls kzalloc() plus drm_encoder_init(). Such drivers are not handled by this patchset. The plan here is to use a simple encoder with either managed memory allocation (once it's merged), or embed the encoder in a larger data structure and drop kzalloc() entirely. The patchset has been compile-tested on x86-64, aarch64 and arm. Thomas Zimmermann (22): drm/arc: Use simple encoder drm/atmel-hlcdc: Use simple encoder drm/exynos: Use simple encoder drm/fsl-dcu: Use simple encoder drm/gma500: Use simple encoder drm/hisilicon/kirin: Use simple encoder drm/i2c/tda998x: Use simple encoder drm/imx: Use simple encoder drm/ingenic: Use simple encoder drm/mediatek: Use simple encoder drm/rcar-du: Use simple encoder drm/rockchip: Use simple encoder drm/shmobile: Use simple encoder drm/sun4i: Use simple encoder drm/tegra: Use simple encoder drm/tidss: Use simple encoder drm/tilcdc: Use simple encoder drm/vc4: Use simple encoder drm/virtgpu: Use simple encoder drm/vkms: Use simple encoder drm/writeback: Use simple encoder drm/zte: Use simple encoder drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++--- drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++-- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 drivers/gpu/drm/drm_writeback.c| 10 +++--- drivers/gpu/drm/exynos/exynos_dp.c | 8 ++-- drivers/gpu/drm/exynos/exynos_drm_dpi.c| 8 ++-- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 8 ++-- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 ++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 +++--- drivers/gpu/drm/gma500/cdv_intel_crt.c | 14 +++--- drivers/gpu/drm/gma500/cdv_intel_dp.c | 16 +++- drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 4 ++-- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 17 +++-- drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 +++ drivers/gpu/drm/gma500/mdfld_output.h | 1 - drivers/gpu/drm/gma500/mdfld_tmd_vid.c | 6 -- drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 6 -- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 14 ++ drivers/gpu/drm/gma500/oaktrail_lvds.c | 5 +++-- drivers/gpu/drm/gma500/psb_intel_drv.h | 1 - drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++--- drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 5 - drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 8 ++-- drivers/gpu/drm/i2c/tda998x_drv.c | 14 +++--- drivers/gpu/drm/imx/dw_hdmi-imx.c | 8 ++-- drivers/gpu/drm/imx/imx-drm-core.c | 6 -- drivers/gpu/drm/imx/imx-drm.h | 1 - drivers/gpu/drm/imx/imx-ldb.c | 8 ++-- drivers/gpu/drm/imx/imx-tve.c | 8 ++-- drivers/gpu/drm/imx/parallel-display.c | 8 ++-- drivers/gpu/drm/ingenic/ingenic-drm.c | 9 +++-- drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++--- drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++--- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 14 +++--- .../gpu/drm/rockchip/analogix_dp-rockchip.c| 9 +++-- drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +++-- .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c| 8 ++-- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 8 ++-- drivers/gpu/drm/rockchip/inno_hdmi.c | 8 ++-- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++-- drivers/gpu/drm/rockchip/rockchip_lvds.c | 10 +++--- drivers/gpu/drm/rockchip/rockchip_rgb.c| 8 ++-- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 14 +++--- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 +++- drivers/gpu/drm/sun4i/sun4i_lvds.c | 12 +++- drivers/gpu/drm/sun4i/sun4i_rgb.c | 17 +++-- drivers/gpu/drm/sun4i/sun4i_tv.c
[PATCH 17/22] drm/tilcdc: Use simple encoder
The tilcdc driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 +++---
drivers/gpu/drm/tilcdc/tilcdc_panel.c| 8 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 28b7f703236e..b177525588c1 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "tilcdc_drv.h"
#include "tilcdc_external.h"
@@ -83,10 +84,6 @@ int tilcdc_add_component_encoder(struct drm_device *ddev)
return 0;
}
-static const struct drm_encoder_funcs tilcdc_external_encoder_funcs = {
- .destroy= drm_encoder_cleanup,
-};
-
static
int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge *bridge)
{
@@ -131,9 +128,8 @@ int tilcdc_attach_external_device(struct drm_device *ddev)
if (!priv->external_encoder)
return -ENOMEM;
- ret = drm_encoder_init(ddev, priv->external_encoder,
- &tilcdc_external_encoder_funcs,
- DRM_MODE_ENCODER_NONE, NULL);
+ ret = drm_simple_encoder_init(ddev, priv->external_encoder,
+ DRM_MODE_ENCODER_NONE);
if (ret) {
dev_err(ddev->dev, "drm_encoder_init() failed %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 5584e656b857..12823d60c4e8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "tilcdc_drv.h"
#include "tilcdc_panel.h"
@@ -74,10 +75,6 @@ static void panel_encoder_mode_set(struct drm_encoder
*encoder,
/* nothing needed */
}
-static const struct drm_encoder_funcs panel_encoder_funcs = {
- .destroy= drm_encoder_cleanup,
-};
-
static const struct drm_encoder_helper_funcs panel_encoder_helper_funcs = {
.dpms = panel_encoder_dpms,
.prepare= panel_encoder_prepare,
@@ -102,8 +99,7 @@ static struct drm_encoder *panel_encoder_create(struct
drm_device *dev,
encoder = &panel_encoder->base;
encoder->possible_crtcs = 1;
- ret = drm_encoder_init(dev, encoder, &panel_encoder_funcs,
- DRM_MODE_ENCODER_LVDS, NULL);
+ ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_LVDS);
if (ret < 0)
goto fail;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/22] drm/mediatek: Use simple encoder
The mediatak driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 14 +++---
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 14fbe1c09ce9..9c90c58e5acd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "mtk_dpi_regs.h"
#include "mtk_drm_ddp_comp.h"
@@ -509,15 +510,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
}
-static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
- .destroy = mtk_dpi_encoder_destroy,
-};
-
static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -596,8 +588,8 @@ static int mtk_dpi_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- ret = drm_encoder_init(drm_dev, &dpi->encoder, &mtk_dpi_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 0ede69830a9d..a9a25087112f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "mtk_drm_ddp_comp.h"
@@ -787,15 +788,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
}
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
- .destroy = mtk_dsi_encoder_destroy,
-};
-
static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -888,8 +880,8 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/22] drm/i2c/tda998x: Use simple encoder
The tda998x driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index c3332209f27a..0e1a90f70ec0 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1997,15 +1998,6 @@ static int tda998x_create(struct device *dev)
/* DRM encoder functions */
-static void tda998x_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs tda998x_encoder_funcs = {
- .destroy = tda998x_encoder_destroy,
-};
-
static int tda998x_encoder_init(struct device *dev, struct drm_device *drm)
{
struct tda998x_priv *priv = dev_get_drvdata(dev);
@@ -2023,8 +2015,8 @@ static int tda998x_encoder_init(struct device *dev,
struct drm_device *drm)
priv->encoder.possible_crtcs = crtcs;
- ret = drm_encoder_init(drm, &priv->encoder, &tda998x_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_simple_encoder_init(drm, &priv->encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret)
goto err_encoder;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/22] drm/sun4i: Use simple encoder
The ingenic driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 12 +++-
drivers/gpu/drm/sun4i/sun4i_lvds.c | 12 +++-
drivers/gpu/drm/sun4i/sun4i_rgb.c | 17 +++--
drivers/gpu/drm/sun4i/sun4i_tv.c | 17 +++--
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 12 +++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 8 ++--
6 files changed, 17 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 68d4644ac2dc..e324d7db7b7d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "sun4i_backend.h"
#include "sun4i_crtc.h"
@@ -204,10 +205,6 @@ static const struct drm_encoder_helper_funcs
sun4i_hdmi_helper_funcs = {
.mode_valid = sun4i_hdmi_mode_valid,
};
-static const struct drm_encoder_funcs sun4i_hdmi_funcs = {
- .destroy= drm_encoder_cleanup,
-};
-
static int sun4i_hdmi_get_modes(struct drm_connector *connector)
{
struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
@@ -611,11 +608,8 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
drm_encoder_helper_add(&hdmi->encoder,
&sun4i_hdmi_helper_funcs);
- ret = drm_encoder_init(drm,
- &hdmi->encoder,
- &sun4i_hdmi_funcs,
- DRM_MODE_ENCODER_TMDS,
- NULL);
+ ret = drm_simple_encoder_init(drm, &hdmi->encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
dev_err(dev, "Couldn't initialise the HDMI encoder\n");
goto err_put_ddc_i2c;
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index 26e5c7ceb8ff..ffda3184aa12 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "sun4i_crtc.h"
#include "sun4i_tcon.h"
@@ -96,10 +97,6 @@ static const struct drm_encoder_helper_funcs
sun4i_lvds_enc_helper_funcs = {
.enable = sun4i_lvds_encoder_enable,
};
-static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
- .destroy= drm_encoder_cleanup,
-};
-
int sun4i_lvds_init(struct drm_device *drm, struct sun4i_tcon *tcon)
{
struct drm_encoder *encoder;
@@ -121,11 +118,8 @@ int sun4i_lvds_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
drm_encoder_helper_add(&lvds->encoder,
&sun4i_lvds_enc_helper_funcs);
- ret = drm_encoder_init(drm,
- &lvds->encoder,
- &sun4i_lvds_enc_funcs,
- DRM_MODE_ENCODER_LVDS,
- NULL);
+ ret = drm_simple_encoder_init(drm, &lvds->encoder,
+ DRM_MODE_ENCODER_LVDS);
if (ret) {
dev_err(drm->dev, "Couldn't initialise the lvds encoder\n");
goto err_out;
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 3b23d5be3cf3..5a7d43939ae6 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "sun4i_crtc.h"
#include "sun4i_tcon.h"
@@ -188,15 +189,6 @@ static struct drm_encoder_helper_funcs
sun4i_rgb_enc_helper_funcs = {
.mode_valid = sun4i_rgb_mode_valid,
};
-static void sun4i_rgb_enc_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static struct drm_encoder_funcs sun4i_rgb_enc_funcs = {
- .destroy= sun4i_rgb_enc_destroy,
-};
-
int sun4i_rgb_init(struct drm_device *drm, struct sun4i_tcon *tcon)
{
struct drm_encoder *encoder;
@@ -218,11 +210,8 @@ int sun4i_rgb_init(struct drm_device *drm, struct
sun4i_tcon *tcon)
drm_encoder_helper_add(&rgb->encoder,
&sun4i_rgb_enc_helper_funcs);
- ret = drm_encoder_init(drm,
- &rgb->encoder,
- &sun4i_rgb_enc_funcs,
- DRM_MODE_ENCODER_NONE,
- NULL);
+ ret = drm_simple_encoder_init(drm, &rgb->encoder,
+ DRM_MODE_ENCODER_NONE);
if (ret) {
dev_err(drm->dev, "Couldn't initialise the rgb encoder\n");
goto err_out;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 39c15282e448..63f4428ac3bf 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/dri
[PATCH 08/22] drm/imx: Use simple encoder
The imx driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 8 ++--
drivers/gpu/drm/imx/imx-drm-core.c | 6 --
drivers/gpu/drm/imx/imx-drm.h | 1 -
drivers/gpu/drm/imx/imx-ldb.c | 8 ++--
drivers/gpu/drm/imx/imx-tve.c | 8 ++--
drivers/gpu/drm/imx/parallel-display.c | 8 ++--
6 files changed, 8 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index f22cfbf9353e..ba4ca17fd4d8 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "imx-drm.h"
@@ -143,10 +144,6 @@ static const struct drm_encoder_helper_funcs
dw_hdmi_imx_encoder_helper_funcs =
.atomic_check = dw_hdmi_imx_atomic_check,
};
-static const struct drm_encoder_funcs dw_hdmi_imx_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static enum drm_mode_status
imx6q_hdmi_mode_valid(struct drm_connector *con,
const struct drm_display_mode *mode)
@@ -236,8 +233,7 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
return ret;
drm_encoder_helper_add(encoder, &dw_hdmi_imx_encoder_helper_funcs);
- drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
platform_set_drvdata(pdev, hdmi);
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index da87c70e413b..9979547ca883 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -42,12 +42,6 @@ void imx_drm_connector_destroy(struct drm_connector
*connector)
}
EXPORT_SYMBOL_GPL(imx_drm_connector_destroy);
-void imx_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-EXPORT_SYMBOL_GPL(imx_drm_encoder_destroy);
-
static int imx_drm_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
{
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index ab9c6f706eb3..c3e1a3f14d30 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -38,7 +38,6 @@ int imx_drm_encoder_parse_of(struct drm_device *drm,
struct drm_encoder *encoder, struct device_node *np);
void imx_drm_connector_destroy(struct drm_connector *connector);
-void imx_drm_encoder_destroy(struct drm_encoder *encoder);
int ipu_planes_assign_pre(struct drm_device *dev,
struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 4da22a94790c..66ea68e8da87 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "imx-drm.h"
@@ -393,10 +394,6 @@ static const struct drm_connector_helper_funcs
imx_ldb_connector_helper_funcs =
.best_encoder = imx_ldb_connector_best_encoder,
};
-static const struct drm_encoder_funcs imx_ldb_encoder_funcs = {
- .destroy = imx_drm_encoder_destroy,
-};
-
static const struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
.atomic_mode_set = imx_ldb_encoder_atomic_mode_set,
.enable = imx_ldb_encoder_enable,
@@ -441,8 +438,7 @@ static int imx_ldb_register(struct drm_device *drm,
}
drm_encoder_helper_add(encoder, &imx_ldb_encoder_helper_funcs);
- drm_encoder_init(drm, encoder, &imx_ldb_encoder_funcs,
-DRM_MODE_ENCODER_LVDS, NULL);
+ drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_LVDS);
if (imx_ldb_ch->bridge) {
ret = drm_bridge_attach(&imx_ldb_ch->encoder,
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 5bbfaa2cd0f4..ee63782c77e9 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "imx-drm.h"
@@ -348,10 +349,6 @@ static const struct drm_connector_helper_funcs
imx_tve_connector_helper_funcs =
.mode_valid = imx_tve_connector_mode_valid,
};
-static const struct drm_encoder_funcs imx_tve_encoder_funcs = {
- .destroy = imx_drm_encoder_destroy,
-};
-
static const struct drm_encoder_helper_funcs imx_tve_encoder_helper_funcs = {
.mode_set = imx_tve_encoder_mode_set,
.enable = imx_tve_encoder_enable,
@@ -479,8 +476,7 @@ static int imx_tve_register(struct drm_device *drm, struct
imx_tve *tve)
return ret;
drm_encoder_helper_add(&tve->encoder, &imx_tve_encoder_helper_funcs);
- drm_encoder_init(drm, &tve->encoder, &imx_tve_encoder_funcs,
-
[PATCH 01/22] drm/arc: Use simple encoder
The arc driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/arc/arcpgu_hdmi.c | 10 +++---
drivers/gpu/drm/arc/arcpgu_sim.c | 8 ++--
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index 52839934f2fb..780911765e2e 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -7,15 +7,12 @@
#include
#include
-#include
#include
+#include
+#include
#include "arcpgu.h"
-static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np)
{
struct drm_encoder *encoder;
@@ -34,8 +31,7 @@ int arcpgu_drm_hdmi_init(struct drm_device *drm, struct
device_node *np)
encoder->possible_crtcs = 1;
encoder->possible_clones = 0;
- ret = drm_encoder_init(drm, encoder, &arcpgu_drm_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 37d961668dfe..66ca2c26e339 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "arcpgu.h"
@@ -50,10 +51,6 @@ static const struct drm_connector_funcs
arcpgu_drm_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static struct drm_encoder_funcs arcpgu_drm_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np)
{
struct arcpgu_drm_connector *arcpgu_connector;
@@ -68,8 +65,7 @@ int arcpgu_drm_sim_init(struct drm_device *drm, struct
device_node *np)
encoder->possible_crtcs = 1;
encoder->possible_clones = 0;
- ret = drm_encoder_init(drm, encoder, &arcpgu_drm_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
+ ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_VIRTUAL);
if (ret)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/22] drm/vkms: Use simple encoder
The vkms driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vkms/vkms_output.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index fb1941a6522c..85afb77e97f0 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -3,6 +3,7 @@
#include "vkms_drv.h"
#include
#include
+#include
static void vkms_connector_destroy(struct drm_connector *connector)
{
@@ -17,10 +18,6 @@ static const struct drm_connector_funcs vkms_connector_funcs
= {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static const struct drm_encoder_funcs vkms_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int vkms_conn_get_modes(struct drm_connector *connector)
{
int count;
@@ -70,8 +67,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
drm_connector_helper_add(connector, &vkms_conn_helper_funcs);
- ret = drm_encoder_init(dev, encoder, &vkms_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
+ ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
if (ret) {
DRM_ERROR("Failed to init encoder\n");
goto err_encoder;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 16/22] drm/tidss: Use simple encoder
The tidss driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tidss/tidss_encoder.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c
b/drivers/gpu/drm/tidss/tidss_encoder.c
index 83785b0a66a9..4c0558286f5e 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -8,8 +8,9 @@
#include
#include
-#include
#include
+#include
+#include
#include "tidss_crtc.h"
#include "tidss_drv.h"
@@ -59,10 +60,6 @@ static const struct drm_encoder_helper_funcs
encoder_helper_funcs = {
.atomic_check = tidss_encoder_atomic_check,
};
-static const struct drm_encoder_funcs encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
struct drm_encoder *tidss_encoder_create(struct tidss_device *tidss,
u32 encoder_type, u32 possible_crtcs)
{
@@ -75,8 +72,7 @@ struct drm_encoder *tidss_encoder_create(struct tidss_device
*tidss,
enc->possible_crtcs = possible_crtcs;
- ret = drm_encoder_init(&tidss->ddev, enc, &encoder_funcs,
- encoder_type, NULL);
+ ret = drm_simple_encoder_init(&tidss->ddev, enc, encoder_type);
if (ret < 0)
return ERR_PTR(ret);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/22] drm/virtgpu: Use simple encoder
The virtgpu driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/virtio/virtgpu_display.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 2b7e6ae65546..cc7fd957a307 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "virtgpu_drv.h"
@@ -240,10 +241,6 @@ static const struct drm_connector_funcs
virtio_gpu_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static const struct drm_encoder_funcs virtio_gpu_enc_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int vgdev_output_init(struct virtio_gpu_device *vgdev, int index)
{
struct drm_device *dev = vgdev->ddev;
@@ -276,8 +273,7 @@ static int vgdev_output_init(struct virtio_gpu_device
*vgdev, int index)
if (vgdev->has_edid)
drm_connector_attach_edid_property(connector);
- drm_encoder_init(dev, encoder, &virtio_gpu_enc_funcs,
-DRM_MODE_ENCODER_VIRTUAL, NULL);
+ drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
drm_encoder_helper_add(encoder, &virtio_gpu_enc_helper_funcs);
encoder->possible_crtcs = 1 << index;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/22] drm/rcar-du: Use simple encoder
The rcar-du driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index c07c6a88aff0..b0335da0c161 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
@@ -23,13 +24,6 @@
* Encoder
*/
-static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
-};
-
-static const struct drm_encoder_funcs encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static unsigned int rcar_du_encoder_count_ports(struct device_node *node)
{
struct device_node *ports;
@@ -110,13 +104,11 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
}
}
- ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
- DRM_MODE_ENCODER_NONE, NULL);
+ ret = drm_simple_encoder_init(rcdu->ddev, encoder,
+ DRM_MODE_ENCODER_NONE);
if (ret < 0)
goto done;
- drm_encoder_helper_add(encoder, &encoder_helper_funcs);
-
/*
* Attach the bridge to the encoder. The bridge will create the
* connector.
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 22/22] drm/zte: Use simple encoder
The zte driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/zte/zx_hdmi.c | 8 ++--
drivers/gpu/drm/zte/zx_tvenc.c | 8 ++--
drivers/gpu/drm/zte/zx_vga.c | 8 ++--
3 files changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index b98a1420dcd3..76a16d997a23 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -254,10 +255,6 @@ static const struct drm_encoder_helper_funcs
zx_hdmi_encoder_helper_funcs = {
.mode_set = zx_hdmi_encoder_mode_set,
};
-static const struct drm_encoder_funcs zx_hdmi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int zx_hdmi_connector_get_modes(struct drm_connector *connector)
{
struct zx_hdmi *hdmi = to_zx_hdmi(connector);
@@ -313,8 +310,7 @@ static int zx_hdmi_register(struct drm_device *drm, struct
zx_hdmi *hdmi)
encoder->possible_crtcs = VOU_CRTC_MASK;
- drm_encoder_init(drm, encoder, &zx_hdmi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &zx_hdmi_encoder_helper_funcs);
hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD;
diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c
index c598b7daf1f1..d8a89ba383bc 100644
--- a/drivers/gpu/drm/zte/zx_tvenc.c
+++ b/drivers/gpu/drm/zte/zx_tvenc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "zx_drm_drv.h"
#include "zx_tvenc_regs.h"
@@ -218,10 +219,6 @@ static const struct drm_encoder_helper_funcs
zx_tvenc_encoder_helper_funcs = {
.mode_set = zx_tvenc_encoder_mode_set,
};
-static const struct drm_encoder_funcs zx_tvenc_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int zx_tvenc_connector_get_modes(struct drm_connector *connector)
{
struct zx_tvenc *tvenc = to_zx_tvenc(connector);
@@ -285,8 +282,7 @@ static int zx_tvenc_register(struct drm_device *drm, struct
zx_tvenc *tvenc)
*/
encoder->possible_crtcs = BIT(1);
- drm_encoder_init(drm, encoder, &zx_tvenc_encoder_funcs,
-DRM_MODE_ENCODER_TVDAC, NULL);
+ drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TVDAC);
drm_encoder_helper_add(encoder, &zx_tvenc_encoder_helper_funcs);
connector->interlace_allowed = true;
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index c4fa3bbaba78..a7ed7f5ca837 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "zx_drm_drv.h"
#include "zx_vga_regs.h"
@@ -72,10 +73,6 @@ static const struct drm_encoder_helper_funcs
zx_vga_encoder_helper_funcs = {
.disable = zx_vga_encoder_disable,
};
-static const struct drm_encoder_funcs zx_vga_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int zx_vga_connector_get_modes(struct drm_connector *connector)
{
struct zx_vga *vga = to_zx_vga(connector);
@@ -154,8 +151,7 @@ static int zx_vga_register(struct drm_device *drm, struct
zx_vga *vga)
encoder->possible_crtcs = VOU_CRTC_MASK;
- ret = drm_encoder_init(drm, encoder, &zx_vga_encoder_funcs,
- DRM_MODE_ENCODER_DAC, NULL);
+ ret = drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_DAC);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init encoder: %d\n", ret);
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/22] drm/exynos: Use simple encoder
The exynos driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/exynos/exynos_dp.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8 ++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 8 ++--
5 files changed, 10 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index d23d3502ca91..a61482af2998 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include "exynos_drm_crtc.h"
@@ -135,10 +136,6 @@ static const struct drm_encoder_helper_funcs
exynos_dp_encoder_helper_funcs = {
.disable = exynos_dp_nop,
};
-static const struct drm_encoder_funcs exynos_dp_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
{
int ret;
@@ -174,8 +171,7 @@ static int exynos_dp_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- drm_encoder_init(drm_dev, encoder, &exynos_dp_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &exynos_dp_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 43fa0f26c052..7ba5354e7d94 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -149,10 +150,6 @@ static const struct drm_encoder_helper_funcs
exynos_dpi_encoder_helper_funcs = {
.disable = exynos_dpi_disable,
};
-static const struct drm_encoder_funcs exynos_dpi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
enum {
FIMD_PORT_IN0,
FIMD_PORT_IN1,
@@ -201,8 +198,7 @@ int exynos_dpi_bind(struct drm_device *dev, struct
drm_encoder *encoder)
{
int ret;
- drm_encoder_init(dev, encoder, &exynos_dpi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &exynos_dpi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 669d3857502a..2986c93382e0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
@@ -1524,10 +1525,6 @@ static const struct drm_encoder_helper_funcs
exynos_dsi_encoder_helper_funcs = {
.disable = exynos_dsi_disable,
};
-static const struct drm_encoder_funcs exynos_dsi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
@@ -1705,8 +1702,7 @@ static int exynos_dsi_bind(struct device *dev, struct
device *master,
struct drm_bridge *in_bridge;
int ret;
- drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &exynos_dsi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index b320b3a21ad4..282467121699 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -369,10 +370,6 @@ static const struct drm_encoder_helper_funcs
exynos_vidi_encoder_helper_funcs =
.disable = exynos_vidi_disable,
};
-static const struct drm_encoder_funcs exynos_vidi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int vidi_bind(struct device *dev, struct device *master, void *data)
{
struct vidi_context *ctx = dev_get_drvdata(dev);
@@ -406,8 +403,7 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
return PTR_ERR(ctx->crtc);
}
- drm_encoder_init(drm_dev, encoder, &exynos_vidi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, &exynos_vidi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 3e5f1a77286d..302ffda5
[PATCH 21/22] drm/writeback: Use simple encoder
The writeback code uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_writeback.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 43d9e3bb3a94..cefb500c4ed7 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
/**
@@ -146,10 +147,6 @@ static int create_writeback_properties(struct drm_device
*dev)
return 0;
}
-static const struct drm_encoder_funcs drm_writeback_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
/**
* drm_writeback_connector_init - Initialize a writeback connector and its
properties
* @dev: DRM device
@@ -191,9 +188,8 @@ int drm_writeback_connector_init(struct drm_device *dev,
return PTR_ERR(blob);
drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, &wb_connector->encoder,
- &drm_writeback_encoder_funcs,
- DRM_MODE_ENCODER_VIRTUAL, NULL);
+ ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
+ DRM_MODE_ENCODER_VIRTUAL);
if (ret)
goto fail;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/22] drm/fsl-dcu: Use simple encoder
The fsl-dcu driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index cff344367f81..9b0c4736c21a 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -13,19 +13,11 @@
#include
#include
#include
+#include
#include "fsl_dcu_drm_drv.h"
#include "fsl_tcon.h"
-static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs encoder_funcs = {
- .destroy = fsl_dcu_drm_encoder_destroy,
-};
-
int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device *fsl_dev,
struct drm_crtc *crtc)
{
@@ -38,8 +30,8 @@ int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device
*fsl_dev,
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
- ret = drm_encoder_init(fsl_dev->drm, encoder, &encoder_funcs,
- DRM_MODE_ENCODER_LVDS, NULL);
+ ret = drm_simple_encoder_init(fsl_dev->drm, encoder,
+ DRM_MODE_ENCODER_LVDS);
if (ret < 0)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/22] drm/vc4: Use simple encoder
The vc4 driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_dpi.c | 8 ++--
drivers/gpu/drm/vc4/vc4_dsi.c | 15 +++
drivers/gpu/drm/vc4/vc4_hdmi.c | 17 -
drivers/gpu/drm/vc4/vc4_vec.c | 8 ++--
4 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index 6dfede03396e..a90f2545baee 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -114,10 +115,6 @@ static const struct debugfs_reg32 dpi_regs[] = {
VC4_REG32(DPI_ID),
};
-static const struct drm_encoder_funcs vc4_dpi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static void vc4_dpi_encoder_disable(struct drm_encoder *encoder)
{
struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
@@ -309,8 +306,7 @@ static int vc4_dpi_bind(struct device *dev, struct device
*master, void *data)
if (ret)
DRM_ERROR("Failed to turn on core clock: %d\n", ret);
- drm_encoder_init(drm, dpi->encoder, &vc4_dpi_encoder_funcs,
-DRM_MODE_ENCODER_DPI, NULL);
+ drm_simple_encoder_init(drm, dpi->encoder, DRM_MODE_ENCODER_DPI);
drm_encoder_helper_add(dpi->encoder, &vc4_dpi_encoder_helper_funcs);
ret = vc4_dpi_init_bridge(dpi);
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index d99b1d526651..eaf276978ee7 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "vc4_drv.h"
#include "vc4_regs.h"
@@ -652,15 +653,6 @@ static const struct debugfs_reg32 dsi1_regs[] = {
VC4_REG32(DSI1_ID),
};
-static void vc4_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs vc4_dsi_encoder_funcs = {
- .destroy = vc4_dsi_encoder_destroy,
-};
-
static void vc4_dsi_latch_ulps(struct vc4_dsi *dsi, bool latch)
{
u32 afec0 = DSI_PORT_READ(PHY_AFEC0);
@@ -1615,8 +1607,7 @@ static int vc4_dsi_bind(struct device *dev, struct device
*master, void *data)
if (dsi->port == 1)
vc4->dsi1 = dsi;
- drm_encoder_init(drm, dsi->encoder, &vc4_dsi_encoder_funcs,
-DRM_MODE_ENCODER_DSI, NULL);
+ drm_simple_encoder_init(drm, dsi->encoder, DRM_MODE_ENCODER_DSI);
drm_encoder_helper_add(dsi->encoder, &vc4_dsi_encoder_helper_funcs);
ret = drm_bridge_attach(dsi->encoder, dsi->bridge, NULL, 0);
@@ -1656,7 +1647,7 @@ static void vc4_dsi_unbind(struct device *dev, struct
device *master,
* normally.
*/
list_splice_init(&dsi->bridge_chain, &dsi->encoder->bridge_chain);
- vc4_dsi_encoder_destroy(dsi->encoder);
+ drm_encoder_cleanup(dsi->encoder);
if (dsi->port == 1)
vc4->dsi1 = NULL;
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index cea18dc15f77..8f956156eb8e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -306,15 +307,6 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
return connector;
}
-static void vc4_hdmi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs vc4_hdmi_encoder_funcs = {
- .destroy = vc4_hdmi_encoder_destroy,
-};
-
static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
enum hdmi_infoframe_type type)
{
@@ -1394,8 +1386,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
}
pm_runtime_enable(dev);
- drm_encoder_init(drm, hdmi->encoder, &vc4_hdmi_encoder_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(drm, hdmi->encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(hdmi->encoder, &vc4_hdmi_encoder_helper_funcs);
hdmi->connector =
@@ -1453,7 +1444,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
vc4_hdmi_connector_destroy(hdmi->connector);
#endif
err_destroy_encoder:
- vc4_hdmi_encoder_destroy(hdmi->encoder);
+ drm_encoder_cleanup(hdmi->encoder);
err_unprepare_hsm:
clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
@@ -1472,7 +1463,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
cec_unregister_adapter(hdmi->cec_adap);
vc4_hdmi_connector_destroy(hdmi->connector);
- vc4_hdmi_encoder_destroy(hdmi->en
[PATCH 12/22] drm/rockchip: Use simple encoder
The rockchip driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +++--
drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +++--
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 8 ++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 8 ++--
drivers/gpu/drm/rockchip/inno_hdmi.c| 8 ++--
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 8 ++--
drivers/gpu/drm/rockchip/rockchip_lvds.c| 10 +++---
drivers/gpu/drm/rockchip/rockchip_rgb.c | 8 ++--
8 files changed, 19 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index f38f5e113c6b..848522797314 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
@@ -258,10 +259,6 @@ static struct drm_encoder_helper_funcs
rockchip_dp_encoder_helper_funcs = {
.atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
-static struct drm_encoder_funcs rockchip_dp_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int rockchip_dp_of_probe(struct rockchip_dp_device *dp)
{
struct device *dev = dp->dev;
@@ -309,8 +306,8 @@ static int rockchip_dp_drm_create_encoder(struct
rockchip_dp_device *dp)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_encoder_init(drm_dev, encoder, &rockchip_dp_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_simple_encoder_init(drm_dev, encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index eed594bd38d3..06f85138b51b 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "cdn-dp-core.h"
#include "cdn-dp-reg.h"
@@ -689,10 +690,6 @@ static const struct drm_encoder_helper_funcs
cdn_dp_encoder_helper_funcs = {
.atomic_check = cdn_dp_encoder_atomic_check,
};
-static const struct drm_encoder_funcs cdn_dp_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int cdn_dp_parse_dt(struct cdn_dp_device *dp)
{
struct device *dev = dp->dev;
@@ -1030,8 +1027,8 @@ static int cdn_dp_bind(struct device *dev, struct device
*master, void *data)
dev->of_node);
DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
- ret = drm_encoder_init(drm_dev, encoder, &cdn_dp_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_simple_encoder_init(drm_dev, encoder,
+ DRM_MODE_ENCODER_TMDS);
if (ret) {
DRM_ERROR("failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index 6e1270e45f97..3feff0c45b3f 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "rockchip_drm_drv.h"
#include "rockchip_drm_vop.h"
@@ -789,10 +790,6 @@ dw_mipi_dsi_encoder_helper_funcs = {
.disable = dw_mipi_dsi_encoder_disable,
};
-static const struct drm_encoder_funcs dw_mipi_dsi_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int rockchip_dsi_drm_create_encoder(struct dw_mipi_dsi_rockchip *dsi,
struct drm_device *drm_dev)
{
@@ -802,8 +799,7 @@ static int rockchip_dsi_drm_create_encoder(struct
dw_mipi_dsi_rockchip *dsi,
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dsi->dev->of_node);
- ret = drm_encoder_init(drm_dev, encoder, &dw_mipi_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to initialize encoder with drm\n");
return ret;
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7f56d8c3491d..121aa8a63a76 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/
[PATCH 13/22] drm/shmobile: Use simple encoder
The shmobile driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 75a752d59ef1..03556dbfcafb 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "shmob_drm_backlight.h"
@@ -558,15 +559,6 @@ static const struct drm_encoder_helper_funcs
encoder_helper_funcs = {
.mode_set = shmob_drm_encoder_mode_set,
};
-static void shmob_drm_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs encoder_funcs = {
- .destroy = shmob_drm_encoder_destroy,
-};
-
int shmob_drm_encoder_create(struct shmob_drm_device *sdev)
{
struct drm_encoder *encoder = &sdev->encoder.encoder;
@@ -576,8 +568,8 @@ int shmob_drm_encoder_create(struct shmob_drm_device *sdev)
encoder->possible_crtcs = 1;
- ret = drm_encoder_init(sdev->ddev, encoder, &encoder_funcs,
- DRM_MODE_ENCODER_LVDS, NULL);
+ ret = drm_simple_encoder_init(sdev->ddev, encoder,
+ DRM_MODE_ENCODER_LVDS);
if (ret < 0)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/22] drm/hisilicon/kirin: Use simple encoder
The kirin driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index f31068d74b18..08c1ab542c03 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "dw_dsi_reg.h"
@@ -696,10 +697,6 @@ static const struct drm_encoder_helper_funcs
dw_encoder_helper_funcs = {
.disable= dsi_encoder_disable
};
-static const struct drm_encoder_funcs dw_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static int dw_drm_encoder_init(struct device *dev,
struct drm_device *drm_dev,
struct drm_encoder *encoder)
@@ -713,8 +710,7 @@ static int dw_drm_encoder_init(struct device *dev,
}
encoder->possible_crtcs = crtc_mask;
- ret = drm_encoder_init(drm_dev, encoder, &dw_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("failed to init dsi encoder\n");
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/22] drm/gma500: Use simple encoder
The gma500 driver uses empty implementations for some of its encoders.
Replace the code with the generic simple encoder. As a side effect, the
patch also removes an indirection in the encoder setup for Medfield.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_intel_crt.c | 14 +++---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 16 +++-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 4 ++--
drivers/gpu/drm/gma500/cdv_intel_lvds.c| 17 +++--
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 +++
drivers/gpu/drm/gma500/mdfld_output.h | 1 -
drivers/gpu/drm/gma500/mdfld_tmd_vid.c | 6 --
drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 6 --
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 14 ++
drivers/gpu/drm/gma500/oaktrail_lvds.c | 5 +++--
drivers/gpu/drm/gma500/psb_intel_drv.h | 1 -
drivers/gpu/drm/gma500/psb_intel_lvds.c| 18 +++---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 5 -
13 files changed, 22 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 29c36d63b20e..88535f5aacc5 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -28,6 +28,8 @@
#include
#include
+#include
+
#include "cdv_device.h"
#include "intel_bios.h"
#include "power.h"
@@ -237,15 +239,6 @@ static const struct drm_connector_helper_funcs
.best_encoder = gma_best_encoder,
};
-static void cdv_intel_crt_enc_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs cdv_intel_crt_enc_funcs = {
- .destroy = cdv_intel_crt_enc_destroy,
-};
-
void cdv_intel_crt_init(struct drm_device *dev,
struct psb_intel_mode_device *mode_dev)
{
@@ -271,8 +264,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
&cdv_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
encoder = &gma_encoder->base;
- drm_encoder_init(dev, encoder,
- &cdv_intel_crt_enc_funcs, DRM_MODE_ENCODER_DAC, NULL);
+ drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_DAC);
gma_connector_attach_encoder(gma_connector, gma_encoder);
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 5772b2dce0d6..13947ec06dbb 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "gma_display.h"
#include "psb_drv.h"
@@ -1908,11 +1909,6 @@ cdv_intel_dp_destroy(struct drm_connector *connector)
kfree(connector);
}
-static void cdv_intel_dp_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
static const struct drm_encoder_helper_funcs cdv_intel_dp_helper_funcs = {
.dpms = cdv_intel_dp_dpms,
.mode_fixup = cdv_intel_dp_mode_fixup,
@@ -1935,11 +1931,6 @@ static const struct drm_connector_helper_funcs
cdv_intel_dp_connector_helper_fun
.best_encoder = gma_best_encoder,
};
-static const struct drm_encoder_funcs cdv_intel_dp_enc_funcs = {
- .destroy = cdv_intel_dp_encoder_destroy,
-};
-
-
static void cdv_intel_dp_add_properties(struct drm_connector *connector)
{
cdv_intel_attach_force_audio_property(connector);
@@ -2016,8 +2007,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev
encoder = &gma_encoder->base;
drm_connector_init(dev, connector, &cdv_intel_dp_connector_funcs, type);
- drm_encoder_init(dev, encoder, &cdv_intel_dp_enc_funcs,
-DRM_MODE_ENCODER_TMDS, NULL);
+ drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
gma_connector_attach_encoder(gma_connector, gma_encoder);
@@ -2120,7 +2110,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
psb_intel_mode_device *mode_dev
if (ret == 0) {
/* if this fails, presume the device is a ghost */
DRM_INFO("failed to retrieve link info, disabling
eDP\n");
- cdv_intel_dp_encoder_destroy(encoder);
+ drm_encoder_cleanup(encoder);
cdv_intel_dp_destroy(connector);
goto err_priv;
} else {
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 1711a41acc16..0d12c6ffbc40 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "cdv_device.h"
#include "psb_drv.h"
@@ -311,8 +312,7 @@ void cdv_hdmi_init(struct drm_device *dev,
&cdv_hdmi_connector_funcs,
DRM_MODE_CONNECTOR_DVID);
- drm_encoder_init(dev, en
[PATCH 02/22] drm/atmel-hlcdc: Use simple encoder
The atmel-hlcdc driver uses an empty implementation for its encoder.
Replace the code with the generic simple encoder.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index e2019fe97fff..43bc709e3523 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -11,9 +11,10 @@
#include
#include
+#include
#include
#include
-#include
+#include
#include "atmel_hlcdc_dc.h"
@@ -22,10 +23,6 @@ struct atmel_hlcdc_rgb_output {
int bus_fmt;
};
-static const struct drm_encoder_funcs atmel_hlcdc_panel_encoder_funcs = {
- .destroy = drm_encoder_cleanup,
-};
-
static struct atmel_hlcdc_rgb_output *
atmel_hlcdc_encoder_to_rgb_output(struct drm_encoder *encoder)
{
@@ -98,9 +95,8 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev, int endpoint)
return -EINVAL;
}
- ret = drm_encoder_init(dev, &output->encoder,
- &atmel_hlcdc_panel_encoder_funcs,
- DRM_MODE_ENCODER_NONE, NULL);
+ ret = drm_simple_encoder_init(dev, &output->encoder,
+ DRM_MODE_ENCODER_NONE);
if (ret)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files
On Thu, Mar 5, 2020 at 7:06 AM Christian König wrote:
>
> Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
> > On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand wrote:
> >> On Wed, Mar 4, 2020 at 2:34 AM Christian König
> >> wrote:
> >>> Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
> On Thu, Feb 27, 2020 at 2:28 AM Christian König
> wrote:
> [SNIP]
> >>> For reference see what dance is necessary in the dma_fence_chain_release
> >>> function to avoid that:
> /* Manually unlink the chain as much as possible to avoid
> recursion
> * and potential stack overflow.
> */
> while ((prev = rcu_dereference_protected(chain->prev, true))) {
> >>>
> >>>
> >>> It took me quite a while to figure out how to do this without causing
> >>> issues. But I don't see how this would be possible for dma_fence_array.
> >> Ah, I see the issue now! It hadn't even occurred to me that userspace
> >> could use this to build up an infinite recursion chain. That's nasty!
>
> Yeah, when I first stumbled over it it was like why the heck is my code
> crashing in an interrupt handler?
>
> Realizing that this is stack corruption because of the long chain we
> constructed was quite an enlightenment.
>
> And then it took me even longer to fix it :)
Fun
> >> I'll give this some more thought and see if can come up with
> >> something clever.
> >>
> >> Here's one thought: We could make dma_fence_array automatically
> >> collapse any arrays it references and instead directly reference their
> >> fences. This way, no matter how much the client chains things, they
> >> will never get more than one dma_fence_array. Of course, the
> >> difficulty here (answering my own question) comes if they ping-pong
> >> back-and-forth between something which constructs a dma_fence_array
> >> and something which constructs a dma_fence_chain to get
> >> array-of-chain-of-array-of-chain-of-... More thought needed.
>
> Condensing the fences into a larger array can certainly work, yes.
>
> > Answering my own questions again... I think the
> > array-of-chain-of-array case is also solvable.
> >
> > For array-of-chain, we can simply add all unsignaled dma_fences in the
> > chain to the array. The array won't signal until all of them have
> > which is exactly the same behavior as if we'd added the chain itself.
>
> Yeah, that should work. Probably best to implement something like a
> cursor to walk all fences in the data structure.
>
> > For chain-of-array, we can add all unsignaled dma_fences in the array
> > to the same point in the chain. There may be some fiddling with the
> > chain numbering required here but I think we can get it so the chain
> > won't signal until everything in the array has signaled and we get the
> > same behavior as if we'd added the dma_fence_array to the chain.
>
> Well as far as I can see this won't work because it would break the
> semantics of the timeline sync.
I'm not 100% convinced it has to. We already have support for the
seqno regressing and we ensure that we still wait for all the fences.
I thought maybe we could use that but I haven't spent enough time
looking at the details to be sure. I may be missing something.
> But I think I know a different way which should work: A dma_fence_chain
> can still contain a dma_fence_array, only the other way around is
> forbidden. Then we create the cursor functionality in such a way that it
> allows us to deep dive into the data structure and return all containing
> fences one by one.
Agreed. As long as one container is able to consume the other, it's fine.
> I can prototype that if you want, shouldn't be more than a few hours of
> hacking anyway.
If you'd like to, go for it. I'd be happy to give it a go as well but
if you already know what you want, it may be easier for you to just
write the patch for the cursor.
Two more questions:
1. Do you want this collapsing to happen every time we create a
dma_fence_array or should it be a special entrypoint? Collapsing all
the time likely means doing extra array calculations instead of the
dma_fence_array taking ownership of the array that's passed in. My
gut says that cost is ok; but my gut doesn't spend much time in kernel
space.
2. When we do the collapsing, should we call dma_fence_is_signaled()
to avoid adding signaled fences to the array? It seems like avoiding
adding references to fences that are already signaled would let the
kernel clean them up faster and reduce the likelihood that a fence
will hang around forever because it keeps getting added to arrays with
other unsignaled fences.
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v3
Am 05.03.20 um 15:35 schrieb Nirmoy:
On 3/5/20 3:07 PM, Gerd Hoffmann wrote:
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..2749c2d25ac4 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -198,6 +198,13 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
*gbo)
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
+static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
+{
+ if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
+ return 0;
returns 0 on error.
I am not sure if we should call this an error. This patch series
removes below offset calculation from ttm_bo.c.
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
Most of the driver sets "bo->mem.mm_node". Thomas suggested to use
this "return 0" in case some driver depends on bo->offset = 0.
We should probably add a code comment here to explain why we do this.
Something like "Keep TTM behavior for now, remove when drivers are audited".
Regards,
Christian.
+ return gbo->bo.mem.start;
+}
+
/**
* drm_gem_vram_offset() - \
Returns a GEM VRAM object's offset in video memory
@@ -214,7 +221,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
returns -errno on error.
- return gbo->bo.offset;
+ return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
And given that one calls the other behavior on error should better be
consistent ...
cheers,
Gerd
Regards,
Nirmoy
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v3
On 3/5/20 3:07 PM, Gerd Hoffmann wrote:
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..2749c2d25ac4 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -198,6 +198,13 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
*gbo)
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
+static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
+{
+ if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
+ return 0;
returns 0 on error.
I am not sure if we should call this an error. This patch series removes
below offset calculation from ttm_bo.c.
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
Most of the driver sets "bo->mem.mm_node". Thomas suggested to use this
"return 0" in case some driver depends on bo->offset = 0.
+ return gbo->bo.mem.start;
+}
+
/**
* drm_gem_vram_offset() - \
Returns a GEM VRAM object's offset in video memory
@@ -214,7 +221,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
returns -errno on error.
- return gbo->bo.offset;
+ return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
And given that one calls the other behavior on error should better be
consistent ...
cheers,
Gerd
Regards,
Nirmoy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v3
Hi
Am 05.03.20 um 15:07 schrieb Gerd Hoffmann:
> On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
>> Calculate GEM VRAM bo's offset within vram-helper without depending on
>> bo->offset.
>>
>> Signed-off-by: Nirmoy Das
>> Reviewed-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>> index 92a11bb42365..2749c2d25ac4 100644
>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>> @@ -198,6 +198,13 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
>> *gbo)
>> }
>> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>>
>> +static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
>> +{
>> +if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
>> +return 0;
>
> returns 0 on error.
>
>> +return gbo->bo.mem.start;
>> +}
>> +
>> /**
>> * drm_gem_vram_offset() - \
>> Returns a GEM VRAM object's offset in video memory
>> @@ -214,7 +221,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
>> {
>> if (WARN_ON_ONCE(!gbo->pin_count))
>> return (s64)-ENODEV;
>
> returns -errno on error.
>
>> -return gbo->bo.offset;
>> +return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
>
> And given that one calls the other behavior on error should better be
> consistent ...
It is expected that the offset is valid if pin_count is positive.
Anything else would be a massive ref-counting bug. And that's been the
behavior of the old code as well.
But I agree that the current patch is inconsistent. I suggest changing
the return type of drm_gem_vram_pg_offset() to u64.
Best regards
Thomas
>
> cheers,
> Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/vboxvideo/vboxvideo.h: Replace zero-length array with flexible-array member
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/vboxvideo.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vboxvideo/vboxvideo.h
b/drivers/gpu/drm/vboxvideo/vboxvideo.h
index 0592004f71aa..a5de40fe1a76 100644
--- a/drivers/gpu/drm/vboxvideo/vboxvideo.h
+++ b/drivers/gpu/drm/vboxvideo/vboxvideo.h
@@ -138,7 +138,7 @@ struct vbva_buffer {
u32 data_len;
/* variable size for the rest of the vbva_buffer area in VRAM. */
- u8 data[0];
+ u8 data[];
} __packed;
#define VBVA_MAX_RECORD_SIZE (128 * 1024 * 1024)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v3
On Thu, Mar 05, 2020 at 02:29:08PM +0100, Nirmoy Das wrote:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 92a11bb42365..2749c2d25ac4 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -198,6 +198,13 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
> *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>
> +static s64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
> +{
> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
> + return 0;
returns 0 on error.
> + return gbo->bo.mem.start;
> +}
> +
> /**
> * drm_gem_vram_offset() - \
> Returns a GEM VRAM object's offset in video memory
> @@ -214,7 +221,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
> {
> if (WARN_ON_ONCE(!gbo->pin_count))
> return (s64)-ENODEV;
returns -errno on error.
> - return gbo->bo.offset;
> + return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
And given that one calls the other behavior on error should better be
consistent ...
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
Am 05.03.20 um 14:29 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6d1e91be9c78..9f24fb287d71 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -85,7 +85,6 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev,
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
- drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
drm_printf(p, "size: %llu\n", man->size);
drm_printf(p, "available_caching: 0x%08X\n",
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
@@ -345,12 +344,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
moved:
bo->evicted = false;
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index b9bc1b00142e..d6f39ee5bf5d 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -213,8 +213,6 @@ struct ttm_buffer_object {
* either of these locks held.
*/
- uint64_t offset; /* GPU address space is independent of CPU word size */
-
struct sg_table *sg;
};
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd09f4b2..c8ce6c181abe 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -177,7 +177,6 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
- uint64_t gpu_offset; /* GPU address space is independent of CPU word
size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] drm/nouveau: don't use ttm bo->offset v3
Am 05.03.20 um 14:29 schrieb Nirmoy Das:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Looks like this is the only patch without an rb or at least acked-by.
Can anybody comment or at least throw a quick tested-by on it?
With that done I would say I would pick this series up for inclusion
into drm-misc-next.
Regards,
Christian.
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 8
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADD
Re: [PATCH 2/3] drm/dp_mst: Don't show connectors as connected before probing available PBN
On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> It's next to impossible for us to do connector probing on topologies
> without occasionally racing with userspace, since creating a connector
> itself causes a hotplug event which we have to send before probing the
> available PBN of a connector. Even if we didn't have this hotplug event
> sent, there's still always a chance that userspace started probing
> connectors before we finished probing the topology.
>
> This can be a problem when validating a new MST state since the
> connector will be shown as connected briefly, but without any available
> PBN - causing any atomic state which would enable said connector to fail
> with -ENOSPC. So, let's simply workaround this by telling userspace new
> MST connectors are disconnected until we've finished probing their PBN.
> Since we always send a hotplug event at the end of the link address
> probing process, userspace will still know to reprobe the connector when
> we're ready.
>
> Signed-off-by: Lyude Paul
> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST
> atomic check")
> Cc: Mikita Lipski
> Cc: Alex Deucher
> Cc: Sean Paul
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 207eef08d12c..7b0ff0cff954 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4033,6 +4033,19 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> ret = connector_status_connected;
> break;
> }
> +
> + /* We don't want to tell userspace the port is actually plugged into
> + * anything until we've finished probing it's available_pbn, otherwise
"its"
Why is the connector even registered before we've finished the probe?
> + * userspace will see racy atomic check failures
> + *
> + * Since we always send a hotplug at the end of probing topology
> + * state, we can just let userspace reprobe this connector later.
> + */
> + if (ret == connector_status_connected && !port->available_pbn) {
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] not ready yet (PBN not
> probed)\n",
> + connector->base.id, connector->name);
> + ret = connector_status_disconnected;
> + }
> out:
> drm_dp_mst_topology_put_port(port);
> return ret;
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-buf: Add an API for importing and exporting sync files
Am 04.03.20 um 17:41 schrieb Jason Ekstrand:
On Wed, Mar 4, 2020 at 10:27 AM Jason Ekstrand wrote:
On Wed, Mar 4, 2020 at 2:34 AM Christian König wrote:
Am 03.03.20 um 20:10 schrieb Jason Ekstrand:
On Thu, Feb 27, 2020 at 2:28 AM Christian König
wrote:
[SNIP]
For reference see what dance is necessary in the dma_fence_chain_release
function to avoid that:
/* Manually unlink the chain as much as possible to avoid
recursion
* and potential stack overflow.
*/
while ((prev = rcu_dereference_protected(chain->prev, true))) {
It took me quite a while to figure out how to do this without causing
issues. But I don't see how this would be possible for dma_fence_array.
Ah, I see the issue now! It hadn't even occurred to me that userspace
could use this to build up an infinite recursion chain. That's nasty!
Yeah, when I first stumbled over it it was like why the heck is my code
crashing in an interrupt handler?
Realizing that this is stack corruption because of the long chain we
constructed was quite an enlightenment.
And then it took me even longer to fix it :)
I'll give this some more thought and see if can come up with
something clever.
Here's one thought: We could make dma_fence_array automatically
collapse any arrays it references and instead directly reference their
fences. This way, no matter how much the client chains things, they
will never get more than one dma_fence_array. Of course, the
difficulty here (answering my own question) comes if they ping-pong
back-and-forth between something which constructs a dma_fence_array
and something which constructs a dma_fence_chain to get
array-of-chain-of-array-of-chain-of-... More thought needed.
Condensing the fences into a larger array can certainly work, yes.
Answering my own questions again... I think the
array-of-chain-of-array case is also solvable.
For array-of-chain, we can simply add all unsignaled dma_fences in the
chain to the array. The array won't signal until all of them have
which is exactly the same behavior as if we'd added the chain itself.
Yeah, that should work. Probably best to implement something like a
cursor to walk all fences in the data structure.
For chain-of-array, we can add all unsignaled dma_fences in the array
to the same point in the chain. There may be some fiddling with the
chain numbering required here but I think we can get it so the chain
won't signal until everything in the array has signaled and we get the
same behavior as if we'd added the dma_fence_array to the chain.
Well as far as I can see this won't work because it would break the
semantics of the timeline sync.
But I think I know a different way which should work: A dma_fence_chain
can still contain a dma_fence_array, only the other way around is
forbidden. Then we create the cursor functionality in such a way that it
allows us to deep dive into the data structure and return all containing
fences one by one.
I can prototype that if you want, shouldn't be more than a few hours of
hacking anyway.
Regards,
Christian.
In both cases, we end up with either a single array or a single and
destruction doesn't require recursion. Thoughts?
--Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 7/7] drm/todo: Update drm_fb_helper tasks
drm_fb_helper tasks are completed now hence remove them from todo list. Changes since v1: * remove entire drm_fb_helper tasks from todo list. Daniel's "64914da24ea9 drm/fbdev-helper: don't force restores" already fixes first one (Daniel) Signed-off-by: Pankaj Bharadiya Reviewed-by: Laurent Pinchart Reviewed-by: Emil Velikov --- Documentation/gpu/todo.rst | 17 - 1 file changed, 17 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index ccf5e8e34222..439656f55c5d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -359,23 +359,6 @@ Contact: Sean Paul Level: Starter -drm_fb_helper tasks - -- drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() - not the _force variant so it can bail out if there is a master. But first - these igt tests need to be fixed: kms_fbcon_fbt@psr and - kms_fbcon_fbt@psr-suspend. - -- The max connector argument for drm_fb_helper_init() isn't used anymore and - can be removed. - -- The helper doesn't keep an array of connectors anymore so these can be - removed: drm_fb_helper_single_add_all_connectors(), - drm_fb_helper_add_one_connector() and drm_fb_helper_remove_one_connector(). - -Level: Intermediate - connector register/unregister fixes --- -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
