Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 20.06.19 um 18:30 schrieb Emil Velikov: > On 2019/06/14, Koenig, Christian wrote: >> Am 14.06.19 um 17:53 schrieb Emil Velikov: >>> On 2019/06/14, Koenig, Christian wrote: Am 14.06.19 um 14:09 schrieb Emil Velikov: > On 2019/05/27, Emil Velikov wrote: > [SNIP] > Hi Christian, > > > In the following, I would like to summarise and emphasize the need for > DRM_AUTH removal. I would kindly ask you to spend a couple of minutes > extra reading it. > > > Today DRM drivers* do not make any distinction between primary and > render node clients. That is actually not 100% correct. We have a special case where a DRM master is allowed to change the priority of render node clients. >>> Can you provide a link? I cannot find that code. >> See amdgpu_sched_ioctl(). >> > Thus for a render capable driver, any premise of > separation, security or otherwise imposed via DRM_AUTH is a fallacy. Yeah, that's what I agree on. I just don't think that removing DRM_AUTH now is the right direction to take. >>> Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW >>> ioctls. >>> >>> That aside, can you propose an alternative solution that addresses this >>> and the second point just below? >> Give me a few days to work on this, it's already Friday 6pm here. >> > Hi Christian, > > Any progress? As mentioned earlier, I'm OK with writing the patches although > I would love to hear your plan. First of all I tried to disable DRM authentication completely with a kernel config option. Surprisingly that actually works out of the box at least on the AMDGPU stack. This effectively allows us to get rid of DRI2 and the related security problems. Only thing left for that is that I'm just not sure how to signal this to userspace so that the DDX wouldn't advertise DRI2 at all any more. As a next step I looked into if we can disable the command submission for DRM master. Turned out that this is relatively easy as well. All we have to do is to fix the bug Michel pointed out about KMS handles for display and let the DDX use a render node instead of the DRM master for Glamor. Still need to sync up with Michel and/or Marek whats the best way of doing this. The last step (and that's what I haven't tried yet) would be to disable DRM authentication for Navi even when it is still compiled into the kernel. But that is more or less just a typing exercise. Regards, Christian. > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH net-next] br_netfilter: prevent UAF in brnf_exit_net()
On Wed, Jun 19, 2019 at 07:05:47PM +0200, Christian Brauner wrote: > Prevent a UAF in brnf_exit_net(). Applied, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
XDC 2019: Less than three weeks to go to submit your talks, workshops or demos!
Hello! Less than three weeks to go to submit your talks, workshops or demos for this year's X.Org Developer Conference, which will be taking place in Montréal, Canada on October 2-4, 2019! The 2019 X.Org Developers Conference is the annual technical meeting for X Window System and Free Desktop developers. Attendees will gather to discuss outstanding technical issues related to the Open Source Graphics stack (Linux kernel, Mesa, DRM, Wayland, X11, etc.) and its software ecosystem. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the XDC website to learn more: https://xdc2019.x.org/ The deadline for submissions Sunday, 7 July 2019. Best, Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 2/2] phy: Add driver for mixel mipi dphy found on NXP's i.MX8 SoCs
Hi, On 24/05/19 9:31 PM, Kishon Vijay Abraham I wrote: > Hi, > > On 24/05/19 5:53 PM, Fabio Estevam wrote: >> Hi Kishon, >> >> On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote: >>> >>> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since >>> this is an IP core it will likely be found on others in the future. So >>> instead of adding this to the nwl host driver make it a generic PHY >>> driver. >>> >>> The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be >>> added once the necessary system controller bits are in via >>> mixel_dphy_devdata. >>> >>> Signed-off-by: Guido Günther >>> Co-developed-by: Robert Chiras >>> Signed-off-by: Robert Chiras >>> Reviewed-by: Fabio Estevam >>> Reviewed-by: Sam Ravnborg >> >> Would you have any comments on this series, please? > > I don't have any comments. I'll queue this once I start queuing patches for > the > next merge window. Can you fix the following checkpatch warning and repost? WARNING: quoted string split across lines #420: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:280: + dev_dbg(&phy->dev, "hs_prepare: %u, clk_prepare: %u, " + "hs_zero: %u, clk_zero: %u, " WARNING: quoted string split across lines #421: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:281: + "hs_zero: %u, clk_zero: %u, " + "hs_trail: %u, clk_trail: %u, " WARNING: quoted string split across lines #422: FILE: drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c:282: + "hs_trail: %u, clk_trail: %u, " + "rxhs_settle: %u\n", Thanks Kishon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/sti: Remove duplicated include from sti_drv.c
Remove duplicated include. Signed-off-by: YueHaibing --- drivers/gpu/drm/sti/sti_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c index bb6ae6dd66c9..2edd666fb44a 100644 --- a/drivers/gpu/drm/sti/sti_drv.c +++ b/drivers/gpu/drm/sti/sti_drv.c @@ -23,7 +23,6 @@ #include "sti_crtc.h" #include "sti_drv.h" -#include "sti_drv.h" #include "sti_plane.h" #define DRIVER_NAME"sti" ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] backlight: gpio_backlight: Enable ACPI enumeration
On Thu, Jun 20, 2019 at 03:12:05PM +0100, Daniel Thompson wrote: > On 19/06/2019 16:21, Andy Shevchenko wrote: > > ACPI allows to enumerate specific devices by using compatible strings. > > Enable that enumeration for GPIO based backlight devices. > > + dev_err(&pdev->dev, > > + "failed to find platform data or device tree node.\n"); > > Should the string also be updated? I don't think it's necessary. The device tree compatible mode is for DT drivers, so, it is assumed that person knows much enough and this message would be useful as is. > If what is updated to acknoledge option to use ACPI then: > Acked-by: Daniel Thompson Thanks! -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019-06-21 9:12 a.m., Koenig, Christian wrote: > > First of all I tried to disable DRM authentication completely with a > kernel config option. Surprisingly that actually works out of the box at > least on the AMDGPU stack. > > This effectively allows us to get rid of DRI2 and the related security > problems. Only thing left for that is that I'm just not sure how to > signal this to userspace so that the DDX wouldn't advertise DRI2 at all > any more. FWIW, getting rid of DRI2 also needs to be discussed with amdgpu-pro OpenGL driver folks. > As a next step I looked into if we can disable the command submission > for DRM master. Turned out that this is relatively easy as well. > > All we have to do is to fix the bug Michel pointed out about KMS handles > for display I'm working on that, consider it fixed. > and let the DDX use a render node instead of the DRM master for Glamor. > Still need to sync up with Michel and/or Marek whats the best way of > doing this. My suggestion was to add a new variant of amdgpu_device_initialize. When the new variant is called, libdrm_amdgpu internally uses a render node for command submission etc. whenever possible. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Adds system power management support
From: "Lowry Li (Arm Technology China)"
Adds system power management support in KMS kernel driver.
Depends on:
- https://patchwork.freedesktop.org/series/61650/
- https://patchwork.freedesktop.org/series/60083/
Changes since v1:
Since we have unified mclk/pclk/pipeline->aclk to one mclk, which will
be turned on/off when crtc atomic enable/disable, removed runtime power
management.
Adds to disable the aclk when register access finished.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 63 +---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 35 +++--
4 files changed, 93 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index cafb445..85eccdda 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -257,6 +257,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
komeda_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old)
{
+ pm_runtime_get_sync(crtc->dev->dev);
komeda_crtc_prepare(to_kcrtc(crtc));
drm_crtc_vblank_on(crtc);
komeda_crtc_do_flush(crtc, old);
@@ -330,6 +331,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
drm_crtc_vblank_off(crtc);
komeda_crtc_unprepare(kcrtc);
+ pm_runtime_put(crtc->dev->dev);
}
static void
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index e1aa58e..c9837dc 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -209,7 +209,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
product->product_id,
MALIDP_CORE_ID_PRODUCT_ID(mdev->chip.core_id));
err = -ENODEV;
- goto err_cleanup;
+ goto disable_clk;
}
DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
@@ -222,19 +222,19 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
err = mdev->funcs->enum_resources(mdev);
if (err) {
DRM_ERROR("enumerate display resource failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
err = komeda_parse_dt(dev, mdev);
if (err) {
DRM_ERROR("parse device tree failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
err = komeda_assemble_pipelines(mdev);
if (err) {
DRM_ERROR("assemble display pipelines failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
dev->dma_parms = &mdev->dma_parms;
@@ -247,11 +247,13 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
if (mdev->iommu && mdev->funcs->connect_iommu) {
err = mdev->funcs->connect_iommu(mdev);
if (err) {
- mdev->iommu = NULL;
- goto err_cleanup;
+ DRM_ERROR("connect iommu failed.\n");
+ goto disable_clk;
}
}
+ clk_disable_unprepare(mdev->aclk);
+
err = sysfs_create_group(&dev->kobj, &komeda_sysfs_attr_group);
if (err) {
DRM_ERROR("create sysfs group failed.\n");
@@ -264,6 +266,8 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
return mdev;
+disable_clk:
+ clk_disable_unprepare(mdev->aclk);
err_cleanup:
komeda_dev_destroy(mdev);
return ERR_PTR(err);
@@ -281,6 +285,9 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
debugfs_remove_recursive(mdev->debugfs_root);
#endif
+ if (mdev->aclk)
+ clk_prepare_enable(mdev->aclk);
+
if (mdev->iommu && mdev->funcs->disconnect_iommu)
mdev->funcs->disconnect_iommu(mdev);
mdev->iommu = NULL;
@@ -308,3 +315,47 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
devm_kfree(dev, mdev);
}
+
+int komeda_dev_resume(struct komeda_dev *mdev)
+{
+ int ret = 0;
+
+ clk_prepare_enable(mdev->aclk);
+
+ if (mdev->iommu && mdev->funcs->connect_iommu) {
+ ret = mdev->funcs->connect_iommu(mdev);
+ if (ret < 0) {
+ DRM_ERROR("connect iommu failed.\n");
+ goto disable_clk;
+ }
+ }
+
+ ret = mdev->funcs->enable_irq(mdev);
+
+disable_clk:
+ clk_disable_unprepare(mdev->aclk);
+
+ return ret;
+}
+
+int komeda_dev_suspend(struct komeda_dev *mdev)
+{
+ int ret = 0;
+
+ clk_prepare_enable(mdev->aclk);
+
+ if (mdev->iommu && mdev->funcs-
[PATCH] drm/komeda: Adds system power management support
From: "Lowry Li (Arm Technology China)"
Adds system power management support in KMS kernel driver.
Depends on:
- https://patchwork.freedesktop.org/series/61650/
- https://patchwork.freedesktop.org/series/60083/
- https://patchwork.freedesktop.org/series/61647/
Changes since v1:
Since we have unified mclk/pclk/pipeline->aclk to one mclk, which will
be turned on/off when crtc atomic enable/disable, removed runtime power
management.
Adds to disable the aclk when register access finished.
Changes since v2:
Removes run time get/put related flow.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 1 -
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 63 +---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 35 +++--
4 files changed, 91 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index cafb445..d14e7f3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -5,7 +5,6 @@
*
*/
#include
-#include
#include
#include
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index e1aa58e..c9837dc 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -209,7 +209,7 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
product->product_id,
MALIDP_CORE_ID_PRODUCT_ID(mdev->chip.core_id));
err = -ENODEV;
- goto err_cleanup;
+ goto disable_clk;
}
DRM_INFO("Found ARM Mali-D%x version r%dp%d\n",
@@ -222,19 +222,19 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
err = mdev->funcs->enum_resources(mdev);
if (err) {
DRM_ERROR("enumerate display resource failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
err = komeda_parse_dt(dev, mdev);
if (err) {
DRM_ERROR("parse device tree failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
err = komeda_assemble_pipelines(mdev);
if (err) {
DRM_ERROR("assemble display pipelines failed.\n");
- goto err_cleanup;
+ goto disable_clk;
}
dev->dma_parms = &mdev->dma_parms;
@@ -247,11 +247,13 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
if (mdev->iommu && mdev->funcs->connect_iommu) {
err = mdev->funcs->connect_iommu(mdev);
if (err) {
- mdev->iommu = NULL;
- goto err_cleanup;
+ DRM_ERROR("connect iommu failed.\n");
+ goto disable_clk;
}
}
+ clk_disable_unprepare(mdev->aclk);
+
err = sysfs_create_group(&dev->kobj, &komeda_sysfs_attr_group);
if (err) {
DRM_ERROR("create sysfs group failed.\n");
@@ -264,6 +266,8 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
return mdev;
+disable_clk:
+ clk_disable_unprepare(mdev->aclk);
err_cleanup:
komeda_dev_destroy(mdev);
return ERR_PTR(err);
@@ -281,6 +285,9 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
debugfs_remove_recursive(mdev->debugfs_root);
#endif
+ if (mdev->aclk)
+ clk_prepare_enable(mdev->aclk);
+
if (mdev->iommu && mdev->funcs->disconnect_iommu)
mdev->funcs->disconnect_iommu(mdev);
mdev->iommu = NULL;
@@ -308,3 +315,47 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
devm_kfree(dev, mdev);
}
+
+int komeda_dev_resume(struct komeda_dev *mdev)
+{
+ int ret = 0;
+
+ clk_prepare_enable(mdev->aclk);
+
+ if (mdev->iommu && mdev->funcs->connect_iommu) {
+ ret = mdev->funcs->connect_iommu(mdev);
+ if (ret < 0) {
+ DRM_ERROR("connect iommu failed.\n");
+ goto disable_clk;
+ }
+ }
+
+ ret = mdev->funcs->enable_irq(mdev);
+
+disable_clk:
+ clk_disable_unprepare(mdev->aclk);
+
+ return ret;
+}
+
+int komeda_dev_suspend(struct komeda_dev *mdev)
+{
+ int ret = 0;
+
+ clk_prepare_enable(mdev->aclk);
+
+ if (mdev->iommu && mdev->funcs->disconnect_iommu) {
+ ret = mdev->funcs->disconnect_iommu(mdev);
+ if (ret < 0) {
+ DRM_ERROR("disconnect iommu failed.\n");
+ goto disable_clk;
+ }
+ }
+
+ ret = mdev->funcs->disable_irq(mdev);
+
+disable_clk:
+ clk_disable_unprepare(mdev->aclk);
+
+ return ret;
+}
diff -
Re: [linux-sunxi] [PATCH v2 5/9] drm/sun4i: tcon_top: Register clock gates in probe
On Fri, Jun 21, 2019 at 12:24 AM Jagan Teki wrote:
>
> On Tue, Jun 18, 2019 at 4:24 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Jun 18, 2019 at 6:34 PM Jagan Teki
> > wrote:
> > >
> > > On Tue, Jun 18, 2019 at 1:23 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Tue, Jun 18, 2019 at 3:45 PM Jagan Teki
> > > > wrote:
> > > > >
> > > > > On Tue, Jun 18, 2019 at 12:49 PM Chen-Yu Tsai wrote:
> > > > > >
> > > > > > On Mon, Jun 17, 2019 at 6:30 PM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > On Sun, Jun 16, 2019 at 11:01 AM Chen-Yu Tsai
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sat, Jun 15, 2019 at 12:44 AM Jagan Teki
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right
> > > > > > > > > now these are register during bind call.
> > > > > > > > >
> > > > > > > > > Of which, dsi clock gate would required during DPHY probe
> > > > > > > > > but same can miss to get since tcon top is not bound at
> > > > > > > > > that time.
> > > > > > > > >
> > > > > > > > > To solve, this circular dependency move the clock gate
> > > > > > > > > registration from bind to probe so-that DPHY can get the
> > > > > > > > > dsi gate clock on time.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jagan Teki
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 94
> > > > > > > > > ++
> > > > > > > > > 1 file changed, 49 insertions(+), 45 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > index 465e9b0cdfee..a8978b3fe851 100644
> > > > > > > > > --- a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > > > > > > > > @@ -124,7 +124,53 @@ static struct clk_hw
> > > > > > > > > *sun8i_tcon_top_register_gate(struct device *dev,
> > > > > > > > > static int sun8i_tcon_top_bind(struct device *dev, struct
> > > > > > > > > device *master,
> > > > > > > > >void *data)
> > > > > > > > > {
> > > > > > > > > - struct platform_device *pdev =
> > > > > > > > > to_platform_device(dev);
> > > > > > > > > + struct sun8i_tcon_top *tcon_top =
> > > > > > > > > dev_get_drvdata(dev);
> > > > > > > > > + int ret;
> > > > > > > > > +
> > > > > > > > > + ret = reset_control_deassert(tcon_top->rst);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(dev, "Could not deassert ctrl reset
> > > > > > > > > control\n");
> > > > > > > > > + return ret;
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > + ret = clk_prepare_enable(tcon_top->bus);
> > > > > > > > > + if (ret) {
> > > > > > > > > + dev_err(dev, "Could not enable bus clock\n");
> > > > > > > > > + goto err_assert_reset;
> > > > > > > > > + }
> > > > > > > >
> > > > > > > > You have to de-assert the reset control and enable the clock
> > > > > > > > before the
> > > > > > > > clocks it provides are registered. Otherwise a consumer may
> > > > > > > > come in and
> > > > > > > > ask for the provided clock to be enabled, but since the TCON
> > > > > > > > TOP's own
> > > > > > > > reset and clock are still disabled, you can't actually access
> > > > > > > > the registers
> > > > > > > > that controls the provided clock.
> > > > > > >
> > > > > > > These rst and bus are common reset and bus clocks not tcon top
> > > > > > > clocks
> > > > > > > that are trying to register here. ie reason I have not moved it in
> > > > > > > top.
> > > > > >
> > > > > > And you're sure that toggling bits in the TCON TOP block doesn't
> > > > > > require
> > > > > > the reset to be de-asserted and the bus clock enabled?
> > > > > >
> > > > > > Somehow I doubt that.
> > > > > >
> > > > > > Once the driver register the clocks it provides, they absolutely
> > > > > > must work.
> > > > > > They can't only work after the bind phase when the reset gets
> > > > > > de-asserted
> > > > > > and the bus clock enabled. Or you should provide proper error
> > > > > > reporting
> > > > > > in the clock ops. I doubt you want to go that way either.
> > > > >
> > > > > Why would they won't work after bind phase? unlike tcon top gates,
> > > > > these reset, and bus are common like what we have in other DE block
> > > > > so enable them in bind won't be an issue as per as I understand. let
> > > > > me know if you want me to check in other directions.
> > > >
> > > > You misunderstood. When you moved the clock registering parts to the
> > > > probe
> > > > phase, but didn't move the clock enable and reset de-assert parts to go
> > > > with,
> > > > the clock ops will not work as expected between probe and bind time.
> > >
> > > If I understand correctly, I have moved tcon clock gates, not the bus
> > > clock or the reset. Both have independent e
[Bug 110702] segfault in radeonsi HEVC hardware decoding with yuv420p10le
https://bugs.freedesktop.org/show_bug.cgi?id=110702 --- Comment #12 from Pierre-Eric Pelloux-Prayer --- Can you try the branch from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1154 and report if it fixes the issue for you? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/rockchip: Add optional support for CRTC gamma LUT
Hi Ezequiel,
just a few minor comments. Thanks for this new iteration.
On Tue, Jun 18, 2019 at 06:34:05PM -0300, Ezequiel Garcia wrote:
> Add an optional CRTC gamma LUT support, and enable it on RK3288.
> This is currently enabled via a separate address resource,
> which needs to be specified in the devicetree.
>
> The address resource is required because on some SoCs, such as
> RK3288, the LUT address is after the MMU address, and the latter
> is supported by a different driver. This prevents the DRM driver
> from requesting an entire register space.
>
> The current implementation works for RGB 10-bit tables, as that
> is what seems to work on RK3288.
>
> Signed-off-by: Ezequiel Garcia
> ---
> Changes from RFC:
> * Request (an optional) address resource for the LUT.
> * Drop support for RK3399, which doesn't seem to work
> out of the box and needs more research.
> * Support pass-thru setting when GAMMA_LUT is NULL.
> * Add a check for the gamma size, as suggested by Ilia.
> * Move gamma setting to atomic_commit_tail, as pointed
> out by Jacopo/Laurent, is the correct way.
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 106
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 7 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +
> 4 files changed, 118 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 1c69066b6894..bf9ad6240971 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -16,6 +16,7 @@
> #include "rockchip_drm_fb.h"
> #include "rockchip_drm_gem.h"
> #include "rockchip_drm_psr.h"
> +#include "rockchip_drm_vop.h"
>
> static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
>struct drm_file *file,
> @@ -128,6 +129,8 @@ rockchip_atomic_helper_commit_tail_rpm(struct
> drm_atomic_state *old_state)
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> + rockchip_drm_vop_gamma_set(old_state);
> +
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
>
> drm_atomic_helper_commit_planes(dev, old_state,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 12ed5265a90b..5b6edbe2673f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -137,6 +137,7 @@ struct vop {
>
> uint32_t *regsbak;
> void __iomem *regs;
> + void __iomem *lut_regs;
>
> /* physical map length of vop register */
> uint32_t len;
> @@ -1153,6 +1154,94 @@ static void vop_wait_for_irq_handler(struct vop *vop)
> synchronize_irq(vop->irq);
> }
>
> +static bool vop_dsp_lut_is_enable(struct vop *vop)
> +{
> + return vop_read_reg(vop, 0, &vop->data->common->dsp_lut_en);
> +}
> +
> +static void vop_crtc_write_gamma_lut(struct vop *vop, struct drm_crtc *crtc)
> +{
> + struct drm_color_lut *lut = crtc->state->gamma_lut->data;
> + int i;
unsigned i
> +
> + for (i = 0; i < crtc->gamma_size; i++) {
> + u32 word;
here and below you could declare and initialize in one line. Matter of
tastes, up to you.
> +
> + word = (drm_color_lut_extract(lut[i].red, 10) << 20) |
> +(drm_color_lut_extract(lut[i].green, 10) << 10) |
> + drm_color_lut_extract(lut[i].blue, 10);
> + writel(word, vop->lut_regs + i * 4);
> + }
> +}
> +
> +static void vop_crtc_gamma_set(struct vop *vop, struct drm_crtc *crtc,
> +struct drm_crtc_state *old_state)
> +{
> + int idle, ret, i;
idle and i could be unsigned
> +
> + spin_lock(&vop->reg_lock);
> + VOP_REG_SET(vop, common, dsp_lut_en, 0);
> + vop_cfg_done(vop);
> + spin_unlock(&vop->reg_lock);
> +
> + ret = readx_poll_timeout(vop_dsp_lut_is_enable, vop,
> +idle, !idle, 5, 30 * 1000);
> + if (ret)
> + return;
> +
> + spin_lock(&vop->reg_lock);
> +
> + if (crtc->state->gamma_lut) {
> + if (!old_state->gamma_lut || (crtc->state->gamma_lut->base.id !=
> + old_state->gamma_lut->base.id))
> + vop_crtc_write_gamma_lut(vop, crtc);
> + } else {
i could also be declared here...
> + for (i = 0; i < crtc->gamma_size; i++) {
> + u32 word;
> +
> + word = (i << 20) | (i << 10) | i;
> + writel(word, vop->lut_regs + i * 4);
> + }
I might be confused, but are you here configuring a linear LUT table?
Isn't this equivalent to have it disabled?
> + }
> +
> + VOP_REG_SET(vop, common, dsp_lut_en, 1);
> + vop_cfg_done(vop);
> + spin_unlock(&vop->reg_lock);
> +}
> +
> +static int vop_crtc_atomic_check(struct drm_crtc
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 09:41 schrieb Michel Dänzer: > On 2019-06-21 9:12 a.m., Koenig, Christian wrote: >> First of all I tried to disable DRM authentication completely with a >> kernel config option. Surprisingly that actually works out of the box at >> least on the AMDGPU stack. >> >> This effectively allows us to get rid of DRI2 and the related security >> problems. Only thing left for that is that I'm just not sure how to >> signal this to userspace so that the DDX wouldn't advertise DRI2 at all >> any more. > FWIW, getting rid of DRI2 also needs to be discussed with amdgpu-pro > OpenGL driver folks. Good point, but I don't expect much problems from that direction. IIRC they where quite happy to not have to support DRI2 except for a very very old X server version. >> As a next step I looked into if we can disable the command submission >> for DRM master. Turned out that this is relatively easy as well. >> >> All we have to do is to fix the bug Michel pointed out about KMS handles >> for display > I'm working on that, consider it fixed. > > >> and let the DDX use a render node instead of the DRM master for Glamor. >> Still need to sync up with Michel and/or Marek whats the best way of >> doing this. > My suggestion was to add a new variant of amdgpu_device_initialize. When > the new variant is called, libdrm_amdgpu internally uses a render node > for command submission etc. whenever possible. Yeah, sounds like a plan to me. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm/exynos: drop drmP.h usage
Hi, 19. 6. 5. 오후 11:49에 Sam Ravnborg 이(가) 쓴 글: > Drop use of the deprecated drmP.h file. > Replace with forwards / externals as appropriate. > > While touching the list of include files divide > them up in blocks and sort them. Build error happens with this patch. [error log] drivers/gpu/drm/exynos/exynos_drm_g2d.c:196:27: error: field 'base' has incomplete type struct drm_pending_event base; ^ drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function 'g2d_userptr_get_dma_addr': drivers/gpu/drm/exynos/exynos_drm_g2d.c:421:50: error: dereferencing pointer to incomplete type struct drm_exynos_file_private *file_priv = filp->driver_priv; -- snip -- Thanks, Inki Dae > > Signed-off-by: Sam Ravnborg > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: David Airlie > Cc: Daniel Vetter > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Jingoo Han > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++-- > drivers/gpu/drm/exynos/exynos_dp.c| 13 +++--- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++-- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 +++--- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +++- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 +-- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ++-- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +++ > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 8 ++-- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 ++-- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 +++--- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 ++--- > drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++--- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- > drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++--- > 24 files changed, 151 insertions(+), 136 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > index 73b318a7ef49..40423e237b82 100644 > --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c > @@ -10,7 +10,6 @@ > * published by the Free Software Foundationr > */ > > -#include > #include > #include > #include > @@ -18,11 +17,15 @@ > #include > #include > #include > +#include > #include > #include > > -#include "exynos_drm_drv.h" > +#include > +#include > + > #include "exynos_drm_crtc.h" > +#include "exynos_drm_drv.h" > #include "exynos_drm_fb.h" > #include "exynos_drm_plane.h" > #include "regs-decon5433.h" > diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c > b/drivers/gpu/drm/exynos/exynos7_drm_decon.c > index 0217ee9a118d..98c2debdd053 100644 > --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c > +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c > @@ -11,8 +11,6 @@ > * option) any later version. > * > */ > -#include > -#include > > #include > #include > @@ -26,10 +24,14 @@ > #include > #include > > +#include > +#include > +#include > + > #include "exynos_drm_crtc.h" > -#include "exynos_drm_plane.h" > #include "exynos_drm_drv.h" > #include "exynos_drm_fb.h" > +#include "exynos_drm_plane.h" > #include "regs-decon7.h" > > /* > diff --git a/drivers/gpu/drm/exynos/exynos_dp.c > b/drivers/gpu/drm/exynos/exynos_dp.c > index b0288cf85701..882275e475c9 100644 > --- a/drivers/gpu/drm/exynos/exynos_dp.c > +++ b/drivers/gpu/drm/exynos/exynos_dp.c > @@ -10,25 +10,24 @@ > * option) any later version. > */ > > -#include > -#include > -#include > #include > -#include > #include > +#include > +#include > +#include > +#include > #include > #include > #include > #include > > -#include > +#include > #include > #include > #include > #include > +#include > #include > - > -#include > #include > > #include "exynos_drm_crtc.h" > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > index 96ee83a798c4..201fdc75ec18 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > @@ -12,11 +12,11 @@ > * o
Re: [linux-sunxi] Re: [PATCH v10 03/11] drm/sun4i: dsi: Fix video start delay computation
On Fri, May 24, 2019 at 6:27 PM Jagan Teki wrote: > > On Fri, May 24, 2019 at 2:18 AM Maxime Ripard > wrote: > > > > On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote: > > > The current code is computing vertical video start delay as > > > > > > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; > > > > > > On which the second parameter > > > > > > mode->vsync_end - mode->vdisplay = front porch + sync timings > > > > > > according to "DRM kernel-internal display mode structure" in > > > include/drm/drm_modes.h > > > > > > With adding additional sync timings, the desired video start delay > > > value as 510 for "bananapi,s070wv20-ct16" panel timings which indeed > > > trigger panel flip_done timed out as: > > > > > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > > > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > > > [CRTC:46:crtc-0] vblank wait timed out > > > Modules linked in: > > > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > > > 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > > > Hardware name: Allwinner sun8i Family > > > Workqueue: events deferred_probe_work_func > > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > > [] (show_stack) from [] (dump_stack+0x84/0x98) > > > [] (dump_stack) from [] (__warn+0xfc/0x114) > > > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > > > [] (warn_slowpath_fmt) from [] > > > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > > > [] (drm_atomic_helper_wait_for_vblanks.part.1) from > > > [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > > > [] (drm_atomic_helper_commit_tail_rpm) from [] > > > (commit_tail+0x40/0x6c) > > > [] (commit_tail) from [] > > > (drm_atomic_helper_commit+0xbc/0x128) > > > [] (drm_atomic_helper_commit) from [] > > > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > > > [] (restore_fbdev_mode_atomic) from [] > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > > > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > > > [] (drm_fb_helper_set_par+0x30/0x54) > > > [] (drm_fb_helper_set_par) from [] > > > (fbcon_init+0x560/0x5ac) > > > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > > > [] (visual_init) from [] > > > (do_bind_con_driver+0x1b0/0x390) > > > [] (do_bind_con_driver) from [] > > > (do_take_over_console+0x13c/0x1c4) > > > [] (do_take_over_console) from [] > > > (do_fbcon_takeover+0x74/0xcc) > > > [] (do_fbcon_takeover) from [] > > > (notifier_call_chain+0x44/0x84) > > > [] (notifier_call_chain) from [] > > > (__blocking_notifier_call_chain+0x48/0x60) > > > [] (__blocking_notifier_call_chain) from [] > > > (blocking_notifier_call_chain+0x18/0x20) > > > [] (blocking_notifier_call_chain) from [] > > > (register_framebuffer+0x1e0/0x2f8) > > > [] (register_framebuffer) from [] > > > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > > > [] (__drm_fb_helper_initial_config_and_unlock) from > > > [] (drm_fbdev_client_hotplug+0xe8/0x1b8) > > > [] (drm_fbdev_client_hotplug) from [] > > > (drm_fbdev_generic_setup+0x88/0x118) > > > [] (drm_fbdev_generic_setup) from [] > > > (sun4i_drv_bind+0x128/0x160) > > > [] (sun4i_drv_bind) from [] > > > (try_to_bring_up_master+0x164/0x1a0) > > > [] (try_to_bring_up_master) from [] > > > (__component_add+0x94/0x140) > > > [] (__component_add) from [] > > > (sun6i_dsi_probe+0x144/0x234) > > > [] (sun6i_dsi_probe) from [] > > > (platform_drv_probe+0x48/0x9c) > > > [] (platform_drv_probe) from [] > > > (really_probe+0x1dc/0x2c8) > > > [] (really_probe) from [] > > > (driver_probe_device+0x60/0x160) > > > [] (driver_probe_device) from [] > > > (bus_for_each_drv+0x74/0xb8) > > > [] (bus_for_each_drv) from [] > > > (__device_attach+0xd0/0x13c) > > > [] (__device_attach) from [] > > > (bus_probe_device+0x84/0x8c) > > > [] (bus_probe_device) from [] > > > (deferred_probe_work_func+0x64/0x90) > > > [] (deferred_probe_work_func) from [] > > > (process_one_work+0x204/0x420) > > > [] (process_one_work) from [] > > > (worker_thread+0x274/0x5a0) > > > [] (worker_thread) from [] (kthread+0x11c/0x14c) > > > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > > > Exception stack(0xde539fb0 to 0xde539ff8) > > > 9fa0: > > > > > > 9fc0: > > > > > > 9fe0: 0013 > > > ---[ end trace 495200a78b24980e ]--- > > > random: fast init done > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > > > flip_done timed out > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > > [CONNECTOR:48:DSI-1] flip_done timed out > > > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > > > flip_done timed out > > > > > > But the expected video start delay value is 513 which states that > > > the second parameter on the computation is "fron
Re: [PATCH 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
On Thu, Jun 20, 2019 at 04:40:12PM +0200, Neil Armstrong wrote: > Hi Andrzej, > > Gentle ping, could you review the dw-hdmi changes here ? btw not sure you absolutely need review from Andrzej, we're currently a bit undersupplied with bridge reviewers I think ... Better to ramp up more. -Daniel > > Thanks, > Neil > > On 26/05/2019 23:18, Jonas Karlman wrote: > > Add support for HDR metadata using the hdr_output_metadata connector > > property, > > configure Dynamic Range and Mastering InfoFrame accordingly. > > > > A drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers > > can use to signal when Dynamic Range and Mastering infoframes is supported. > > This flag is needed because Amlogic GXBB and GXL report same DW-HDMI > > version, > > and only GXL support DRM InfoFrame. > > > > The first patch add functionality to configure DRM InfoFrame based on the > > hdr_output_metadata connector property. > > > > The remaining patches sets the drm_infoframe flag on some SoCs supporting > > Dynamic Range and Mastering InfoFrame. > > > > Note that this was based on top of drm-misc-next and Neil Armstrong's > > "drm/meson: Add support for HDMI2.0 YUV420 4k60" series at [1] > > > > [1] https://patchwork.freedesktop.org/series/58725/#rev2 > > > > Jonas Karlman (4): > > drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support > > drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399 > > drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A > > drm/sun4i: Enable DRM InfoFrame support on H6 > > > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 109 > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++ > > drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 + > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 + > > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 + > > include/drm/bridge/dw_hdmi.h| 1 + > > 7 files changed, 157 insertions(+) > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
On Thu, Jun 20, 2019 at 04:15:59PM +0200, Paul Cercueil wrote: > > > Le mer. 19 juin 2019 à 14:26, Sam Ravnborg a écrit : > > Hi Paul. > > > > On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote: > > > Add a KMS driver for the Ingenic JZ47xx family of SoCs. > > > This driver is meant to replace the aging jz4740-fb driver. > > > > > > This driver does not make use of the simple pipe helper, for the > > > reason > > > that it will soon be updated to support more advanced features like > > > multiple planes, IPU integration for colorspace conversion and > > > up/down > > > scaling, support for DSI displays, and TV-out and HDMI outputs. > > > > > > Signed-off-by: Paul Cercueil > > > Tested-by: Artur Rojek > > > --- > > > > > > Notes: > > > v2: - Remove custom handling of panel. The panel is now > > > discovered using > > > the standard API. > > > - Lots of small tweaks suggested by upstream > > > > > > v3: - Use devm_drm_dev_init() > > > - Update compatible strings to -lcd instead of -drm > > > - Add destroy() callbacks to plane and crtc > > > - The ingenic,lcd-mode is now read from the bridge's DT node > > > > > > v4: Remove ingenic,lcd-mode property completely. The various > > > modes are now > > > deduced from the connector type, the pixel format or the bus > > > flags. > > > > > > v5: - Fix framebuffer size incorrectly calculated for 24bpp > > > framebuffers > > > - Use 32bpp framebuffer instead of 16bpp, as it'll work with > > > both > > > 16-bit and 24-bit panel > > > - Get rid of drm_format_plane_cpp() which has been dropped > > > upstream > > > - Avoid using drm_format_info->depth, which is deprecated. > > In the drm world we include the revision notes in the changelog. > > So I did this when I applied it to drm-misc-next. > > > > Fixed a few trivial checkpatch warnings about indent too. > > There was a few too-long-lines warnings that I ignored. Fixing them > > would have hurt readability. > > Thanks. > > > I assume you will maintain this driver onwards from now. > > Please request drm-misc commit rights (see > > https://www.freedesktop.org/wiki/AccountRequests/) > > You will need a legacy SSH account. > > I requested an account here: > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/162 This 404s for me. Did you set the issue to private by any chance? Or deleted already again? -Daniel > > > And you should familiarize yourself with the maintainer-tools: > > https://drm.pages.freedesktop.org/maintainer-tools/index.html > > > > For my use I use "dim update-branches; dim apply; dim push > > So only a small subset i needed for simple use. > > > > Sam > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
Le ven. 21 juin 2019 à 11:04, Daniel Vetter a écrit : On Thu, Jun 20, 2019 at 04:15:59PM +0200, Paul Cercueil wrote: Le mer. 19 juin 2019 à 14:26, Sam Ravnborg a écrit : > Hi Paul. > > On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote: > > Add a KMS driver for the Ingenic JZ47xx family of SoCs. > > This driver is meant to replace the aging jz4740-fb driver. > > > > This driver does not make use of the simple pipe helper, for the > > reason > > that it will soon be updated to support more advanced features like > > multiple planes, IPU integration for colorspace conversion and > > up/down > > scaling, support for DSI displays, and TV-out and HDMI outputs. > > > > Signed-off-by: Paul Cercueil > > Tested-by: Artur Rojek > > --- > > > > Notes: > > v2: - Remove custom handling of panel. The panel is now > > discovered using > >the standard API. > > - Lots of small tweaks suggested by upstream > > > > v3: - Use devm_drm_dev_init() > > - Update compatible strings to -lcd instead of -drm > > - Add destroy() callbacks to plane and crtc > > - The ingenic,lcd-mode is now read from the bridge's DT node > > > > v4: Remove ingenic,lcd-mode property completely. The various > > modes are now > > deduced from the connector type, the pixel format or the bus > > flags. > > > > v5: - Fix framebuffer size incorrectly calculated for 24bpp > > framebuffers > > - Use 32bpp framebuffer instead of 16bpp, as it'll work with > > both > >16-bit and 24-bit panel > > - Get rid of drm_format_plane_cpp() which has been dropped > > upstream > > - Avoid using drm_format_info->depth, which is deprecated. > In the drm world we include the revision notes in the changelog. > So I did this when I applied it to drm-misc-next. > > Fixed a few trivial checkpatch warnings about indent too. > There was a few too-long-lines warnings that I ignored. Fixing them > would have hurt readability. Thanks. > I assume you will maintain this driver onwards from now. > Please request drm-misc commit rights (see > https://www.freedesktop.org/wiki/AccountRequests/) > You will need a legacy SSH account. I requested an account here: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/162 This 404s for me. Did you set the issue to private by any chance? Or deleted already again? -Daniel Sorry, yes, I set it to private. I thought I had to :( -Paul > And you should familiarize yourself with the maintainer-tools: > https://drm.pages.freedesktop.org/maintainer-tools/index.html > > For my use I use "dim update-branches; dim apply; dim push > So only a small subset i needed for simple use. > > Sam -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: > Am 20.06.19 um 18:30 schrieb Emil Velikov: > > On 2019/06/14, Koenig, Christian wrote: > >> Am 14.06.19 um 17:53 schrieb Emil Velikov: > >>> On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 14:09 schrieb Emil Velikov: > > On 2019/05/27, Emil Velikov wrote: > > [SNIP] > > Hi Christian, > > > > > > In the following, I would like to summarise and emphasize the need for > > DRM_AUTH removal. I would kindly ask you to spend a couple of minutes > > extra reading it. > > > > > > Today DRM drivers* do not make any distinction between primary and > > render node clients. > That is actually not 100% correct. We have a special case where a DRM > master is allowed to change the priority of render node clients. > > >>> Can you provide a link? I cannot find that code. > >> See amdgpu_sched_ioctl(). > >> > > Thus for a render capable driver, any premise of > > separation, security or otherwise imposed via DRM_AUTH is a fallacy. > Yeah, that's what I agree on. I just don't think that removing DRM_AUTH > now is the right direction to take. > > >>> Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW > >>> ioctls. > >>> > >>> That aside, can you propose an alternative solution that addresses this > >>> and the second point just below? > >> Give me a few days to work on this, it's already Friday 6pm here. > >> > > Hi Christian, > > > > Any progress? As mentioned earlier, I'm OK with writing the patches although > > I would love to hear your plan. > > First of all I tried to disable DRM authentication completely with a > kernel config option. Surprisingly that actually works out of the box at > least on the AMDGPU stack. > > This effectively allows us to get rid of DRI2 and the related security > problems. Only thing left for that is that I'm just not sure how to > signal this to userspace so that the DDX wouldn't advertise DRI2 at all > any more. > > > As a next step I looked into if we can disable the command submission > for DRM master. Turned out that this is relatively easy as well. > > All we have to do is to fix the bug Michel pointed out about KMS handles > for display and let the DDX use a render node instead of the DRM master > for Glamor. Still need to sync up with Michel and/or Marek whats the > best way of doing this. > > > The last step (and that's what I haven't tried yet) would be to disable > DRM authentication for Navi even when it is still compiled into the > kernel. But that is more or less just a typing exercise. So just to get this straight, we're now full on embracing a subsystem split here: - amdgpu plans to ditch dri2/rendering on primary nodes - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH removal - others are just hanging in there somehow "best of both^W worlds" ftw? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs
On Fri, Jun 21, 2019 at 11:07:30AM +0200, Paul Cercueil wrote: > > > Le ven. 21 juin 2019 à 11:04, Daniel Vetter a écrit : > > On Thu, Jun 20, 2019 at 04:15:59PM +0200, Paul Cercueil wrote: > > > > > > > > > Le mer. 19 juin 2019 à 14:26, Sam Ravnborg a > > > écrit : > > > > Hi Paul. > > > > > > > > On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote: > > > > > Add a KMS driver for the Ingenic JZ47xx family of SoCs. > > > > > This driver is meant to replace the aging jz4740-fb driver. > > > > > > > > > > This driver does not make use of the simple pipe helper, for > > > the > > > > > reason > > > > > that it will soon be updated to support more advanced features > > > like > > > > > multiple planes, IPU integration for colorspace conversion and > > > > > up/down > > > > > scaling, support for DSI displays, and TV-out and HDMI outputs. > > > > > > > > > > Signed-off-by: Paul Cercueil > > > > > Tested-by: Artur Rojek > > > > > --- > > > > > > > > > > Notes: > > > > > v2: - Remove custom handling of panel. The panel is now > > > > > discovered using > > > > >the standard API. > > > > > - Lots of small tweaks suggested by upstream > > > > > > > > > > v3: - Use devm_drm_dev_init() > > > > > - Update compatible strings to -lcd instead of -drm > > > > > - Add destroy() callbacks to plane and crtc > > > > > - The ingenic,lcd-mode is now read from the bridge's DT > > > node > > > > > > > > > > v4: Remove ingenic,lcd-mode property completely. The > > > various > > > > > modes are now > > > > > deduced from the connector type, the pixel format or the > > > bus > > > > > flags. > > > > > > > > > > v5: - Fix framebuffer size incorrectly calculated for 24bpp > > > > > framebuffers > > > > > - Use 32bpp framebuffer instead of 16bpp, as it'll work > > > with > > > > > both > > > > >16-bit and 24-bit panel > > > > > - Get rid of drm_format_plane_cpp() which has been > > > dropped > > > > > upstream > > > > > - Avoid using drm_format_info->depth, which is > > > deprecated. > > > > In the drm world we include the revision notes in the changelog. > > > > So I did this when I applied it to drm-misc-next. > > > > > > > > Fixed a few trivial checkpatch warnings about indent too. > > > > There was a few too-long-lines warnings that I ignored. Fixing > > > them > > > > would have hurt readability. > > > > > > Thanks. > > > > > > > I assume you will maintain this driver onwards from now. > > > > Please request drm-misc commit rights (see > > > > https://www.freedesktop.org/wiki/AccountRequests/) > > > > You will need a legacy SSH account. > > > > > > I requested an account here: > > > https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/162 > > > > This 404s for me. Did you set the issue to private by any chance? Or > > deleted already again? > > -Daniel > > Sorry, yes, I set it to private. I thought I had to :( Well I can't ack it if its private, so please change that. Also, everything is public around here, or almost everything ... -Daniel > > -Paul > > > > > > > > > And you should familiarize yourself with the maintainer-tools: > > > > https://drm.pages.freedesktop.org/maintainer-tools/index.html > > > > > > > > For my use I use "dim update-branches; dim apply; dim push > > > > So only a small subset i needed for simple use. > > > > > > > >Sam > > > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/panel: Add attach/detach callbacks
On Tue, Jun 11, 2019 at 05:25:47PM -0700, dbasehore . wrote:
> On Tue, Jun 11, 2019 at 1:57 AM Daniel Vetter wrote:
> >
> > On Mon, Jun 10, 2019 at 09:03:48PM -0700, Derek Basehore wrote:
> > > This adds the attach/detach callbacks. These are for setting up
> > > internal state for the connector/panel pair that can't be done at
> > > probe (since the connector doesn't exist) and which don't need to be
> > > repeatedly done for every get/modes, prepare, or enable callback.
> > > Values such as the panel orientation, and display size can be filled
> > > in for the connector.
> > >
> > > Signed-off-by: Derek Basehore
> > > ---
> > > drivers/gpu/drm/drm_panel.c | 14 ++
> > > include/drm/drm_panel.h | 4
> > > 2 files changed, 18 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > > index 3b689ce4a51a..72f67678d9d5 100644
> > > --- a/drivers/gpu/drm/drm_panel.c
> > > +++ b/drivers/gpu/drm/drm_panel.c
> > > @@ -104,12 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> > > */
> > > int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> > > *connector)
> > > {
> > > + int ret;
> > > +
> > > if (panel->connector)
> > > return -EBUSY;
> > >
> > > panel->connector = connector;
> > > panel->drm = connector->dev;
> > >
> > > + if (panel->funcs->attach) {
> > > + ret = panel->funcs->attach(panel);
> > > + if (ret < 0) {
> > > + panel->connector = NULL;
> > > + panel->drm = NULL;
> > > + return ret;
> > > + }
> > > + }
> >
> > Why can't we just implement this in the drm helpers for everyone, by e.g.
> > storing a dt node in drm_panel? Feels a bit overkill to have these new
> > hooks here.
> >
> > Also, my understanding is that this dt stuff is supposed to be
> > standardized, so this should work.
>
> So do you want all of this information added to the drm_panel struct?
> If we do that, we don't necessarily even need the drm helper function.
> We could just copy the values over here in the drm_panel_attach
> function (and clear them in drm_panel_detach).
Yeah, I think we should have all this extra information in the struct
drm_panel. However, I think we need to more carefully split things such
that the DT parsing happens at panel probe time. That way we can catch
errors in DT, or missing entries/resources when we can still do
something about it.
If we start parsing DT and encounter failures, it's going to be very
confusing if that's at panel attach time where code will usually just
assume that everything is already validated and can't fail anymore.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
> held.
>
> On the importer side we add an optional invalidate callback. This callback is
> used by the exporter to inform the importers that their mappings should be
> destroyed as soon as possible.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> v2: don't try to invalidate mappings when the callback is NULL,
> lock the reservation obj while using the attachments,
> add helper to set the callback
> v3: move flag for invalidation support into the DMA-buf,
> use new attach_info structure to set the callback
> v4: use importer_priv field instead of mangling exporter priv.
> v5: drop invalidation_supported flag
> v6: squash together with pin/unpin changes
> v7: pin/unpin takes an attachment now
> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> everything is now handled backward compatible
> v9: always cache when export/importer don't agree on dynamic handling
> v10: minimal style cleanup
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-buf.c | 188 --
> include/linux/dma-buf.h | 109 --
> 2 files changed, 283 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 6c15deb5d4ad..9c9c95a88655 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -531,6 +531,9 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
>
> + if (WARN_ON(exp_info->ops->cache_sgt_mapping && exp_info->ops->pin))
> + return ERR_PTR(-EINVAL);
> +
> if (!try_module_get(exp_info->owner))
> return ERR_PTR(-ENOENT);
>
> @@ -651,10 +654,12 @@ void dma_buf_put(struct dma_buf *dmabuf)
> EXPORT_SYMBOL_GPL(dma_buf_put);
>
> /**
> - * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
> + * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
> optionally,
> * calls attach() of dma_buf_ops to allow device-specific attach
> functionality
> - * @dmabuf: [in]buffer to attach device to.
> - * @dev: [in]device to be attached.
> + * @dmabuf: [in]buffer to attach device to.
> + * @dev: [in]device to be attached.
> + * @importer_ops [in]importer operations for the attachment
> + * @importer_priv[in]importer private pointer for the attachment
> *
> * Returns struct dma_buf_attachment pointer for this attachment. Attachments
> * must be cleaned up by calling dma_buf_detach().
> @@ -668,8 +673,10 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> * accessible to @dev, and cannot be moved to a more suitable place. This is
> * indicated with the error code -EBUSY.
> */
> -struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
> - struct device *dev)
> +struct dma_buf_attachment *
> +dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
> +const struct dma_buf_attach_ops *importer_ops,
> +void *importer_priv)
> {
> struct dma_buf_attachment *attach;
> int ret;
> @@ -683,6 +690,8 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
> *dmabuf,
>
> attach->dev = dev;
> attach->dmabuf = dmabuf;
> + attach->importer_ops = importer_ops;
> + attach->importer_priv = importer_priv;
>
> mutex_lock(&dmabuf->lock);
>
> @@ -691,16 +700,72 @@ struct dma_buf_attachment *dma_buf_attach(struct
> dma_buf *dmabuf,
> if (ret)
> goto err_attach;
> }
> + reservation_object_lock(dmabuf->resv, NULL);
> list_add(&attach->node, &dmabuf->attachments);
> + reservation_object_unlock(dmabuf->resv);
>
> mutex_unlock(&dmabuf->lock);
>
> + /* When either the importer or the exporter can't handle dynamic
> + * mappings we cache the mapping here to avoid issues with the
> + * reservation object lock.
> + */
> + if (dma_buf_attachment_is_dynamic(attach) !=
> + dma_buf_is_dynamic(dmabuf)) {
> + struct sg_table *sgt;
> +
> + if (dma_buf_is_dynamic(attach->dmabuf)) {
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> + ret = dma_buf_pin(attach);
> + if (ret)
> + goto err_unlock;
> + }
> +
> + sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
> + if (!sgt)
> + sgt = ERR_PTR(-ENOMEM);
> + if (IS_ERR(sgt)) {
> +
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 11:09 schrieb Daniel Vetter: > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: >> Am 20.06.19 um 18:30 schrieb Emil Velikov: >>> On 2019/06/14, Koenig, Christian wrote: Am 14.06.19 um 17:53 schrieb Emil Velikov: > On 2019/06/14, Koenig, Christian wrote: >> Am 14.06.19 um 14:09 schrieb Emil Velikov: >>> On 2019/05/27, Emil Velikov wrote: >>> [SNIP] >>> Hi Christian, >>> >>> >>> In the following, I would like to summarise and emphasize the need for >>> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes >>> extra reading it. >>> >>> >>> Today DRM drivers* do not make any distinction between primary and >>> render node clients. >> That is actually not 100% correct. We have a special case where a DRM >> master is allowed to change the priority of render node clients. >> > Can you provide a link? I cannot find that code. See amdgpu_sched_ioctl(). >>> Thus for a render capable driver, any premise of >>> separation, security or otherwise imposed via DRM_AUTH is a fallacy. >> Yeah, that's what I agree on. I just don't think that removing DRM_AUTH >> now is the right direction to take. >> > Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW > ioctls. > > That aside, can you propose an alternative solution that addresses this > and the second point just below? Give me a few days to work on this, it's already Friday 6pm here. >>> Hi Christian, >>> >>> Any progress? As mentioned earlier, I'm OK with writing the patches although >>> I would love to hear your plan. >> First of all I tried to disable DRM authentication completely with a >> kernel config option. Surprisingly that actually works out of the box at >> least on the AMDGPU stack. >> >> This effectively allows us to get rid of DRI2 and the related security >> problems. Only thing left for that is that I'm just not sure how to >> signal this to userspace so that the DDX wouldn't advertise DRI2 at all >> any more. >> >> >> As a next step I looked into if we can disable the command submission >> for DRM master. Turned out that this is relatively easy as well. >> >> All we have to do is to fix the bug Michel pointed out about KMS handles >> for display and let the DDX use a render node instead of the DRM master >> for Glamor. Still need to sync up with Michel and/or Marek whats the >> best way of doing this. >> >> >> The last step (and that's what I haven't tried yet) would be to disable >> DRM authentication for Navi even when it is still compiled into the >> kernel. But that is more or less just a typing exercise. > So just to get this straight, we're now full on embracing a subsystem > split here: > - amdgpu plans to ditch dri2/rendering on primary nodes > - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH >removal > - others are just hanging in there somehow > > "best of both^W worlds" ftw? Yes, exactly! Think a step further, when this is upstream we can apply the DRM_AUTH removal to amdgpu as well. Because we simply made sure that userspace is using the render node for command submission and not the primary node. So nobody can go ahead and remove render node support any more :) Regards, Christian. > -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian wrote: > > Am 21.06.19 um 11:09 schrieb Daniel Vetter: > > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: > >> Am 20.06.19 um 18:30 schrieb Emil Velikov: > >>> On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 17:53 schrieb Emil Velikov: > > On 2019/06/14, Koenig, Christian wrote: > >> Am 14.06.19 um 14:09 schrieb Emil Velikov: > >>> On 2019/05/27, Emil Velikov wrote: > >>> [SNIP] > >>> Hi Christian, > >>> > >>> > >>> In the following, I would like to summarise and emphasize the need for > >>> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes > >>> extra reading it. > >>> > >>> > >>> Today DRM drivers* do not make any distinction between primary and > >>> render node clients. > >> That is actually not 100% correct. We have a special case where a DRM > >> master is allowed to change the priority of render node clients. > >> > > Can you provide a link? I cannot find that code. > See amdgpu_sched_ioctl(). > > >>> Thus for a render capable driver, any premise of > >>> separation, security or otherwise imposed via DRM_AUTH is a fallacy. > >> Yeah, that's what I agree on. I just don't think that removing DRM_AUTH > >> now is the right direction to take. > >> > > Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW > > ioctls. > > > > That aside, can you propose an alternative solution that addresses this > > and the second point just below? > Give me a few days to work on this, it's already Friday 6pm here. > > >>> Hi Christian, > >>> > >>> Any progress? As mentioned earlier, I'm OK with writing the patches > >>> although > >>> I would love to hear your plan. > >> First of all I tried to disable DRM authentication completely with a > >> kernel config option. Surprisingly that actually works out of the box at > >> least on the AMDGPU stack. > >> > >> This effectively allows us to get rid of DRI2 and the related security > >> problems. Only thing left for that is that I'm just not sure how to > >> signal this to userspace so that the DDX wouldn't advertise DRI2 at all > >> any more. > >> > >> > >> As a next step I looked into if we can disable the command submission > >> for DRM master. Turned out that this is relatively easy as well. > >> > >> All we have to do is to fix the bug Michel pointed out about KMS handles > >> for display and let the DDX use a render node instead of the DRM master > >> for Glamor. Still need to sync up with Michel and/or Marek whats the > >> best way of doing this. > >> > >> > >> The last step (and that's what I haven't tried yet) would be to disable > >> DRM authentication for Navi even when it is still compiled into the > >> kernel. But that is more or less just a typing exercise. > > So just to get this straight, we're now full on embracing a subsystem > > split here: > > - amdgpu plans to ditch dri2/rendering on primary nodes > > - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH > >removal > > - others are just hanging in there somehow > > > > "best of both^W worlds" ftw? > > Yes, exactly! > > Think a step further, when this is upstream we can apply the DRM_AUTH > removal to amdgpu as well. > > Because we simply made sure that userspace is using the render node for > command submission and not the primary node. > > So nobody can go ahead and remove render node support any more :) How does this work? I thought the entire problem of DRM_AUTH removal for you was that it broke stuff, and you didn't want to deal with that. We still have that exact problem afaics ... old userspace doesn't simply vanish, even if you entirely nuke it going forward. Also, testing on the amdgpu stack isn't really testing a hole lot here, it's all the various silly compositors out there I'd expect to fall over. Will gbm/radeonsi/whatever just internally do all the necessary dma-buf import/export between the primary node and display node to keep this all working? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] video: add HDMI state notifier support
On Fri, Jun 21, 2019 at 5:12 AM Daniel Vetter wrote: > > Massively cutting this thread, since halfway through in my previous reply > I realized that maybe hdmi_codec is a much better starting point. > ACK > On Thu, Jun 20, 2019 at 09:23:23PM +0800, Cheng-yi Chiang wrote: > > On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter wrote: > > > Yeah fully agreeing that hdmi_audio_code is probably a better starting > > > point. Problem is that becuase hdmi_codec is built on top of platform > > > device it's quite a bit harder to extend with callbacks and things like > > > that, without breaking the driver model. > > > > > > I need to think about this more, but if all we need to look at is > > > hdmi_codec, then I think this becomes a lot easier. And we can ignore > > > drm_audio_component.h completely. > > > > > > It is surprising that you think this way. > > Maybe the original patch before hdmi-notifier was introduced is the > > better way to solve this issue, if we only need to look at hdmi_codec. > > > > The history of hdmi_codec driver is in this patch series: > > > > https://lore.kernel.org/patchwork/patch/539656/ > > Hm, this doesn't seem to be the hdmi_codec driver I meant, but another, > new one. I was talking about SND_SOC_HDMI_CODEC. > Yes you are right. They are different codec drivers. Sorry for the confusion. What I meant was that my use case on RK3288 was using dw-hdmi-audio.c codec driver, which was later replaced by a more general version hdmi-codec.c. > > There was a callback mechanism implemented between dw-hdmi and hdmi > > codec driver. > > It was later consolidated by Doug in this patch for better jack status > > reporting: > > > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/ > > Hm that still seems entirely separate hdmi-codec specific to dw-hdmi only > ... > Again you are right. Sorry for the confusion. What I meant is that this callback mechanism should work on hdmi-codec.c driver as well. > > I am not sure why the original patch series did not get fully accepted > > in the upstream. > > It was quite long time ago. > > > > But if you think this might be the right way to do, then it is even > > better for us because the patch series and Doug's patch had been quite > > stable > > on our RK3288 products for about four years with plenty of users, so > > we have much higher confidence in them. > > I can rebase and clean up them and post another patch for review. > > > > Please let me know what approach you feel is better. > > Thanks again! > > Not sure we're talking about the same. What I had in mind is to add jack > status to the hdmi-codec.c stuff, which is used by multiple soc drm > display drivers already. Looking at git grep output, there seems to be > already some support for dw-hdmi synopsys drm_bridge driver. I thought of > extending that. Does that not work for you? > I think extending current interface will work. There is a struct hdmi_codec_pdata to let ALSA codec driver access some ops through platform data. And after this patch https://lore.kernel.org/patchwork/patch/692324/ ALSA codec driver can get access to the struct on DRM side. Based on this I can add a new ops to register callback function for jack status. It will be similar to Doug's chromium patch above. I think that is quite a feasible way, and can benefit all boards using hdmi-codec.c. Thanks a lot!! > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH -next] drm/sti: Remove duplicated include from sti_drv.c
Le jeu. 20 juin 2019 à 16:56, YueHaibing a écrit : > > Remove duplicated include. > > Signed-off-by: YueHaibing Applied on drm-misc-next, Thanks for the patch. Benjamin > --- > drivers/gpu/drm/sti/sti_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c > index bb6ae6dd66c9..2edd666fb44a 100644 > --- a/drivers/gpu/drm/sti/sti_drv.c > +++ b/drivers/gpu/drm/sti/sti_drv.c > @@ -23,7 +23,6 @@ > > #include "sti_crtc.h" > #include "sti_drv.h" > -#include "sti_drv.h" > #include "sti_plane.h" > > #define DRIVER_NAME"sti" > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] mali-dp and komeda patches for drm-next
On Fri, Jun 21, 2019 at 01:54:11PM +1000, Dave Airlie wrote:
> On Thu, 20 Jun 2019 at 20:35, Liviu Dudau wrote:
> >
> > Hi DRM maintainers,
> >
> > Picking up pace on the upstreaming of Komeda driver, with quite a lot
> > of new features added this time. On top of that we have the small
> > cleanups and improved usage of the debugfs functions. Please pull!
>
> It looks like you rebased this at the last moment, please don't do
> that, don't rebase just because you can.
Yes, sorry again, I was trying to be up-to-date with drm-next so as to figure
out if there are any conflicts before sending the pull request.
>
> The reason I noticed is because
> dim: 344f00e4d7d6 ("drm/komeda: Make Komeda interrupts shareable"):
> author Signed-off-by missing.
Huh, I've missed the fact that Ayan has updated his S-o-b line, I'll have a
chat with him to get his author updated as well.
> dim: 1885a6d946f5 ("drm/komeda: fix 32-bit
> komeda_crtc_update_clock_ratio"): SHA1 in fixes line not found:
> dim: a962091227ed ("drm/komeda: Add engine clock requirement check
> for the downscaling")
> dim: ERROR: issues in commits detected, aborting
>
> so clearly rebasing the fixed commit broke stuff, you should probably
> squash fixes if you are rebasing.
>
> Please resend with above fixed, and refrain from misc rebases in future.
They are now fixed, sorry about the noise.
Best regards,
Liviu
The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9:
Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200)
are available in the Git repository at:
git://linux-arm.org/linux-ld.git for-upstream/mali-dp
for you to fetch changes up to 2cfb1981dd0d9505b59868a7f7591746f51794b0:
drm/komeda: Make Komeda interrupts shareable (2019-06-21 10:47:15 +0100)
Arnd Bergmann (1):
drm/komeda: fix 32-bit komeda_crtc_update_clock_ratio
Ayan Halder (1):
drm/komeda: Make Komeda interrupts shareable
Greg Kroah-Hartman (2):
komeda: no need to check return value of debugfs_create functions
malidp: no need to check return value of debugfs_create functions
Liviu Dudau (1):
arm/komeda: Convert dp_wait_cond() to return an error code.
Lowry Li (Arm Technology China) (10):
drm/komeda: Creates plane alpha and blend mode properties
drm/komeda: Clear enable bit in CU_INPUTx_CONTROL
drm/komeda: Add rotation support on Komeda driver
drm/komeda: Adds limitation check for AFBC wide block not support Rot90
drm/komeda: Update HW up-sampling on D71
drm/komeda: Enable color-encoding (YUV format) support
drm/komeda: Adds SMMU support
dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree
drm/komeda: Adds zorder support
drm/komeda: Add slave pipeline support
james qian wang (Arm Technology China) (21):
drm/komeda: Add writeback support
drm/komeda: Added AFBC support for komeda driver
drm/komeda: Attach scaler to drm as private object
drm/komeda: Add the initial scaler support for CORE
drm/komeda: Implement D71 scaler support
drm/komeda: Add writeback scaling support
drm/komeda: Add engine clock requirement check for the downscaling
drm/komeda: Add image enhancement support
drm/komeda: Add komeda_fb_check_src_coords
drm/komeda: Add format support for Y0L2, P010, YUV420_8/10BIT
drm/komeda: Unify mclk/pclk/pipeline->aclk to one MCLK
drm/komeda: Rename main engine clk name "mclk" to "aclk"
dt/bindings: drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK
drm/komeda: Add component komeda_merger
drm/komeda: Add split support for scaler
drm/komeda: Add layer split support
drm/komeda: Refine function to_d71_input_id
drm/komeda: Accept null writeback configurations for writeback
drm/komeda: Add new component komeda_splitter
drm/komeda: Enable writeback split support
drm/komeda: Correct printk format specifier for "size_t"
.../devicetree/bindings/display/arm,komeda.txt | 23 +-
drivers/gpu/drm/arm/display/include/malidp_io.h| 7 +
drivers/gpu/drm/arm/display/include/malidp_utils.h | 5 +-
drivers/gpu/drm/arm/display/komeda/Makefile| 2 +
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 582 +-
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 142 +++--
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h | 2 +
.../gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 67 ++
.../gpu/drm/arm/display/komeda/komeda_color_mgmt.h | 17 +
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 154 -
drivers/gpu/drm/arm/display/komeda/komeda_dev.c| 59 +-
drivers/gpu/drm/arm/display/komeda/komeda_dev.h| 13 +-
.../drm/arm/display/komeda/komeda_format_caps.c| 58 ++
.../drm/arm/display/komeda/komeda_format_caps.h| 24 +-
.../drm/arm/display/komeda/komeda_framebuffer.c| 175 +-
.../drm/arm/dis
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 11:20 schrieb Daniel Vetter:
On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 188 --
include/linux/dma-buf.h | 109 --
2 files changed, 283 insertions(+), 14 deletions(-)
[SNIP]
+ if (dma_buf_attachment_is_dynamic(attach)) {
+ reservation_object_assert_held(attach->dmabuf->resv);
+
+ /*
+* Mapping a DMA-buf can trigger its invalidation, prevent
+* sending this event to the caller by temporary removing
+* this attachment from the list.
+*/
+ list_del(&attach->node);
I'm still hung up about this, that still feels like leaking random ttm
implementation details into the dma-buf interfaces. And it's asymmetric:
- When acquiring a buffer mapping (whether p2p or system memory sg or
whatever) we always have to wait for pending fences before we can access
the buffer. At least for full dynamic dma-buf access.
- Same is true when dropping a mapping: We could drop the mapping
immediately, but only actually release it when that fence has signalled.
Then this hack here wouldn't be necessary.
It feels a bit like this is just an artifact of how ttm currently does bo
moves with the shadow bo. There's other ways to fix that, you could just
have a memory manager reservation of a given range or whatever and a
release fence from when it's actually good to use.
No, that is for handling a completely different case :)
Imo the below semantics would be much cleaner:
- invalidate may add new fences
- invalidate _must_ unmap its mappings
- an unmap must wait for current fences before the mapping can be
released.
Imo there's no reason why unmap is special, and the only thing where we
don't use fences to gate access to resources/memory when it's in the
process of getting moved around.
Well in general I want to avoid waiting for fences as much as possible.
But the key point here is that this actually won't help with the problem
I'm trying to solve.
btw this is like the 2nd or 3rd time I'm typing this, haven't seen your
thoughts on this yet.
Yeah, and I'm responding for the 3rd time now that you are
misunderstanding why we need this here :)
Maybe I can make that clear with an example:
1. You got a sharing between device A (exporter) and B (importer) which
uses P2P.
2. Now device C (importer) comes along and wants to use the DMA-buf
object as well.
3. The handling now figures out that we can't do P2P between device A
and device C (for whatever reason).
4. The map_attachment implementation in device driver A doesn't want to
fail with -EBUSY and migrates the DMA-buf somewhere where both device A
and device C can access it.
5. This migration will result in sending an invalidation event around.
And here it doesn't make sense to send this invalidation event to device
C, because we know that device C is actually causing this event and
doesn't have a valid mapping.
One alternative would be to completely disallow buffer migration which
can cause invalidation in the drivers map_attachment call. But with
dynamic handling you definitely need to be able to migrate in the
map_attachment call for swapping evicted things back into a place where
they are accessible. So that would make it harder for drivers to get it
right.
Another alternative (and that's what I implemented initially) is to make
sure the driver calling map_attachment can handle invalidation events
re-entering itself while doing so. But then you add another tricky thing
for drivers to handle which could be done in the general code.
The reason I don't have that on unmap is that I think migrating things
on unmap
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 11:35 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian wrote: Am 21.06.19 um 11:09 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: Am 20.06.19 um 18:30 schrieb Emil Velikov: On 2019/06/14, Koenig, Christian wrote: Am 14.06.19 um 17:53 schrieb Emil Velikov: On 2019/06/14, Koenig, Christian wrote: Am 14.06.19 um 14:09 schrieb Emil Velikov: On 2019/05/27, Emil Velikov wrote: [SNIP] Hi Christian, In the following, I would like to summarise and emphasize the need for DRM_AUTH removal. I would kindly ask you to spend a couple of minutes extra reading it. Today DRM drivers* do not make any distinction between primary and render node clients. That is actually not 100% correct. We have a special case where a DRM master is allowed to change the priority of render node clients. Can you provide a link? I cannot find that code. See amdgpu_sched_ioctl(). Thus for a render capable driver, any premise of separation, security or otherwise imposed via DRM_AUTH is a fallacy. Yeah, that's what I agree on. I just don't think that removing DRM_AUTH now is the right direction to take. Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW ioctls. That aside, can you propose an alternative solution that addresses this and the second point just below? Give me a few days to work on this, it's already Friday 6pm here. Hi Christian, Any progress? As mentioned earlier, I'm OK with writing the patches although I would love to hear your plan. First of all I tried to disable DRM authentication completely with a kernel config option. Surprisingly that actually works out of the box at least on the AMDGPU stack. This effectively allows us to get rid of DRI2 and the related security problems. Only thing left for that is that I'm just not sure how to signal this to userspace so that the DDX wouldn't advertise DRI2 at all any more. As a next step I looked into if we can disable the command submission for DRM master. Turned out that this is relatively easy as well. All we have to do is to fix the bug Michel pointed out about KMS handles for display and let the DDX use a render node instead of the DRM master for Glamor. Still need to sync up with Michel and/or Marek whats the best way of doing this. The last step (and that's what I haven't tried yet) would be to disable DRM authentication for Navi even when it is still compiled into the kernel. But that is more or less just a typing exercise. So just to get this straight, we're now full on embracing a subsystem split here: - amdgpu plans to ditch dri2/rendering on primary nodes - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH removal - others are just hanging in there somehow "best of both^W worlds" ftw? Yes, exactly! Think a step further, when this is upstream we can apply the DRM_AUTH removal to amdgpu as well. Because we simply made sure that userspace is using the render node for command submission and not the primary node. So nobody can go ahead and remove render node support any more :) How does this work? I thought the entire problem of DRM_AUTH removal for you was that it broke stuff, and you didn't want to deal with that. Yeah, that is indeed still true. It's just that we have done way to many projects with radeon/amdgpu and customized userspace stuff. We still have that exact problem afaics ... old userspace doesn't simply vanish, even if you entirely nuke it going forward. Well old userspace doesn't work with new hardware either. So the idea is to keep old userspace for old hardware working, but only disable old stuff for new hardware. Also, testing on the amdgpu stack isn't really testing a hole lot here, it's all the various silly compositors out there I'd expect to fall over. Will gbm/radeonsi/whatever just internally do all the necessary dma-buf import/export between the primary node and display node to keep this all working? Yes, at least that's how I understand Michel's idea. We keep both file descriptors for primary and render node around at the same time anyway. So the change is actually not that much. This also solves the problem that people are running things as root, since we now always use the render node and never the primary node for everything except KMS. Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fourcc: Add Arm 16x16 block modifier
Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
denote the 16x16 block u-interleaved format used in Arm Utgard and
Midgard GPUs.
Signed-off-by: Raymond Smith
---
include/uapi/drm/drm_fourcc.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3..8ed7ecf 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -743,6 +743,16 @@ extern "C" {
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
/*
+ * Arm 16x16 Block U-Interleaved modifier
+ *
+ * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
+ * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
+ * in the block are reordered.
+ */
+#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
+ fourcc_mod_code(ARM, ((1ULL << 55) | 1))
+
+/*
* Allwinner tiled modifier
*
* This tiling mode is implemented by the VPU found on all Allwinner platforms,
--
2.7.4
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/21, Daniel Vetter wrote: > On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian > wrote: > > > > Am 21.06.19 um 11:09 schrieb Daniel Vetter: > > > On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: > > >> Am 20.06.19 um 18:30 schrieb Emil Velikov: > > >>> On 2019/06/14, Koenig, Christian wrote: > > Am 14.06.19 um 17:53 schrieb Emil Velikov: > > > On 2019/06/14, Koenig, Christian wrote: > > >> Am 14.06.19 um 14:09 schrieb Emil Velikov: > > >>> On 2019/05/27, Emil Velikov wrote: > > >>> [SNIP] > > >>> Hi Christian, > > >>> > > >>> > > >>> In the following, I would like to summarise and emphasize the need > > >>> for > > >>> DRM_AUTH removal. I would kindly ask you to spend a couple of > > >>> minutes > > >>> extra reading it. > > >>> > > >>> > > >>> Today DRM drivers* do not make any distinction between primary and > > >>> render node clients. > > >> That is actually not 100% correct. We have a special case where a DRM > > >> master is allowed to change the priority of render node clients. > > >> > > > Can you provide a link? I cannot find that code. > > See amdgpu_sched_ioctl(). > > > > >>> Thus for a render capable driver, any premise of > > >>> separation, security or otherwise imposed via DRM_AUTH is a fallacy. > > >> Yeah, that's what I agree on. I just don't think that removing > > >> DRM_AUTH > > >> now is the right direction to take. > > >> > > > Could have been clearer - I'm talking about DRM_AUTH | > > > DRM_RENDER_ALLOW > > > ioctls. > > > > > > That aside, can you propose an alternative solution that addresses > > > this > > > and the second point just below? > > Give me a few days to work on this, it's already Friday 6pm here. > > > > >>> Hi Christian, > > >>> > > >>> Any progress? As mentioned earlier, I'm OK with writing the patches > > >>> although > > >>> I would love to hear your plan. > > >> First of all I tried to disable DRM authentication completely with a > > >> kernel config option. Surprisingly that actually works out of the box at > > >> least on the AMDGPU stack. > > >> > > >> This effectively allows us to get rid of DRI2 and the related security > > >> problems. Only thing left for that is that I'm just not sure how to > > >> signal this to userspace so that the DDX wouldn't advertise DRI2 at all > > >> any more. > > >> > > >> > > >> As a next step I looked into if we can disable the command submission > > >> for DRM master. Turned out that this is relatively easy as well. > > >> > > >> All we have to do is to fix the bug Michel pointed out about KMS handles > > >> for display and let the DDX use a render node instead of the DRM master > > >> for Glamor. Still need to sync up with Michel and/or Marek whats the > > >> best way of doing this. > > >> > > >> > > >> The last step (and that's what I haven't tried yet) would be to disable > > >> DRM authentication for Navi even when it is still compiled into the > > >> kernel. But that is more or less just a typing exercise. > > > So just to get this straight, we're now full on embracing a subsystem > > > split here: > > > - amdgpu plans to ditch dri2/rendering on primary nodes > > > - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH > > >removal > > > - others are just hanging in there somehow > > > > > > "best of both^W worlds" ftw? > > > > Yes, exactly! > > > > Think a step further, when this is upstream we can apply the DRM_AUTH > > removal to amdgpu as well. > > So this is effectively what I suggested/planned with a couple of caveats: - making amdgpu behave differently from the rest of drm ;-( - having the KConfig amdgpu only and merged before this DRM_AUTH While I suggested: - keeping amdgpu consistent with the rest - exposing the KConfig option for the whole of the kernel, and - merging it alongside this work So I effectively waited for weeks, instead of simply going ahead and writing/submitting patches. That's a bit unfortunate... > > Because we simply made sure that userspace is using the render node for > > command submission and not the primary node. > > > > So nobody can go ahead and remove render node support any more :) > > How does this work? I thought the entire problem of DRM_AUTH removal > for you was that it broke stuff, and you didn't want to deal with > that. We still have that exact problem afaics ... old userspace > doesn't simply vanish, even if you entirely nuke it going forward. > > Also, testing on the amdgpu stack isn't really testing a hole lot > here, it's all the various silly compositors out there I'd expect to > fall over. Will gbm/radeonsi/whatever just internally do all the > necessary dma-buf import/export between the primary node and display > node to keep this all working? If I understood Christian, feel free to correct me, the fact that my earlier patch broke RADV was not the arg
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
On Fri, Jun 21, 2019 at 11:55 AM Christian König
wrote:
>
> Am 21.06.19 um 11:20 schrieb Daniel Vetter:
> > On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote:
> >> On the exporter side we add optional explicit pinning callbacks. If those
> >> callbacks are implemented the framework no longer caches sg tables and the
> >> map/unmap callbacks are always called with the lock of the reservation
> >> object
> >> held.
> >>
> >> On the importer side we add an optional invalidate callback. This callback
> >> is
> >> used by the exporter to inform the importers that their mappings should be
> >> destroyed as soon as possible.
> >>
> >> This allows the exporter to provide the mappings without the need to pin
> >> the backing store.
> >>
> >> v2: don't try to invalidate mappings when the callback is NULL,
> >> lock the reservation obj while using the attachments,
> >> add helper to set the callback
> >> v3: move flag for invalidation support into the DMA-buf,
> >> use new attach_info structure to set the callback
> >> v4: use importer_priv field instead of mangling exporter priv.
> >> v5: drop invalidation_supported flag
> >> v6: squash together with pin/unpin changes
> >> v7: pin/unpin takes an attachment now
> >> v8: nuke dma_buf_attachment_(map|unmap)_locked,
> >> everything is now handled backward compatible
> >> v9: always cache when export/importer don't agree on dynamic handling
> >> v10: minimal style cleanup
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/dma-buf/dma-buf.c | 188 --
> >> include/linux/dma-buf.h | 109 --
> >> 2 files changed, 283 insertions(+), 14 deletions(-)
> >>
> >> [SNIP]
> >> +if (dma_buf_attachment_is_dynamic(attach)) {
> >> +reservation_object_assert_held(attach->dmabuf->resv);
> >> +
> >> +/*
> >> + * Mapping a DMA-buf can trigger its invalidation, prevent
> >> + * sending this event to the caller by temporary removing
> >> + * this attachment from the list.
> >> + */
> >> +list_del(&attach->node);
> > I'm still hung up about this, that still feels like leaking random ttm
> > implementation details into the dma-buf interfaces. And it's asymmetric:
> >
> > - When acquiring a buffer mapping (whether p2p or system memory sg or
> >whatever) we always have to wait for pending fences before we can access
> >the buffer. At least for full dynamic dma-buf access.
> >
> > - Same is true when dropping a mapping: We could drop the mapping
> >immediately, but only actually release it when that fence has signalled.
> >Then this hack here wouldn't be necessary.
> >
> > It feels a bit like this is just an artifact of how ttm currently does bo
> > moves with the shadow bo. There's other ways to fix that, you could just
> > have a memory manager reservation of a given range or whatever and a
> > release fence from when it's actually good to use.
>
> No, that is for handling a completely different case :)
>
> >
> > Imo the below semantics would be much cleaner:
> >
> > - invalidate may add new fences
> > - invalidate _must_ unmap its mappings
> > - an unmap must wait for current fences before the mapping can be
> >released.
> >
> > Imo there's no reason why unmap is special, and the only thing where we
> > don't use fences to gate access to resources/memory when it's in the
> > process of getting moved around.
>
> Well in general I want to avoid waiting for fences as much as possible.
> But the key point here is that this actually won't help with the problem
> I'm trying to solve.
The point of using fences is not to wait on them. I mean if you have
the shadow ttm bo on the lru you also don't wait for that fence to
retire before you insert the shadow bo onto the lru. You don't even
wait when you try to use that memory again, you just pipeline more
stuff on top.
In the end it will be the exact same amount of fences and waiting in
both solutions. One just leaks less implementationt details (at least
in my opinion) across the dma-buf border.
> > btw this is like the 2nd or 3rd time I'm typing this, haven't seen your
> > thoughts on this yet.
>
> Yeah, and I'm responding for the 3rd time now that you are
> misunderstanding why we need this here :)
>
> Maybe I can make that clear with an example:
>
> 1. You got a sharing between device A (exporter) and B (importer) which
> uses P2P.
>
> 2. Now device C (importer) comes along and wants to use the DMA-buf
> object as well.
>
> 3. The handling now figures out that we can't do P2P between device A
> and device C (for whatever reason).
>
> 4. The map_attachment implementation in device driver A doesn't want to
> fail with -EBUSY and migrates the DMA-buf somewhere where both device A
> and device C can access it.
>
> 5. This migration will result in sending an invalidation event around.
> And here it doesn't make sense to send this invalida
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 12:20 schrieb Emil Velikov: > On 2019/06/21, Daniel Vetter wrote: >> On Fri, Jun 21, 2019 at 11:25 AM Koenig, Christian >> wrote: >>> Am 21.06.19 um 11:09 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 07:12:14AM +, Koenig, Christian wrote: > Am 20.06.19 um 18:30 schrieb Emil Velikov: >> On 2019/06/14, Koenig, Christian wrote: >>> Am 14.06.19 um 17:53 schrieb Emil Velikov: On 2019/06/14, Koenig, Christian wrote: > Am 14.06.19 um 14:09 schrieb Emil Velikov: >> On 2019/05/27, Emil Velikov wrote: >> [SNIP] >> Hi Christian, >> >> >> In the following, I would like to summarise and emphasize the need >> for >> DRM_AUTH removal. I would kindly ask you to spend a couple of minutes >> extra reading it. >> >> >> Today DRM drivers* do not make any distinction between primary and >> render node clients. > That is actually not 100% correct. We have a special case where a DRM > master is allowed to change the priority of render node clients. > Can you provide a link? I cannot find that code. >>> See amdgpu_sched_ioctl(). >>> >> Thus for a render capable driver, any premise of >> separation, security or otherwise imposed via DRM_AUTH is a fallacy. > Yeah, that's what I agree on. I just don't think that removing > DRM_AUTH > now is the right direction to take. > Could have been clearer - I'm talking about DRM_AUTH | DRM_RENDER_ALLOW ioctls. That aside, can you propose an alternative solution that addresses this and the second point just below? >>> Give me a few days to work on this, it's already Friday 6pm here. >>> >> Hi Christian, >> >> Any progress? As mentioned earlier, I'm OK with writing the patches >> although >> I would love to hear your plan. > First of all I tried to disable DRM authentication completely with a > kernel config option. Surprisingly that actually works out of the box at > least on the AMDGPU stack. > > This effectively allows us to get rid of DRI2 and the related security > problems. Only thing left for that is that I'm just not sure how to > signal this to userspace so that the DDX wouldn't advertise DRI2 at all > any more. > > > As a next step I looked into if we can disable the command submission > for DRM master. Turned out that this is relatively easy as well. > > All we have to do is to fix the bug Michel pointed out about KMS handles > for display and let the DDX use a render node instead of the DRM master > for Glamor. Still need to sync up with Michel and/or Marek whats the > best way of doing this. > > > The last step (and that's what I haven't tried yet) would be to disable > DRM authentication for Navi even when it is still compiled into the > kernel. But that is more or less just a typing exercise. So just to get this straight, we're now full on embracing a subsystem split here: - amdgpu plans to ditch dri2/rendering on primary nodes - bunch of drivers (I think more than i915 by now) merged the DRM_AUTH removal - others are just hanging in there somehow "best of both^W worlds" ftw? >>> Yes, exactly! >>> >>> Think a step further, when this is upstream we can apply the DRM_AUTH >>> removal to amdgpu as well. >>> > So this is effectively what I suggested/planned with a couple of caveats: > - making amdgpu behave differently from the rest of drm ;-( > - having the KConfig amdgpu only and merged before this DRM_AUTH No this should apply to all drivers, not just amdgpu. > While I suggested: > - keeping amdgpu consistent with the rest > - exposing the KConfig option for the whole of the kernel, and > - merging it alongside this work > > So I effectively waited for weeks, instead of simply going ahead and > writing/submitting patches. That's a bit unfortunate... > >>> Because we simply made sure that userspace is using the render node for >>> command submission and not the primary node. >>> >>> So nobody can go ahead and remove render node support any more :) >> How does this work? I thought the entire problem of DRM_AUTH removal >> for you was that it broke stuff, and you didn't want to deal with >> that. We still have that exact problem afaics ... old userspace >> doesn't simply vanish, even if you entirely nuke it going forward. >> >> Also, testing on the amdgpu stack isn't really testing a hole lot >> here, it's all the various silly compositors out there I'd expect to >> fall over. Will gbm/radeonsi/whatever just internally do all the >> necessary dma-buf import/export between the primary node and display >> node to keep this all working? > If I understood Christian, feel free to correct me, the fact that my > earlier patch broke
Re: [PATCH 09/59] drm/prime: Align gem_prime_export with obj_funcs.export
On Fri, Jun 14, 2019 at 10:35:25PM +0200, Daniel Vetter wrote:
> The idea is that gem_prime_export is deprecated in favor of
> obj_funcs.export. That's much easier to do if both have matching
> function signatures.
>
> Signed-off-by: Daniel Vetter
> Cc: Russell King
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tomi Valkeinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Dave Airlie
> Cc: Eric Anholt
> Cc: "Michel Dänzer"
> Cc: Chris Wilson
> Cc: Huang Rui
> Cc: Felix Kuehling
> Cc: Hawking Zhang
> Cc: Feifei Xu
> Cc: Jim Qu
> Cc: Evan Quan
> Cc: Matthew Auld
> Cc: Mika Kuoppala
> Cc: Thomas Zimmermann
> Cc: Kate Stewart
> Cc: Sumit Semwal
> Cc: Jilayne Lovejoy
> Cc: Thomas Gleixner
> Cc: Mikulas Patocka
> Cc: Greg Kroah-Hartman
> Cc: Junwei Zhang
> Cc: intel-gvt-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: amd-...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
Merged up to this one to drm-misc-next (for 5.4), thanks everyone for the
review and comments thus far.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 7 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 3 +--
> drivers/gpu/drm/armada/armada_gem.c | 5 ++---
> drivers/gpu/drm/armada/armada_gem.h | 3 +--
> drivers/gpu/drm/drm_prime.c | 9 -
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 5 ++---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 8
> drivers/gpu/drm/i915/gvt/dmabuf.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 3 +--
> drivers/gpu/drm/omapdrm/omap_gem.h | 3 +--
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c| 5 ++---
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +--
> drivers/gpu/drm/radeon/radeon_prime.c| 5 ++---
> drivers/gpu/drm/tegra/gem.c | 7 +++
> drivers/gpu/drm/tegra/gem.h | 3 +--
> drivers/gpu/drm/udl/udl_dmabuf.c | 5 ++---
> drivers/gpu/drm/udl/udl_drv.h| 3 +--
> drivers/gpu/drm/vc4/vc4_bo.c | 5 ++---
> drivers/gpu/drm/vc4/vc4_drv.h| 3 +--
> drivers/gpu/drm/vgem/vgem_fence.c| 2 +-
> include/drm/drm_drv.h| 4 ++--
> include/drm/drm_prime.h | 3 +--
> 22 files changed, 39 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 489041df1f45..4809d4a5d72a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -345,8 +345,7 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
> * Returns:
> * Shared DMA buffer representing the GEM BO from the given device.
> */
> -struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *gobj,
> +struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
> int flags)
> {
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
> @@ -356,9 +355,9 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device
> *dev,
> bo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
> return ERR_PTR(-EPERM);
>
> - buf = drm_gem_prime_export(dev, gobj, flags);
> + buf = drm_gem_prime_export(gobj, flags);
> if (!IS_ERR(buf)) {
> - buf->file->f_mapping = dev->anon_inode->i_mapping;
> + buf->file->f_mapping = gobj->dev->anon_inode->i_mapping;
> buf->ops = &amdgpu_dmabuf_ops;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> index c7056cbe8685..7f73a4f94204 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> @@ -30,8 +30,7 @@ struct drm_gem_object *
> amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
>struct dma_buf_attachment *attach,
>struct sg_table *sg);
> -struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
> - struct drm_gem_object *gobj,
> +struct dma_buf *amdgpu_gem_prime_export(struct drm_gem_object *gobj,
> int flags);
> struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
> struct dma_buf *dma_buf);
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/g
Re: [PATCH v7 0/6] Add support for Orange Pi 3
On Thu, Jun 20, 2019 at 03:47:42PM +0200, verejna wrote: > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > - ethernet support (patches 1-3) > - HDMI support (patches 4-6) > > For some people, ethernet doesn't work after reboot (but works on cold > boot), when the stmmac driver is built into the kernel. It works when > the driver is built as a module. It's either some timing issue, or power > supply issue or a combination of both. Module build induces a power > cycling of the phy. > > I encourage people with this issue, to build the driver into the kernel, > and try to alter the reset timings for the phy in DTS or > startup-delay-us and report the findings. Other theory to test is that the PHY requires two power supplies to be enabled at the same time, and during reboot one of them (one controlled via GPIO) may be turned off, and ALDO2 controlled by AXP805 may not. It should be possible to turn off ALDO2 in u-boot via CONFIG_AXP_ALDO2_VOLT=0 (You may need to enable CONFIG_AXP809_POWER and other options too, since it seems AXP805 support is not enabled for orange pi 3 in u-boot) regards, o. > > Please take a look. > > thank you and regards, > Ondrej Jirman > > > Changes in v7: > - dropped stored reference to connector_pdev as suggested by Jernej > - added forgotten dt-bindings reviewed-by tag > > Changes in v6: > - added dt-bindings reviewed-by tag > - fix wording in stmmac commit (as suggested by Sergei) > > Changes in v5: > - dropped already applied patches (pinctrl patches, mmc1 pinconf patch) > - rename GMAC-3V3 -> GMAC-3V to match the schematic (Jagan) > - changed hdmi-connector's ddc-supply property to ddc-en-gpios > (Rob Herring) > > Changes in v4: > - fix checkpatch warnings/style issues > - use enum in struct sunxi_desc_function for io_bias_cfg_variant > - collected acked-by's > - fix compile error in drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c:156 > caused by missing conversion from has_io_bias_cfg struct member > (I've kept the acked-by, because it's a trivial change, but feel free > to object.) (reported by Martin A. on github) > I did not have A80 pinctrl enabled for some reason, so I did not catch > this sooner. > - dropped brcm firmware patch (was already applied) > - dropped the wifi dts patch (will re-send after H6 RTC gets merged, > along with bluetooth support, in a separate series) > > Changes in v3: > - dropped already applied patches > - changed pinctrl I/O bias selection constants to enum and renamed > - added /omit-if-no-ref/ to mmc1_pins > - made mmc1_pins default pinconf for mmc1 in H6 dtsi > - move ddc-supply to HDMI connector node, updated patch descriptions, > changed dt-bindings docs > > Changes in v2: > - added dt-bindings documentation for the board's compatible string > (suggested by Clement) > - addressed checkpatch warnings and code formatting issues (on Maxime's > suggestions) > - stmmac: dropped useless parenthesis, reworded description of the patch > (suggested by Sergei) > - drop useles dev_info() about the selected io bias voltage > - docummented io voltage bias selection variant macros > - wifi: marked WiFi DTS patch and realted mmc1_pins as "DO NOT MERGE", > because wifi depends on H6 RTC support that's not merged yet (suggested > by Clement) > - added missing signed-of-bys > - changed &usb2otg dr_mode to otg, and added a note about VBUS > - improved wording of HDMI driver's DDC power supply patch > > Icenowy Zheng (2): > net: stmmac: sun8i: add support for Allwinner H6 EMAC > net: stmmac: sun8i: force select external PHY when no internal one > > Ondrej Jirman (4): > arm64: dts: allwinner: orange-pi-3: Enable ethernet > dt-bindings: display: hdmi-connector: Support DDC bus enable > drm: sun4i: Add support for enabling DDC I2C bus to sun8i_dw_hdmi glue > arm64: dts: allwinner: orange-pi-3: Enable HDMI output > > .../display/connector/hdmi-connector.txt | 1 + > .../dts/allwinner/sun50i-h6-orangepi-3.dts| 70 +++ > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 54 -- > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 + > .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 21 ++ > 5 files changed, 144 insertions(+), 4 deletions(-) > > -- > 2.22.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 1/1] drm/exynos: drop drmP.h usage
HI, 2019년 6월 8일 (토) 오후 5:35, Sam Ravnborg 님이 작성: > > Drop use of the deprecated drmP.h file. > Replace with forwards / externals as appropriate. > > While touching the list of include files divide > them up in blocks and sort them. > > Signed-off-by: Sam Ravnborg > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Cc: David Airlie > Cc: Daniel Vetter > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Jingoo Han > --- > drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++- > drivers/gpu/drm/exynos/exynos7_drm_decon.c| 8 ++-- > drivers/gpu/drm/exynos/exynos_dp.c| 13 +++--- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_dma.c | 6 ++- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 8 ++-- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 +++--- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 8 +++- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 21 +- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 6 +-- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ++-- > drivers/gpu/drm/exynos/exynos_drm_fimc.c | 15 +++ > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --- > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 8 ++-- > drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 ++-- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 +++--- > drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +- > drivers/gpu/drm/exynos/exynos_drm_mic.c | 22 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 10 ++--- > drivers/gpu/drm/exynos/exynos_drm_scaler.c| 12 +++--- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++-- > drivers/gpu/drm/exynos/exynos_hdmi.c | 41 +-- > drivers/gpu/drm/exynos/exynos_mixer.c | 31 +++--- > 24 files changed, 151 insertions(+), 136 deletions(-) > --- snip --- > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > index c20b3a759370..ff9342737a51 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > @@ -7,21 +7,21 @@ > * published by the Free Software Foundationr > */ > > -#include > #include > #include > +#include > #include > #include > #include > +#include > +#include > #include > #include > #include > #include > -#include > -#include > > -#include > #include > + With this patch, many build errors happen. Seems you missed to include below header files, Thanks, Inki Dae [Error log] -- drivers/gpu/drm/exynos/exynos_drm_g2d.c:196:27: error: field ‘base’ has incomplete type struct drm_pending_event base; ^~~~ drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_userptr_get_dma_addr’: drivers/gpu/drm/exynos/exynos_drm_g2d.c:421:50: error: dereferencing pointer to incomplete type ‘struct drm_file’ struct drm_exynos_file_private *file_priv = filp->driver_priv; ^~ drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_map_cmdlist_gem’: drivers/gpu/drm/exynos/exynos_drm_g2d.c:734:8: error: implicit declaration of function ‘copy_from_user’; did you mean ‘sg_copy_from_buffer’? [-Werror=implicit-function-declaration] if (copy_from_user(&g2d_userptr, (void __user *)handle, ^~ sg_copy_from_buffer drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_finish_event’: drivers/gpu/drm/exynos/exynos_drm_g2d.c:923:2: error: implicit declaration of function ‘drm_send_event’; did you mean ‘drm_eld_mnl’? [-Werror=implicit-function-declaration] drm_send_event(drm_dev, &e->base); ^~ drm_eld_mnl drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘g2d_wait_finish’: drivers/gpu/drm/exynos/exynos_drm_g2d.c:990:3: error: implicit declaration of function ‘mdelay’ [-Werror=implicit-function-declaration] mdelay(10); ^~ drivers/gpu/drm/exynos/exynos_drm_g2d.c: In function ‘exynos_g2d_set_cmdlist_ioctl’: drivers/gpu/drm/exynos/exynos_drm_g2d.c:1174:9: error: implicit declaration of function ‘drm_event_reserve_init’; did you mean ‘drm_mm_reserve_node’? [-Werror=implicit-function-declaration] ret = drm_event_reserve_init(drm_dev, file, &e->base, &e->event.base); ^~ drm_mm_reserve_node drivers/gpu/drm/exynos/exynos_drm_g2d.c:1285:3: error: implicit declaration of function ‘drm_event_cancel_free’; did you mean ‘drm_gem_object_free’? [-Werror=implicit-function-declaration] drm_event_cancel_free(drm_dev, &node->event->base); ^ dr
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/21, Koenig, Christian wrote: > No this should apply to all drivers, not just amdgpu. > > > While I suggested: > > - keeping amdgpu consistent with the rest > > - exposing the KConfig option for the whole of the kernel, and > > - merging it alongside this work > > > > So I effectively waited for weeks, instead of simply going ahead and > > writing/submitting patches. That's a bit unfortunate... > > > >>> Because we simply made sure that userspace is using the render node for > >>> command submission and not the primary node. > >>> > >>> So nobody can go ahead and remove render node support any more :) > >> How does this work? I thought the entire problem of DRM_AUTH removal > >> for you was that it broke stuff, and you didn't want to deal with > >> that. We still have that exact problem afaics ... old userspace > >> doesn't simply vanish, even if you entirely nuke it going forward. > >> > >> Also, testing on the amdgpu stack isn't really testing a hole lot > >> here, it's all the various silly compositors out there I'd expect to > >> fall over. Will gbm/radeonsi/whatever just internally do all the > >> necessary dma-buf import/export between the primary node and display > >> node to keep this all working? > > If I understood Christian, feel free to correct me, the fact that my > > earlier patch broke RADV was not the argument. The problem was was the > > patch does. > > Well partially. That RADV broke is unfortunate, but we have done so many > customized userspace stuff both based on Mesa/DDX as well as closed > source components that it is just highly likely that we would break > something else as well. > As an engineer I like to work with tangibles. The highly likely part is probable, but as mentioned multiple times the series allows for a _dead_ trivial way to address any such problems. > > In particular, that user-space will "remove" render nodes. > > Yes, that is my main concern here. You basically make render nodes > superfluously. That gives userspace all legitimization to also remove > support for them. That is not stupid or evil or whatever, userspace > would just follow the kernel design. > Do you have an example of userspace doing such an extremely silly thing? It does seem like suspect you're a couple of steps beyond overcautious, perhaps rightfully so. Maybe you've seen some closed-source user-space going crazy? Or any other projects? In other words, being cautious is great, but without references of misuse it's very hard for others to draw the full picture. > > I'm really sad that amdgpu insists on standing out, hope one day it will > > converge. Yet since all other maintainers are ok with the series, I'll > > start merging patches in a few hours. I'm really sad that amdgpu wants > > to stand out, hope it will converge sooner rather than later. > > > > Christian, how would you like amdgpu handled - with a separate flag in > > the driver or shall we special case amdgpu within core drm? > > No, I ask you to please stick around DRM_AUTH for at least amdgpu and > radeon. And NOT enable any render node functionality for them on the > primary node. > My question is how do you want this handled: - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or - driver_name == amdgpu, in core DRM. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: pvr2fb: fix link error for pvr2fb_pci_exit
Hi,
On 6/17/19 3:16 PM, Arnd Bergmann wrote:
> When the driver is built-in for PCI, we reference the exit function
> after discarding it:
>
> `pvr2fb_pci_exit' referenced in section `.ref.data' of
> drivers/video/fbdev/pvr2fb.o: defined in discarded section `.exit.text' of
> drivers/video/fbdev/pvr2fb.o
>
> Just remove the __exit annotation as the easiest workaround.
Don't we also need to fix pvr2fb_dc_exit() for CONFIG_SH_DREAMCAST=y case?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> Fixes: 0f5a5712ad1e ("video: fbdev: pvr2fb: add COMPILE_TEST support")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/video/fbdev/pvr2fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
> index 299ea7db9220..cf9cfdc5e685 100644
> --- a/drivers/video/fbdev/pvr2fb.c
> +++ b/drivers/video/fbdev/pvr2fb.c
> @@ -990,7 +990,7 @@ static int __init pvr2fb_pci_init(void)
> return pci_register_driver(&pvr2fb_pci_driver);
> }
>
> -static void __exit pvr2fb_pci_exit(void)
> +static void pvr2fb_pci_exit(void)
> {
> pci_unregister_driver(&pvr2fb_pci_driver);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian wrote: > Am 21.06.19 um 12:20 schrieb Emil Velikov: > > In particular, that user-space will "remove" render nodes. > > Yes, that is my main concern here. You basically make render nodes > superfluously. That gives userspace all legitimization to also remove > support for them. That is not stupid or evil or whatever, userspace > would just follow the kernel design. This already happened. At least for kms-only display socs we had to hide the separate render node (and there you really have to deal with the separate render node, because it's a distinct driver) entirely within gbm/mesa. So if you want to depracate render functionality on primary nodes, you _have_ to do that hiding in userspace. Or you'll break a lot of compositors everywhere. Just testing -amdgpu doesn't really prove anything here. So you won't move the larger ecosystem with this at all, that ship sailed. At that point this all feels like a bikeshed, and for a bikeshed I don't care what the color is we pick, as long as they're all painted the same. Once we picked a color it's a simple technical matter of how to roll it out, using Kconfig options, or only enabling on new hw, or "merge and fix the regressions as they come" or any of the other well proven paths forward. So if you want to do this, please start with the mesa side work (as the biggest userspace, not all of it) with patches to redirect all primary node rendering to render nodes. The code is there already for socs, just needs to be rolled out more. Or we go with the DRM_AUTH horrors. Or a 3rd option, I really don't care which it is, as long as its consistent. tldr; consistent color choice on this bikeshed please. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: pvr2fb: fix link error for pvr2fb_pci_exit
On Fri, Jun 21, 2019 at 12:58 PM Bartlomiej Zolnierkiewicz wrote: > > On 6/17/19 3:16 PM, Arnd Bergmann wrote: > > When the driver is built-in for PCI, we reference the exit function > > after discarding it: > > > > `pvr2fb_pci_exit' referenced in section `.ref.data' of > > drivers/video/fbdev/pvr2fb.o: defined in discarded section `.exit.text' of > > drivers/video/fbdev/pvr2fb.o > > > > Just remove the __exit annotation as the easiest workaround. > > Don't we also need to fix pvr2fb_dc_exit() for CONFIG_SH_DREAMCAST=y case? I think that's correct, yes. Can you fix that up when applying the patch? Arnd
Re: [PATCH v2 1/1] drm/exynos: drop drmP.h usage
Hi Inki. > --- snip --- > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > index c20b3a759370..ff9342737a51 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c > > @@ -7,21 +7,21 @@ > > * published by the Free Software Foundationr > > */ > > > > -#include > > #include > > #include > > +#include > > #include > > #include > > #include > > +#include > > +#include > > #include > > #include > > #include > > #include > > -#include > > -#include > > > > -#include > > #include > > + > > With this patch, many build errors happen. > > Seems you missed to include below header files, > > > Thanks for testing, glad this was catched before it hit drm-misc. I will try to reproduce and get back if I fails to do so. Smells like I failed to apply some local changes or something. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: pvr2fb: fix build warning when compiling as module
On 6/14/19 12:43 PM, Bartlomiej Zolnierkiewicz wrote:
> Add missing #ifndef MODULE around pvr2_get_param_val().
>
> Fixes: 0f5a5712ad1e ("video: fbdev: pvr2fb: add COMPILE_TEST support")
> Reported-by: Stephen Rothwell
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: imxfb: fix sparse warnings about using incorrect types
On 6/14/19 1:53 PM, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Reported-by: kbuild test robot
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Pengutronix Kernel Team
> Cc: Fabio Estevam
> Cc: Uwe Kleine-König
> Cc: NXP Linux Team
> Signed-off-by: Bartlomiej Zolnierkiewicz
I queued the patch for v5.3.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 12:53 schrieb Emil Velikov: > On 2019/06/21, Koenig, Christian wrote: >> [SNIP] >> Well partially. That RADV broke is unfortunate, but we have done so many >> customized userspace stuff both based on Mesa/DDX as well as closed >> source components that it is just highly likely that we would break >> something else as well. >> > As an engineer I like to work with tangibles. The highly likely part is > probable, but as mentioned multiple times the series allows for a _dead_ > trivial way to address any such problems. Well to clarify my concern is that this won't be so trivial. You implemented on workaround for one specific case and it is perfectly possible that for other cases we would have to completely revert the removal of DRM_AUTH. >>> In particular, that user-space will "remove" render nodes. >> Yes, that is my main concern here. You basically make render nodes >> superfluously. That gives userspace all legitimization to also remove >> support for them. That is not stupid or evil or whatever, userspace >> would just follow the kernel design. >> > Do you have an example of userspace doing such an extremely silly thing? > It does seem like suspect you're a couple of steps beyond overcautious, > perhaps rightfully so. Maybe you've seen some closed-source user-space > going crazy? Or any other projects? The key point is that I don't think this is silly or strange or crazy at all. See the kernel defines the interface userspace can and should use. When the kernel defines that everything will work with the primary node it is perfectly valid for userspace to drop support for the render node. I mean why should they keep this? Just because we tell them not to do this? > In other words, being cautious is great, but without references of > misuse it's very hard for others to draw the full picture. > >>> I'm really sad that amdgpu insists on standing out, hope one day it will >>> converge. Yet since all other maintainers are ok with the series, I'll >>> start merging patches in a few hours. I'm really sad that amdgpu wants >>> to stand out, hope it will converge sooner rather than later. >>> >>> Christian, how would you like amdgpu handled - with a separate flag in >>> the driver or shall we special case amdgpu within core drm? >> No, I ask you to please stick around DRM_AUTH for at least amdgpu and >> radeon. And NOT enable any render node functionality for them on the >> primary node. >> > My question is how do you want this handled: > - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or > - driver_name == amdgpu, in core DRM. I want to keep DRM_AUTH in amdgpu and radeon for at least the next 5-10 years. At least until we have established that nobody is using the primary node for command submission any more. Plus some grace time to make sure that this has been spread enough. Regards, Christian. > > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: s3c-fb: add COMPILE_TEST support
On 6/18/19 8:12 AM, Jingoo Han wrote: > On 6/14/19, 11:46 PM, Bartlomiej Zolnierkiewicz wrote: >> >> Add COMPILE_TEST support to s3c-fb driver for better compile >> testing coverage. >> >> Cc: Jingoo Han > Acked-by: Jingoo Han >> Signed-off-by: Bartlomiej Zolnierkiewicz Thanks, I queued the patch for v5.3. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Re: [PATCH] video: fbdev: pvr2fb: fix compile-testing as module
On 6/17/19 2:47 PM, Arnd Bergmann wrote:
> Building an allmodconfig kernel now produces a harmless warning:
>
> drivers/video/fbdev/pvr2fb.c:726:12: error: unused function
> 'pvr2_get_param_val' [-Werror,-Wunused-function]
>
> Shut this up the same way as we do for other unused functions
> in the same file, using the __maybe_unused attribute.
>
> Fixes: 0f5a5712ad1e ("video: fbdev: pvr2fb: add COMPILE_TEST support")
> Signed-off-by: Arnd Bergmann
Thanks but I've fixed it already by adding #ifndef MODULE (since other
functions in the same file using __maybe_unused depend on either PCI or
SH_DREAMCAST I've preferred not to use this attribute):
https://marc.info/?l=linux-fbdev&m=156050904010778&w=2
> ---
> drivers/video/fbdev/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
> index 59c59b3a67cb..cf9cfdc5e685 100644
> --- a/drivers/video/fbdev/pvr2fb.c
> +++ b/drivers/video/fbdev/pvr2fb.c
> @@ -723,8 +723,8 @@ static struct fb_ops pvr2fb_ops = {
> .fb_imageblit = cfb_imageblit,
> };
>
> -static int pvr2_get_param_val(const struct pvr2_params *p, const char *s,
> - int size)
> +static int __maybe_unused pvr2_get_param_val(const struct pvr2_params *p,
> + const char *s, int size)
> {
> int i;
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] mali-dp and komeda patches for drm-next
On Fri, Jun 21, 2019 at 11:53 AM Liviu Dudau wrote:
>
> On Fri, Jun 21, 2019 at 01:54:11PM +1000, Dave Airlie wrote:
> > On Thu, 20 Jun 2019 at 20:35, Liviu Dudau wrote:
> > >
> > > Hi DRM maintainers,
> > >
> > > Picking up pace on the upstreaming of Komeda driver, with quite a lot
> > > of new features added this time. On top of that we have the small
> > > cleanups and improved usage of the debugfs functions. Please pull!
> >
> > It looks like you rebased this at the last moment, please don't do
> > that, don't rebase just because you can.
>
> Yes, sorry again, I was trying to be up-to-date with drm-next so as to figure
> out if there are any conflicts before sending the pull request.
Testing for conflicts is good, but don't do that with a rebase. Instead.
1. create throw-away branch, starting at the commit you want to send a
pull request for
2. merge latest drm-next, look at conflicts, test in CI
3. once happy, send pull request, _unchanged_, with maybe a note about
any conflicts or how to resolve them.
Ime (and that's also why Linus insists on this) rebasing just breaks
patches too often, and then you might end up with an unbisectable
range for some reason. Yes merge commits also break sometimes, but
then we at least the chance to record why we thought the conflict
resolution was correct in a commit message, so there's some record
about what went wrong.
For drm-intel we do that automatically with the drm-tip integration tree.
-Daniel
> > The reason I noticed is because
> > dim: 344f00e4d7d6 ("drm/komeda: Make Komeda interrupts shareable"):
> > author Signed-off-by missing.
>
> Huh, I've missed the fact that Ayan has updated his S-o-b line, I'll have a
> chat with him to get his author updated as well.
>
> > dim: 1885a6d946f5 ("drm/komeda: fix 32-bit
> > komeda_crtc_update_clock_ratio"): SHA1 in fixes line not found:
> > dim: a962091227ed ("drm/komeda: Add engine clock requirement check
> > for the downscaling")
> > dim: ERROR: issues in commits detected, aborting
> >
> > so clearly rebasing the fixed commit broke stuff, you should probably
> > squash fixes if you are rebasing.
> >
> > Please resend with above fixed, and refrain from misc rebases in future.
>
> They are now fixed, sorry about the noise.
>
> Best regards,
> Liviu
>
>
> The following changes since commit 52d2d44eee8091e740d0d275df1311fb8373c9a9:
>
> Merge v5.2-rc5 into drm-next (2019-06-19 12:07:29 +0200)
>
> are available in the Git repository at:
>
> git://linux-arm.org/linux-ld.git for-upstream/mali-dp
>
> for you to fetch changes up to 2cfb1981dd0d9505b59868a7f7591746f51794b0:
>
> drm/komeda: Make Komeda interrupts shareable (2019-06-21 10:47:15 +0100)
>
>
> Arnd Bergmann (1):
> drm/komeda: fix 32-bit komeda_crtc_update_clock_ratio
>
> Ayan Halder (1):
> drm/komeda: Make Komeda interrupts shareable
>
> Greg Kroah-Hartman (2):
> komeda: no need to check return value of debugfs_create functions
> malidp: no need to check return value of debugfs_create functions
>
> Liviu Dudau (1):
> arm/komeda: Convert dp_wait_cond() to return an error code.
>
> Lowry Li (Arm Technology China) (10):
> drm/komeda: Creates plane alpha and blend mode properties
> drm/komeda: Clear enable bit in CU_INPUTx_CONTROL
> drm/komeda: Add rotation support on Komeda driver
> drm/komeda: Adds limitation check for AFBC wide block not support Rot90
> drm/komeda: Update HW up-sampling on D71
> drm/komeda: Enable color-encoding (YUV format) support
> drm/komeda: Adds SMMU support
> dt/bindings: drm/komeda: Adds SMMU support for D71 devicetree
> drm/komeda: Adds zorder support
> drm/komeda: Add slave pipeline support
>
> james qian wang (Arm Technology China) (21):
> drm/komeda: Add writeback support
> drm/komeda: Added AFBC support for komeda driver
> drm/komeda: Attach scaler to drm as private object
> drm/komeda: Add the initial scaler support for CORE
> drm/komeda: Implement D71 scaler support
> drm/komeda: Add writeback scaling support
> drm/komeda: Add engine clock requirement check for the downscaling
> drm/komeda: Add image enhancement support
> drm/komeda: Add komeda_fb_check_src_coords
> drm/komeda: Add format support for Y0L2, P010, YUV420_8/10BIT
> drm/komeda: Unify mclk/pclk/pipeline->aclk to one MCLK
> drm/komeda: Rename main engine clk name "mclk" to "aclk"
> dt/bindings: drm/komeda: Unify mclk/pclk/pipeline->aclk to one ACLK
> drm/komeda: Add component komeda_merger
> drm/komeda: Add split support for scaler
> drm/komeda: Add layer split support
> drm/komeda: Refine function to_d71_input_id
> drm/komeda: Accept null writeback configurations for writeback
> drm/komeda: Add new component komeda_splitter
> drm/komeda: Enable writeback split support
> drm/komeda: Cor
Re: [PATCH] video: fbdev: pvr2fb: fix link error for pvr2fb_pci_exit
On 6/21/19 1:05 PM, Arnd Bergmann wrote: > On Fri, Jun 21, 2019 at 12:58 PM Bartlomiej Zolnierkiewicz > wrote: >> >> On 6/17/19 3:16 PM, Arnd Bergmann wrote: >>> When the driver is built-in for PCI, we reference the exit function >>> after discarding it: >>> >>> `pvr2fb_pci_exit' referenced in section `.ref.data' of >>> drivers/video/fbdev/pvr2fb.o: defined in discarded section `.exit.text' of >>> drivers/video/fbdev/pvr2fb.o >>> >>> Just remove the __exit annotation as the easiest workaround. >> >> Don't we also need to fix pvr2fb_dc_exit() for CONFIG_SH_DREAMCAST=y case? > > I think that's correct, yes. Can you fix that up when applying the patch? Sure. I've queued the patch for v5.3, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 13:03 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian wrote: Am 21.06.19 um 12:20 schrieb Emil Velikov: In particular, that user-space will "remove" render nodes. Yes, that is my main concern here. You basically make render nodes superfluously. That gives userspace all legitimization to also remove support for them. That is not stupid or evil or whatever, userspace would just follow the kernel design. This already happened. At least for kms-only display socs we had to hide the separate render node (and there you really have to deal with the separate render node, because it's a distinct driver) entirely within gbm/mesa. Ok, that is something I didn't knew before and is rather interesting. So if you want to depracate render functionality on primary nodes, you _have_ to do that hiding in userspace. Or you'll break a lot of compositors everywhere. Just testing -amdgpu doesn't really prove anything here. So you won't move the larger ecosystem with this at all, that ship sailed. So what else can we do? That sounds like you suggest we should completely drop render node functionality. I mean it's not my preferred option, but certainly something that everybody could do. My primary concern is that we somehow need to get rid of thinks like GEM flink and all that other crufty stuff we still have around on the primary node (we should probably make a list of that). Switching everything over to render nodes just sounded like the best alternative so far to archive that. At that point this all feels like a bikeshed, and for a bikeshed I don't care what the color is we pick, as long as they're all painted the same. Once we picked a color it's a simple technical matter of how to roll it out, using Kconfig options, or only enabling on new hw, or "merge and fix the regressions as they come" or any of the other well proven paths forward. Yeah, the problem is I don't see an option which currently works for everyone. I absolutely need a grace time of multiple years until we can apply this to amdgpu/radeon. And that under the prerequisite to have a plan to somehow enable that functionality now to make it at least painful for userspace to rely on hack around that. So if you want to do this, please start with the mesa side work (as the biggest userspace, not all of it) with patches to redirect all primary node rendering to render nodes. The code is there already for socs, just needs to be rolled out more. Or we go with the DRM_AUTH horrors. Or a 3rd option, I really don't care which it is, as long as its consistent. How about this: 1. We keep DRM_AUTH around for amdgpu/radeon for now. 2. We add a Kconfig option to ignore DRM_AUTH, currently default to N. This also works as a workaround for old RADV. 3. We start to work on further removing old cruft from the primary node. Possible the Kconfig option I suggested to disable GEM flink. Regards, Christian. tldr; consistent color choice on this bikeshed please. Thanks, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] efifb: BGRT: Add check for new BGRT status field rotation bits
On 6/11/19 4:24 PM, Hans de Goede wrote:
> Hi,
>
> On 11-06-19 16:04, Ard Biesheuvel wrote:
>> On Mon, 10 Jun 2019 at 17:12, Ard Biesheuvel
>> wrote:
>>>
>>> On Wed, 29 May 2019 at 17:46, Hans de Goede wrote:
Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer
reserved. These bits are now used to indicate if the image needs to be
rotated before being displayed.
The efifb code does not support rotating the image before copying it to
the screen.
This commit adds a check for these new bits and if they are set leaves the
fb contents as is instead of trying to use the un-rotated BGRT image.
Signed-off-by: Hans de Goede
>>>
>>> Acked-by: Ard Biesheuvel
>>>
>>
>> BTW should we make sure that this patch and the efi-bgrt patch get
>> merged at the same time?
>
> The 2 patches are related but merging them at the same time is not
> necessary.
>
>> I guess the net result is just that we get
>> rid of some error in the log, but a rotated BMP will be ignored
>> otherwise.
>
> Right, worse case (if the bmp fits pre-rotation) it will be displayed
> rotated. Note on the one machine I'm aware of which uses these bits
> the bmp does not fit pre-rotation, so we end up triggering:
>
> error:
> memunmap(bgrt_image);
> pr_warn("efifb: Ignoring BGRT: unexpected or invalid BMP data\n");
> }
>
> Which this patch replaces with hitting:
>
> if (bgrt_tab.status & 0x06) {
> pr_info("efifb: BGRT rotation bits set, not showing boot
> graphics\n");
> return;
> }
>
> Instead. So at least on the one machine I know of this is 99% cosmetic.
>
>> Or is it relevant for userland in some other way?
>
> No.
>
> Regards,
>
> Hans
Patch queued for v5.3, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Fixes tags need some work in the drm-fixes tree
Hi all,
In commit
912bbf7e9ca4 ("gpu: ipu-v3: image-convert: Fix image downsize coefficients")
Fixes tag
Fixes: 70b9b6b3bcb21 ("gpu: ipu-v3: image-convert: calculate per-tile
has these problem(s):
- Please don't split Fixes tags across more than one line
In commit
bca4d70cf1b8 ("gpu: ipu-v3: image-convert: Fix input bytesperline for packed
formats")
Fixes tag
Fixes: d966e23d61a2c ("gpu: ipu-v3: image-convert: fix bytesperline
has these problem(s):
- Please don't split Fixes tags across more than one line
In commit
ff391ecd65a1 ("gpu: ipu-v3: image-convert: Fix input bytesperline
width/height align")
Fixes tag
Fixes: d966e23d61a2c ("gpu: ipu-v3: image-convert: fix bytesperline
has these problem(s):
- Please don't split Fixes tags across more than one line
--
Cheers,
Stephen Rothwell
pgplhG14MPP_7.pgp
Description: OpenPGP digital signature
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On Fri, Jun 21, 2019 at 1:37 PM Christian König wrote: > > Am 21.06.19 um 13:03 schrieb Daniel Vetter: > > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian > > wrote: > >> Am 21.06.19 um 12:20 schrieb Emil Velikov: > >>> In particular, that user-space will "remove" render nodes. > >> Yes, that is my main concern here. You basically make render nodes > >> superfluously. That gives userspace all legitimization to also remove > >> support for them. That is not stupid or evil or whatever, userspace > >> would just follow the kernel design. > > This already happened. At least for kms-only display socs we had to > > hide the separate render node (and there you really have to deal with > > the separate render node, because it's a distinct driver) entirely > > within gbm/mesa. > > Ok, that is something I didn't knew before and is rather interesting. > > > So if you want to depracate render functionality on primary nodes, you > > _have_ to do that hiding in userspace. Or you'll break a lot of > > compositors everywhere. Just testing -amdgpu doesn't really prove > > anything here. So you won't move the larger ecosystem with this at > > all, that ship sailed. > > So what else can we do? That sounds like you suggest we should > completely drop render node functionality. > > I mean it's not my preferred option, but certainly something that > everybody could do. > > My primary concern is that we somehow need to get rid of thinks like GEM > flink and all that other crufty stuff we still have around on the > primary node (we should probably make a list of that). > > Switching everything over to render nodes just sounded like the best > alternative so far to archive that. tbh I do like that plan too, but it's a lot more work. And I think to have any push whatsoever we probably need to roll it out in gbm as a hack to keep things going. But probably not enough. I also think that at least some compositors will bother to do the right thing, and actually bother with render nodes and all that correctly. It's just that there's way more which dont. Also for server rendering it'll be render nodes all the way down I hope (or we need to seriously educate cloud people about the permissions they set on their default images, and distros on how this cloud stuff should work. > > At that point this all feels like a bikeshed, and for a bikeshed I > > don't care what the color is we pick, as long as they're all painted > > the same. > > > > Once we picked a color it's a simple technical matter of how to roll > > it out, using Kconfig options, or only enabling on new hw, or "merge > > and fix the regressions as they come" or any of the other well proven > > paths forward. > > Yeah, the problem is I don't see an option which currently works for > everyone. > > I absolutely need a grace time of multiple years until we can apply this > to amdgpu/radeon. Yeah that's what I meant with "pick a color, pick a way to roll it out". "enable for new hw, roll out years and years later" is one of the options for roll out. > And that under the prerequisite to have a plan to somehow enable that > functionality now to make it at least painful for userspace to rely on > hack around that. > > > So if you want to do this, please start with the mesa side work (as > > the biggest userspace, not all of it) with patches to redirect all > > primary node rendering to render nodes. The code is there already for > > socs, just needs to be rolled out more. Or we go with the DRM_AUTH > > horrors. Or a 3rd option, I really don't care which it is, as long as > > its consistent. > > How about this: > 1. We keep DRM_AUTH around for amdgpu/radeon for now. > 2. We add a Kconfig option to ignore DRM_AUTH, currently default to N. > This also works as a workaround for old RADV. > 3. We start to work on further removing old cruft from the primary node. > Possible the Kconfig option I suggested to disable GEM flink. Hm I'm not worried about flink really. It's gem_open which is the security gap, and that one has to stay master-only forever. I guess we could try to disable that so people have to deal with dma-buf (and once you have that render nodes become a lot easier to use). But then I still think we have drivers which don't do dma-buf self-import, so again we're stuck. So maybe first step is to just roll out a default self-import dma-buf support for every gem driver. Then start ditching flink/gem_open. Then start ditching render support on primary nodes. Every step in the way taking a few years of prodding userspace plus even more years to wait until it's all gone. Another option would be to extract the kms stuff from primary nodes, but we've tried that with control nodes. Until I realized a few years back that with control nodes it's impossible to get any rendered buffer in there at all, so useless, and I removed it. No one ever complained. So yeah would be really nice if we could fix this, but the universe conspires against us too much it seems. Hence the fallback o
Re: [PATCH v2] video: fbdev: Fix Warning comparing pointer to 0 reported by coccicheck
On 6/3/19 1:57 PM, Mathieu Malaterre wrote: > On Mon, Jun 3, 2019 at 1:21 PM wrote: >> >> From: Shobhit Kukreti >> >> Fixed Warning Comparing Pointer to 0. Changed return value to -ENOMEM to >> report kzalloc failure >> >> drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 >> drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 >> drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 >> >> Signed-off-by: Shobhit Kukreti >> --- >> Changes in v2: >> - Modified commit message to report change in return type >> >> drivers/video/fbdev/controlfb.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/video/fbdev/controlfb.c >> b/drivers/video/fbdev/controlfb.c >> index 7af8db2..07907c5 100644 >> --- a/drivers/video/fbdev/controlfb.c >> +++ b/drivers/video/fbdev/controlfb.c >> @@ -182,7 +182,7 @@ int init_module(void) >> int ret = -ENXIO; >> >> dp = of_find_node_by_name(NULL, "control"); >> - if (dp != 0 && !control_of_init(dp)) >> + if (dp != NULL && !control_of_init(dp)) >> ret = 0; >> of_node_put(dp); >> >> @@ -580,7 +580,7 @@ static int __init control_init(void) >> control_setup(option); >> >> dp = of_find_node_by_name(NULL, "control"); >> - if (dp != 0 && !control_of_init(dp)) >> + if (dp != NULL && !control_of_init(dp)) >> ret = 0; >> of_node_put(dp); >> >> @@ -683,8 +683,8 @@ static int __init control_of_init(struct device_node *dp) >> return -ENXIO; >> } >> p = kzalloc(sizeof(*p), GFP_KERNEL); >> - if (p == 0) >> - return -ENXIO; >> + if (p == NULL) > > nit: I would have use `!p` (same for the others above). Maybe > checkpatch with --strict would warn for those (can't remember from top > of my head). > > Anyway: > > Reviewed-by: Mathieu Malaterre > >> + return -ENOMEM; >> control_fb = p; /* save it for cleanups */ >> >> /* Map in frame buffer and registers */ Patch queued (with some fixups, please see below) for v5.3, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics From: Shobhit Kukreti Subject: [PATCH] video: fbdev: controlfb: fix warnings about comparing pointer to 0 Fix warnings aboout comparing pointer to 0 reported by coccicheck: drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 drivers/video/fbdev/controlfb.c: WARNING comparing pointer to 0 Also while at it change return value to -ENOMEM on kzalloc() failure. Signed-off-by: Shobhit Kukreti Reviewed-by: Mathieu Malaterre [b.zolnierkie: minor fixups] Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/controlfb.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: b/drivers/video/fbdev/controlfb.c === --- a/drivers/video/fbdev/controlfb.c +++ b/drivers/video/fbdev/controlfb.c @@ -182,7 +182,7 @@ int init_module(void) int ret = -ENXIO; dp = of_find_node_by_name(NULL, "control"); - if (dp != 0 && !control_of_init(dp)) + if (dp && !control_of_init(dp)) ret = 0; of_node_put(dp); @@ -580,7 +580,7 @@ static int __init control_init(void) control_setup(option); dp = of_find_node_by_name(NULL, "control"); - if (dp != 0 && !control_of_init(dp)) + if (dp && !control_of_init(dp)) ret = 0; of_node_put(dp); @@ -683,8 +683,8 @@ static int __init control_of_init(struct return -ENXIO; } p = kzalloc(sizeof(*p), GFP_KERNEL); - if (p == 0) - return -ENXIO; + if (!p) + return -ENOMEM; control_fb = p; /* save it for cleanups */ /* Map in frame buffer and registers */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/18] drm/ttm: add gem base object
Add drm_gem_object struct to ttm_buffer_object, so ttm objects are a gdm
object superclass. Add a function to check whenever a given bo actually
uses the embedded drm_gem_object, for the transition period.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 49d9cdfc58f2..72f6aeda619c 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -31,6 +31,7 @@
#ifndef _TTM_BO_API_H_
#define _TTM_BO_API_H_
+#include
#include
#include
#include
@@ -127,6 +128,7 @@ struct ttm_tt;
/**
* struct ttm_buffer_object
*
+ * @base: drm_gem_object superclass data.
* @bdev: Pointer to the buffer object device structure.
* @type: The bo type.
* @destroy: Destruction function. If NULL, kfree is used.
@@ -169,6 +171,8 @@ struct ttm_tt;
*/
struct ttm_buffer_object {
+ struct drm_gem_object base;
+
/**
* Members constant at init.
*/
@@ -768,4 +772,18 @@ int ttm_bo_swapout(struct ttm_bo_global *glob,
struct ttm_operation_ctx *ctx);
void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
+
+/**
+ * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
+ * embedded drm_gem_object.
+ *
+ * Helper for the transition period, once all drivers are switched to
+ * use the embedded drm_gem_object this can go away.
+ *
+ * @bo: The bo to check.
+ */
+static inline bool ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object
*bo)
+{
+ return bo->base.dev != NULL;
+}
#endif
--
2.18.1
[PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass
v2: - build fixes. - also drop ttm_buffer_object->resv Gerd Hoffmann (18): drm/ttm: add gem base object drm/vram: use embedded gem object drm/qxl: use embedded gem object drm/radeon: use embedded gem object drm/amdgpu: use embedded gem object drm/nouveau: use embedded gem object drm/ttm: use gem reservation object drm/ttm: use gem vma_node drm/vram: drop drm_gem_vram_driver_gem_prime_mmap drm/ttm: set both resv and base.resv pointers drm/ttm: switch ttm core from bo->resv to bo->base.resv drm/radeon: switch driver from bo->resv to bo->base.resv drm/vmwgfx: switch driver from bo->resv to bo->base.resv drm/amdgpu: switch driver from bo->resv to bo->base.resv drm/nouveau: switch driver from bo->resv to bo->base.resv drm/qxl: switch driver from bo->resv to bo->base.resv drm/virtio: switch driver from bo->resv to bo->base.resv drm/ttm: drop ttm_buffer_object->resv drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 3 +- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 - drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 6 +- drivers/gpu/drm/qxl/qxl_object.h | 6 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_object.h| 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- include/drm/drm_gem_vram_helper.h | 7 +- include/drm/ttm/ttm_bo_api.h | 25 +++- include/drm/ttm/ttm_bo_driver.h | 12 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 28 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 30 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- drivers/gpu/drm/ast/ast_main.c| 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 36 ++--- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +- drivers/gpu/drm/mgag200/mgag200_main.c| 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +- drivers/gpu/drm/nouveau/nouveau_display.c | 10 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 19 +-- drivers/gpu/drm/nouveau/nouveau_prime.c | 6 +- drivers/gpu/drm/qxl/qxl_cmd.c | 4 +- drivers/gpu/drm/qxl/qxl_debugfs.c | 4 +- drivers/gpu/drm/qxl/qxl_display.c | 8 +- drivers/gpu/drm/qxl/qxl_gem.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 20 +-- drivers/gpu/drm/qxl/qxl_release.c | 8 +- drivers/gpu/drm/qxl/qxl_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- drivers/gpu/drm/radeon/radeon_cs.c| 4 +- drivers/gpu/drm/radeon/radeon_display.c | 6 +- drivers/gpu/drm/radeon/radeon_gem.c | 8 +- drivers/gpu/drm/radeon/radeon_mn.c| 2 +- drivers/gpu/drm/radeon/radeon_object.c| 22 +-- drivers/gpu/drm/radeon/radeon_prime.c | 4 +- drivers/gpu/drm/radeon/radeon_test.c | 8 +- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c| 6 +- drivers/gpu/drm/ttm/ttm_bo.c | 136 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-- drivers/gpu/drm/ttm/ttm_bo_vm.c | 15 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c| 20 +-- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_main.c | 2 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c| 4 +- drivers/gpu/drm/virtio/virtgpu_plane.c| 2 +- drivers/gpu/drm/virtio/virtgpu_prime.c| 3 - drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 +- 68 files changed, 311 insertions(+), 321 deletions(-) -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/18] drm/radeon: use embedded gem object
Drop drm_gem_object from radeon_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon.h | 3 +--
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 4 ++--
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 14 +++---
drivers/gpu/drm/radeon/radeon_prime.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
7 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 32808e50be12..3f7701321d21 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -505,7 +505,6 @@ struct radeon_bo {
struct list_headva;
/* Constant after initialization */
struct radeon_device*rdev;
- struct drm_gem_object gem_base;
struct ttm_bo_kmap_obj dma_buf_vmap;
pid_t pid;
@@ -513,7 +512,7 @@ struct radeon_bo {
struct radeon_mn*mn;
struct list_headmn_list;
};
-#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base)
+#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, tbo.base)
int radeon_gem_debugfs_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index cef0e697a2ea..d206654b31ad 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -443,7 +443,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
if (bo == NULL)
continue;
- drm_gem_object_put_unlocked(&bo->gem_base);
+ drm_gem_object_put_unlocked(&bo->tbo.base);
}
}
kfree(parser->track);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index bd52f15e6330..ea6b752dd3a4 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -275,7 +275,7 @@ static void radeon_unpin_work_func(struct work_struct
*__work)
} else
DRM_ERROR("failed to reserve buffer after flip\n");
- drm_gem_object_put_unlocked(&work->old_rbo->gem_base);
+ drm_gem_object_put_unlocked(&work->old_rbo->tbo.base);
kfree(work);
}
@@ -607,7 +607,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc
*crtc,
radeon_bo_unreserve(new_rbo);
cleanup:
- drm_gem_object_put_unlocked(&work->old_rbo->gem_base);
+ drm_gem_object_put_unlocked(&work->old_rbo->tbo.base);
dma_fence_put(work->fence);
kfree(work);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d8bc5d2dfd61..7238007f5aa4 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -83,7 +83,7 @@ int radeon_gem_object_create(struct radeon_device *rdev,
unsigned long size,
}
return r;
}
- *obj = &robj->gem_base;
+ *obj = &robj->tbo.base;
robj->pid = task_pid_nr(current);
mutex_lock(&rdev->gem.mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 21f73fc86f38..d96c2cb7d584 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -85,9 +85,9 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object
*tbo)
mutex_unlock(&bo->rdev->gem.mutex);
radeon_bo_clear_surface_reg(bo);
WARN_ON_ONCE(!list_empty(&bo->va));
- if (bo->gem_base.import_attach)
- drm_prime_gem_destroy(&bo->gem_base, bo->tbo.sg);
- drm_gem_object_release(&bo->gem_base);
+ if (bo->tbo.base.import_attach)
+ drm_prime_gem_destroy(&bo->tbo.base, bo->tbo.sg);
+ drm_gem_object_release(&bo->tbo.base);
kfree(bo);
}
@@ -209,7 +209,7 @@ int radeon_bo_create(struct radeon_device *rdev,
bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
- drm_gem_private_object_init(rdev->ddev, &bo->gem_base, size);
+ drm_gem_private_object_init(rdev->ddev, &bo->tbo.base, size);
bo->rdev = rdev;
bo->surface_reg = -1;
INIT_LIST_HEAD(&bo->list);
@@ -442,13 +442,13 @@ void radeon_bo_force_delete(struct radeon_device *rdev)
dev_err(rdev->dev, "Userspace still has active objects !\n");
list_for_each_entry_safe(bo, n, &rdev->gem.objects, list) {
dev_err(rdev->dev, "%p %p %lu %lu force free\n",
- &bo->gem_base, bo, (unsigned long)bo->gem_base.size,
- *((unsigned long *)&bo->gem_base
[PATCH v2 03/18] drm/qxl: use embedded gem object
Drop drm_gem_object from qxl_bo, use the
ttm_buffer_object.base instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h | 6 +++---
drivers/gpu/drm/qxl/qxl_object.h | 4 ++--
drivers/gpu/drm/qxl/qxl_cmd.c | 4 ++--
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 8
drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 20 ++--
drivers/gpu/drm/qxl/qxl_release.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 4 ++--
9 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 2896bb6fdbf4..b80d4a4361cd 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -72,12 +72,13 @@ extern int qxl_max_ioctls;
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG)
struct qxl_bo {
+ struct ttm_buffer_objecttbo;
+
/* Protected by gem.mutex */
struct list_headlist;
/* Protected by tbo.reserved */
struct ttm_placeplacements[3];
struct ttm_placementplacement;
- struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
unsigned int pin_count;
void*kptr;
@@ -85,7 +86,6 @@ struct qxl_bo {
int type;
/* Constant after initialization */
- struct drm_gem_object gem_base;
unsigned int is_primary:1; /* is this now a primary surface */
unsigned int is_dumb:1;
struct qxl_bo *shadow;
@@ -94,7 +94,7 @@ struct qxl_bo {
uint32_t surface_id;
struct qxl_release *surf_create;
};
-#define gem_to_qxl_bo(gobj) container_of((gobj), struct qxl_bo, gem_base)
+#define gem_to_qxl_bo(gobj) container_of((gobj), struct qxl_bo, tbo.base)
#define to_qxl_bo(tobj) container_of((tobj), struct qxl_bo, tbo)
struct qxl_gem {
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index 255b914e2a7b..b812d4ae9d0d 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -34,7 +34,7 @@ static inline int qxl_bo_reserve(struct qxl_bo *bo, bool
no_wait)
r = ttm_bo_reserve(&bo->tbo, true, no_wait, NULL);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS) {
- struct drm_device *ddev = bo->gem_base.dev;
+ struct drm_device *ddev = bo->tbo.base.dev;
dev_err(ddev->dev, "%p reserve failed\n", bo);
}
@@ -71,7 +71,7 @@ static inline int qxl_bo_wait(struct qxl_bo *bo, u32
*mem_type,
r = ttm_bo_reserve(&bo->tbo, true, no_wait, NULL);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS) {
- struct drm_device *ddev = bo->gem_base.dev;
+ struct drm_device *ddev = bo->tbo.base.dev;
dev_err(ddev->dev, "%p reserve failed for wait\n",
bo);
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index 0a2e51af1230..498000899bfd 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -375,7 +375,7 @@ void qxl_io_destroy_primary(struct qxl_device *qdev)
{
wait_for_io_cmd(qdev, 0, QXL_IO_DESTROY_PRIMARY_ASYNC);
qdev->primary_bo->is_primary = false;
- drm_gem_object_put_unlocked(&qdev->primary_bo->gem_base);
+ drm_gem_object_put_unlocked(&qdev->primary_bo->tbo.base);
qdev->primary_bo = NULL;
}
@@ -402,7 +402,7 @@ void qxl_io_create_primary(struct qxl_device *qdev, struct
qxl_bo *bo)
wait_for_io_cmd(qdev, 0, QXL_IO_CREATE_PRIMARY_ASYNC);
qdev->primary_bo = bo;
qdev->primary_bo->is_primary = true;
- drm_gem_object_get(&qdev->primary_bo->gem_base);
+ drm_gem_object_get(&qdev->primary_bo->tbo.base);
}
void qxl_io_memslot_add(struct qxl_device *qdev, uint8_t id)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 118422549828..013b938986c7 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -66,7 +66,7 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
rcu_read_unlock();
seq_printf(m, "size %ld, pc %d, num releases %d\n",
- (unsigned long)bo->gem_base.size,
+ (unsigned long)bo->tbo.base.size,
bo->pin_count, rel);
}
return 0;
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 8b319ebbb0fb..93e31d062854 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -794,7 +794,7 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane,
qdev->dumb_shadow_bo->surf.height != surf.height) {
[PATCH v2 02/18] drm/vram: use embedded gem object
Drop drm_gem_object from drm_gem_vram_object, use the
ttm_buffer_object.base instead.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 3 +--
drivers/gpu/drm/ast/ast_main.c | 2 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 16
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_main.c | 2 +-
drivers/gpu/drm/vboxvideo/vbox_main.c | 2 +-
6 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 9581ea0a4f7e..7b9f50ba3fce 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -36,7 +36,6 @@ struct vm_area_struct;
* video memory becomes scarce.
*/
struct drm_gem_vram_object {
- struct drm_gem_object gem;
struct ttm_buffer_object bo;
struct ttm_bo_kmap_obj kmap;
@@ -68,7 +67,7 @@ static inline struct drm_gem_vram_object *drm_gem_vram_of_bo(
static inline struct drm_gem_vram_object *drm_gem_vram_of_gem(
struct drm_gem_object *gem)
{
- return container_of(gem, struct drm_gem_vram_object, gem);
+ return container_of(gem, struct drm_gem_vram_object, bo.base);
}
struct drm_gem_vram_object *drm_gem_vram_create(struct drm_device *dev,
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 4c7e31cb45ff..74e6e471d283 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -609,6 +609,6 @@ int ast_gem_create(struct drm_device *dev,
DRM_ERROR("failed to allocate GEM object\n");
return ret;
}
- *obj = &gbo->gem;
+ *obj = &gbo->bo.base;
return 0;
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 4de782ca26b2..61d9520cc15f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -24,7 +24,7 @@ static void drm_gem_vram_cleanup(struct drm_gem_vram_object
*gbo)
* TTM buffer object in 'bo' has already been cleaned
* up; only release the GEM object.
*/
- drm_gem_object_release(&gbo->gem);
+ drm_gem_object_release(&gbo->bo.base);
}
static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
@@ -80,7 +80,7 @@ static int drm_gem_vram_init(struct drm_device *dev,
int ret;
size_t acc_size;
- ret = drm_gem_object_init(dev, &gbo->gem, size);
+ ret = drm_gem_object_init(dev, &gbo->bo.base, size);
if (ret)
return ret;
@@ -98,7 +98,7 @@ static int drm_gem_vram_init(struct drm_device *dev,
return 0;
err_drm_gem_object_release:
- drm_gem_object_release(&gbo->gem);
+ drm_gem_object_release(&gbo->bo.base);
return ret;
}
@@ -378,11 +378,11 @@ int drm_gem_vram_fill_create_dumb(struct drm_file *file,
if (IS_ERR(gbo))
return PTR_ERR(gbo);
- ret = drm_gem_handle_create(file, &gbo->gem, &handle);
+ ret = drm_gem_handle_create(file, &gbo->bo.base, &handle);
if (ret)
goto err_drm_gem_object_put_unlocked;
- drm_gem_object_put_unlocked(&gbo->gem);
+ drm_gem_object_put_unlocked(&gbo->bo.base);
args->pitch = pitch;
args->size = size;
@@ -391,7 +391,7 @@ int drm_gem_vram_fill_create_dumb(struct drm_file *file,
return 0;
err_drm_gem_object_put_unlocked:
- drm_gem_object_put_unlocked(&gbo->gem);
+ drm_gem_object_put_unlocked(&gbo->bo.base);
return ret;
}
EXPORT_SYMBOL(drm_gem_vram_fill_create_dumb);
@@ -441,7 +441,7 @@ int drm_gem_vram_bo_driver_verify_access(struct
ttm_buffer_object *bo,
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
- return drm_vma_node_verify_access(&gbo->gem.vma_node,
+ return drm_vma_node_verify_access(&gbo->bo.base.vma_node,
filp->private_data);
}
EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
@@ -635,7 +635,7 @@ int drm_gem_vram_driver_gem_prime_mmap(struct
drm_gem_object *gem,
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
- gbo->gem.vma_node.vm_node.start = gbo->bo.vma_node.vm_node.start;
+ gbo->bo.base.vma_node.vm_node.start = gbo->bo.vma_node.vm_node.start;
return drm_gem_prime_mmap(gem, vma);
}
EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_mmap);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 52fba8cb8ddd..f2a63b5f0425 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -65,7 +65,7 @@ int hibmc_gem_create(struct drm_device *dev, u32 size, bool
iskernel,
DRM_ERROR("failed to allocate GEM object: %d\n", ret);
return ret;
}
- *obj = &gbo->gem;
+ *obj = &gbo->bo.b
[PATCH v2 05/18] drm/amdgpu: use embedded gem object
Drop drm_gem_object from amdgpu_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
6 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
index b8ba6e27c61f..2f17150e26e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
@@ -31,7 +31,7 @@
*/
#define AMDGPU_GEM_DOMAIN_MAX 0x3
-#define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, gem_base)
+#define gem_to_amdgpu_bo(gobj) container_of((gobj), struct amdgpu_bo, tbo.base)
void amdgpu_gem_object_free(struct drm_gem_object *obj);
int amdgpu_gem_object_open(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index c430e8259038..a80a9972ad16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -94,7 +94,6 @@ struct amdgpu_bo {
/* per VM structure for page tables and with virtual addresses */
struct amdgpu_vm_bo_base*vm_bo;
/* Constant after initialization */
- struct drm_gem_object gem_base;
struct amdgpu_bo*parent;
struct amdgpu_bo*shadow;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 489041df1f45..c56819bcad8e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -409,7 +409,7 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
bo->prime_shared_count = 1;
ww_mutex_unlock(&resv->lock);
- return &bo->gem_base;
+ return &bo->tbo.base;
error:
ww_mutex_unlock(&resv->lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 37b526c6f494..6d991e8df357 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -85,7 +85,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev,
unsigned long size,
}
return r;
}
- *obj = &bo->gem_base;
+ *obj = &bo->tbo.base;
return 0;
}
@@ -690,7 +690,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
struct drm_amdgpu_gem_create_in info;
void __user *out = u64_to_user_ptr(args->value);
- info.bo_size = robj->gem_base.size;
+ info.bo_size = robj->tbo.base.size;
info.alignment = robj->tbo.mem.page_alignment << PAGE_SHIFT;
info.domains = robj->preferred_domains;
info.domain_flags = robj->flags;
@@ -820,8 +820,8 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr,
void *data)
if (pin_count)
seq_printf(m, " pin count %d", pin_count);
- dma_buf = READ_ONCE(bo->gem_base.dma_buf);
- attachment = READ_ONCE(bo->gem_base.import_attach);
+ dma_buf = READ_ONCE(bo->tbo.base.dma_buf);
+ attachment = READ_ONCE(bo->tbo.base.import_attach);
if (attachment)
seq_printf(m, " imported from %p", dma_buf);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 16f96f2e3671..00b283f914a6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -85,9 +85,9 @@ static void amdgpu_bo_destroy(struct ttm_buffer_object *tbo)
amdgpu_bo_kunmap(bo);
- if (bo->gem_base.import_attach)
- drm_prime_gem_destroy(&bo->gem_base, bo->tbo.sg);
- drm_gem_object_release(&bo->gem_base);
+ if (bo->tbo.base.import_attach)
+ drm_prime_gem_destroy(&bo->tbo.base, bo->tbo.sg);
+ drm_gem_object_release(&bo->tbo.base);
/* in case amdgpu_device_recover_vram got NULL of bo->parent */
if (!list_empty(&bo->shadow_list)) {
mutex_lock(&adev->shadow_list_lock);
@@ -454,7 +454,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
bo = kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
- drm_gem_private_object_init(adev->ddev, &bo->gem_base, size);
+ drm_gem_private_object_init(adev->ddev, &bo->tbo.base, size);
INIT_LIST_HEAD(&bo->shadow_list);
bo->vm_bo = NULL;
bo->preferred_domains = bp->preferred_domain ? bp->preferred_domain :
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/dr
[PATCH v2 18/18] drm/ttm: drop ttm_buffer_object->resv
All users moved to ttm_buffer_object->base.resv
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 77bd420a147a..af331d56951c 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -231,7 +231,6 @@ struct ttm_buffer_object {
struct sg_table *sg;
- struct reservation_object *resv;
struct mutex wu_mutex;
};
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e0792fd38b54..7465bf62e54c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1330,11 +1330,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->acc_size = acc_size;
bo->sg = sg;
if (resv) {
- bo->resv = resv;
bo->base.resv = resv;
reservation_object_assert_held(bo->base.resv);
} else {
- bo->resv = &bo->base._resv;
bo->base.resv = &bo->base._resv;
}
if (!ttm_bo_uses_embedded_gem_object(bo)) {
--
2.18.1
[PATCH v2 09/18] drm/vram: drop drm_gem_vram_driver_gem_prime_mmap
The wrapper doesn't do anything any more, drop it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 -
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 7b9f50ba3fce..2ada671a2a6b 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -137,8 +137,6 @@ void drm_gem_vram_driver_gem_prime_unpin(struct
drm_gem_object *obj);
void *drm_gem_vram_driver_gem_prime_vmap(struct drm_gem_object *obj);
void drm_gem_vram_driver_gem_prime_vunmap(struct drm_gem_object *obj,
void *vaddr);
-int drm_gem_vram_driver_gem_prime_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
#define DRM_GEM_VRAM_DRIVER_PRIME \
.gem_prime_export = drm_gem_prime_export, \
@@ -147,6 +145,6 @@ int drm_gem_vram_driver_gem_prime_mmap(struct
drm_gem_object *obj,
.gem_prime_unpin = drm_gem_vram_driver_gem_prime_unpin, \
.gem_prime_vmap = drm_gem_vram_driver_gem_prime_vmap, \
.gem_prime_vunmap = drm_gem_vram_driver_gem_prime_vunmap, \
- .gem_prime_mmap = drm_gem_vram_driver_gem_prime_mmap
+ .gem_prime_mmap = drm_gem_prime_mmap
#endif
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 2e474dee30df..d78761802374 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -619,20 +619,3 @@ void drm_gem_vram_driver_gem_prime_vunmap(struct
drm_gem_object *gem,
drm_gem_vram_unpin(gbo);
}
EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_vunmap);
-
-/**
- * drm_gem_vram_driver_gem_prime_mmap() - \
- Implements &struct drm_driver.gem_prime_mmap
- * @gem: The GEM object to map
- * @vma: The VMA describing the mapping
- *
- * Returns:
- * 0 on success, or
- * a negative errno code otherwise.
- */
-int drm_gem_vram_driver_gem_prime_mmap(struct drm_gem_object *gem,
- struct vm_area_struct *vma)
-{
- return drm_gem_prime_mmap(gem, vma);
-}
-EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_mmap);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/18] drm/radeon: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 ++--
drivers/gpu/drm/radeon/radeon_cs.c| 2 +-
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 6 +++---
drivers/gpu/drm/radeon/radeon_mn.c| 2 +-
drivers/gpu/drm/radeon/radeon_object.c| 8
drivers/gpu/drm/radeon/radeon_prime.c | 2 +-
drivers/gpu/drm/radeon/radeon_test.c | 8
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
drivers/gpu/drm/radeon/radeon_vm.c| 6 +++---
11 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c
b/drivers/gpu/drm/radeon/radeon_benchmark.c
index 7ce5064a59f6..1ea50ce16312 100644
--- a/drivers/gpu/drm/radeon/radeon_benchmark.c
+++ b/drivers/gpu/drm/radeon/radeon_benchmark.c
@@ -122,7 +122,7 @@ static void radeon_benchmark_move(struct radeon_device
*rdev, unsigned size,
if (rdev->asic->copy.dma) {
time = radeon_benchmark_do_move(rdev, size, saddr, daddr,
RADEON_BENCHMARK_COPY_DMA, n,
- dobj->tbo.resv);
+ dobj->tbo.base.resv);
if (time < 0)
goto out_cleanup;
if (time > 0)
@@ -133,7 +133,7 @@ static void radeon_benchmark_move(struct radeon_device
*rdev, unsigned size,
if (rdev->asic->copy.blit) {
time = radeon_benchmark_do_move(rdev, size, saddr, daddr,
RADEON_BENCHMARK_COPY_BLIT, n,
- dobj->tbo.resv);
+ dobj->tbo.base.resv);
if (time < 0)
goto out_cleanup;
if (time > 0)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index d206654b31ad..7e5254a34e84 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -257,7 +257,7 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser *p)
list_for_each_entry(reloc, &p->validated, tv.head) {
struct reservation_object *resv;
- resv = reloc->robj->tbo.resv;
+ resv = reloc->robj->tbo.base.resv;
r = radeon_sync_resv(p->rdev, &p->ib.sync, resv,
reloc->tv.num_shared);
if (r)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index ea6b752dd3a4..7bf73230ac0b 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -533,7 +533,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc
*crtc,
DRM_ERROR("failed to pin new rbo buffer before flip\n");
goto cleanup;
}
- work->fence =
dma_fence_get(reservation_object_get_excl(new_rbo->tbo.resv));
+ work->fence =
dma_fence_get(reservation_object_get_excl(new_rbo->tbo.base.resv));
radeon_bo_get_tiling_flags(new_rbo, &tiling_flags, NULL);
radeon_bo_unreserve(new_rbo);
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 7238007f5aa4..03873f21a734 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -114,7 +114,7 @@ static int radeon_gem_set_domain(struct drm_gem_object
*gobj,
}
if (domain == RADEON_GEM_DOMAIN_CPU) {
/* Asking for cpu access wait for object idle */
- r = reservation_object_wait_timeout_rcu(robj->tbo.resv, true,
true, 30 * HZ);
+ r = reservation_object_wait_timeout_rcu(robj->tbo.base.resv,
true, true, 30 * HZ);
if (!r)
r = -EBUSY;
@@ -449,7 +449,7 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void
*data,
}
robj = gem_to_radeon_bo(gobj);
- r = reservation_object_test_signaled_rcu(robj->tbo.resv, true);
+ r = reservation_object_test_signaled_rcu(robj->tbo.base.resv, true);
if (r == 0)
r = -EBUSY;
else
@@ -478,7 +478,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
}
robj = gem_to_radeon_bo(gobj);
- ret = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true,
30 * HZ);
+ ret = reservation_object_wait_timeout_rcu(robj->tbo.base.resv, true,
true, 30 * HZ);
if (ret == 0)
r = -EBUSY;
else if (ret < 0)
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
index 8c3871ed23a9..0d64ace0e6c1 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -163,7 +163,7 @@ static int radeon_mn_invalidate_range_start(struct
mmu_no
[PATCH v2 10/18] drm/ttm: set both resv and base.resv pointers
Initialize both ttm_buffer_object->resv and ttm_buffer_object->base.resv
pointers. This allows to move users from the former to the latter. When
all users are moved we can drop ttm_buffer_object->resv.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 1d91da85f399..3e605b9ee2f3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1331,9 +1331,11 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->sg = sg;
if (resv) {
bo->resv = resv;
+ bo->base.resv = resv;
reservation_object_assert_held(bo->resv);
} else {
bo->resv = &bo->base._resv;
+ bo->base.resv = &bo->base._resv;
}
if (!ttm_bo_uses_embedded_gem_object(bo)) {
/*
--
2.18.1
[PATCH v2 16/18] drm/qxl: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_release.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 013b938986c7..f30460782f05 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -61,7 +61,7 @@ qxl_debugfs_buffers_info(struct seq_file *m, void *data)
int rel;
rcu_read_lock();
- fobj = rcu_dereference(bo->tbo.resv->fence);
+ fobj = rcu_dereference(bo->tbo.base.resv->fence);
rel = fobj ? fobj->shared_count : 0;
rcu_read_unlock();
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 32126e8836b3..1b7be82c8e68 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -234,7 +234,7 @@ static int qxl_release_validate_bo(struct qxl_bo *bo)
return ret;
}
- ret = reservation_object_reserve_shared(bo->tbo.resv, 1);
+ ret = reservation_object_reserve_shared(bo->tbo.base.resv, 1);
if (ret)
return ret;
@@ -454,9 +454,9 @@ void qxl_release_fence_buffer_objects(struct qxl_release
*release)
list_for_each_entry(entry, &release->bos, head) {
bo = entry->bo;
- reservation_object_add_shared_fence(bo->resv, &release->base);
+ reservation_object_add_shared_fence(bo->base.resv,
&release->base);
ttm_bo_add_to_lru(bo);
- reservation_object_unlock(bo->resv);
+ reservation_object_unlock(bo->base.resv);
}
spin_unlock(&glob->lru_lock);
ww_acquire_fini(&release->ticket);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/18] drm/nouveau: use embedded gem object
Drop drm_gem_object from nouveau_bo, use the
ttm_buffer_object.base instead.
Build tested only.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/nouveau/nouveau_bo.h | 5 -
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_display.c | 8
drivers/gpu/drm/nouveau/nouveau_gem.c | 15 ---
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
7 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 846f4bdec0de..40f01b9a07d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -35,11 +35,6 @@ struct nouveau_bo {
struct nouveau_drm_tile *tile;
- /* Only valid if allocated via nouveau_gem_new() and iff you hold a
-* gem reference to it! For debugging, use gem.filp != NULL to test
-* whether it is valid. */
- struct drm_gem_object gem;
-
/* protect by the ttm reservation lock */
int pin_refcnt;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index fe39998f65cc..477cd0fb050f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -10,7 +10,7 @@
static inline struct nouveau_bo *
nouveau_gem_object(struct drm_gem_object *gem)
{
- return gem ? container_of(gem, struct nouveau_bo, gem) : NULL;
+ return gem ? container_of(gem, struct nouveau_bo, bo.base) : NULL;
}
/* nouveau_gem.c */
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index c3fd5dd39ed9..94387e62b338 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -139,7 +139,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
if (chan->ntfy) {
nouveau_vma_del(&chan->ntfy_vma);
nouveau_bo_unpin(chan->ntfy);
- drm_gem_object_put_unlocked(&chan->ntfy->gem);
+ drm_gem_object_put_unlocked(&chan->ntfy->bo.base);
}
if (chan->heap.block_size)
@@ -345,7 +345,7 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
goto done;
}
- ret = drm_gem_handle_create(file_priv, &chan->ntfy->gem,
+ ret = drm_gem_handle_create(file_priv, &chan->ntfy->bo.base,
&init->notifier_handle);
if (ret)
goto done;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 34a998012bf6..376215b2206f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -136,7 +136,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_device *dev = drm->dev;
struct nouveau_bo *nvbo = nouveau_bo(bo);
- if (unlikely(nvbo->gem.filp))
+ if (unlikely(nvbo->bo.base.filp))
DRM_ERROR("bo %p still attached to GEM object\n", bo);
WARN_ON(nvbo->pin_refcnt > 0);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
@@ -1400,7 +1400,7 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo,
struct file *filp)
{
struct nouveau_bo *nvbo = nouveau_bo(bo);
- return drm_vma_node_verify_access(&nvbo->gem.vma_node,
+ return drm_vma_node_verify_access(&nvbo->bo.base.vma_node,
filp->private_data);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 832da8e0020d..fc8f5bb73ca8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -201,7 +201,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer
*drm_fb)
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
if (fb->nvbo)
- drm_gem_object_put_unlocked(&fb->nvbo->gem);
+ drm_gem_object_put_unlocked(&fb->nvbo->bo.base);
drm_framebuffer_cleanup(drm_fb);
kfree(fb);
@@ -214,7 +214,7 @@ nouveau_user_framebuffer_create_handle(struct
drm_framebuffer *drm_fb,
{
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
- return drm_gem_handle_create(file_priv, &fb->nvbo->gem, handle);
+ return drm_gem_handle_create(file_priv, &fb->nvbo->bo.base, handle);
}
static const struct drm_framebuffer_funcs nouveau_framebuffer_funcs = {
@@ -660,8 +660,8 @@ nouveau_display_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
if (ret)
return ret;
- ret = drm_gem_handle_create(file_priv, &bo->gem, &args->handle);
- drm_gem_object_put_unlocked(&bo->gem);
+ ret = drm_gem_handle_create(file_priv, &bo->bo.base, &args->handle);
+ drm_gem_object_put_unlocked(&bo->bo.base);
[PATCH v2 17/18] drm/virtio: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index ac60be9b5c19..4adfced8df2c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -394,7 +394,7 @@ static int virtio_gpu_transfer_from_host_ioctl(struct
drm_device *dev,
(vgdev, qobj->hw_res_handle,
vfpriv->ctx_id, offset, args->level,
&box, fence);
- reservation_object_add_excl_fence(qobj->tbo.resv,
+ reservation_object_add_excl_fence(qobj->tbo.base.resv,
&fence->f);
dma_fence_put(&fence->f);
@@ -448,7 +448,7 @@ static int virtio_gpu_transfer_to_host_ioctl(struct
drm_device *dev, void *data,
(vgdev, qobj,
vfpriv ? vfpriv->ctx_id : 0, offset,
args->level, &box, fence);
- reservation_object_add_excl_fence(qobj->tbo.resv,
+ reservation_object_add_excl_fence(qobj->tbo.base.resv,
&fence->f);
dma_fence_put(&fence->f);
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 024c2aa0c929..328e28081d9f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -210,7 +210,7 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane
*plane,
0, 0, vgfb->fence);
ret = virtio_gpu_object_reserve(bo, false);
if (!ret) {
- reservation_object_add_excl_fence(bo->tbo.resv,
+ reservation_object_add_excl_fence(bo->tbo.base.resv,
&vgfb->fence->f);
dma_fence_put(&vgfb->fence->f);
vgfb->fence = NULL;
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/18] drm/vmwgfx: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 8
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index fc6673cde289..917eeb793585 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -459,9 +459,9 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
/* Buffer objects need to be either pinned or reserved: */
if (!(dst->mem.placement & TTM_PL_FLAG_NO_EVICT))
- lockdep_assert_held(&dst->resv->lock.base);
+ lockdep_assert_held(&dst->base.resv->lock.base);
if (!(src->mem.placement & TTM_PL_FLAG_NO_EVICT))
- lockdep_assert_held(&src->resv->lock.base);
+ lockdep_assert_held(&src->base.resv->lock.base);
if (dst->ttm->state == tt_unpopulated) {
ret = dst->ttm->bdev->driver->ttm_tt_populate(dst->ttm, &ctx);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 0d9478d2e700..4a38ab0733c4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -342,7 +342,7 @@ void vmw_bo_pin_reserved(struct vmw_buffer_object *vbo,
bool pin)
uint32_t old_mem_type = bo->mem.mem_type;
int ret;
- lockdep_assert_held(&bo->resv->lock.base);
+ lockdep_assert_held(&bo->base.resv->lock.base);
if (pin) {
if (vbo->pin_count++ > 0)
@@ -690,7 +690,7 @@ static int vmw_user_bo_synccpu_grab(struct
vmw_user_buffer_object *user_bo,
long lret;
lret = reservation_object_wait_timeout_rcu
- (bo->resv, true, true,
+ (bo->base.resv, true, true,
nonblock ? 0 : MAX_SCHEDULE_TIMEOUT);
if (!lret)
return -EBUSY;
@@ -1007,10 +1007,10 @@ void vmw_bo_fence_single(struct ttm_buffer_object *bo,
if (fence == NULL) {
vmw_execbuf_fence_commands(NULL, dev_priv, &fence, NULL);
- reservation_object_add_excl_fence(bo->resv, &fence->base);
+ reservation_object_add_excl_fence(bo->base.resv, &fence->base);
dma_fence_put(&fence->base);
} else
- reservation_object_add_excl_fence(bo->resv, &fence->base);
+ reservation_object_add_excl_fence(bo->base.resv, &fence->base);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index b4f6e1217c9d..e142714f132c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -169,7 +169,7 @@ static int vmw_cotable_unscrub(struct vmw_resource *res)
} *cmd;
WARN_ON_ONCE(bo->mem.mem_type != VMW_PL_MOB);
- lockdep_assert_held(&bo->resv->lock.base);
+ lockdep_assert_held(&bo->base.resv->lock.base);
cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
if (!cmd)
@@ -311,7 +311,7 @@ static int vmw_cotable_unbind(struct vmw_resource *res,
return 0;
WARN_ON_ONCE(bo->mem.mem_type != VMW_PL_MOB);
- lockdep_assert_held(&bo->resv->lock.base);
+ lockdep_assert_held(&bo->base.resv->lock.base);
mutex_lock(&dev_priv->binding_mutex);
if (!vcotbl->scrubbed)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 1d38a8b2f2ec..ccd7f758bf8c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -402,14 +402,14 @@ void vmw_resource_unreserve(struct vmw_resource *res,
if (switch_backup && new_backup != res->backup) {
if (res->backup) {
- lockdep_assert_held(&res->backup->base.resv->lock.base);
+
lockdep_assert_held(&res->backup->base.base.resv->lock.base);
list_del_init(&res->mob_head);
vmw_bo_unreference(&res->backup);
}
if (new_backup) {
res->backup = vmw_bo_reference(new_backup);
- lockdep_assert_held(&new_backup->base.resv->lock.base);
+
lockdep_assert_held(&new_backup->base.base.resv->lock.base);
list_add_tail(&res->mob_head, &new_backup->res_list);
} else {
res->backup = NULL;
@@ -691,7 +691,7 @@ void vmw_resource_unbind_list(struct vmw_buffer_object *vbo)
.num_shared = 0
};
- lockdep_assert_held(&vbo->base.resv->lock.base);
+ lockdep_assert_held(&vbo->base.base.resv->lock.base);
list_for_each_entry_safe(res, next, &vbo->res_list, mob_head) {
[PATCH v2 14/18] drm/amdgpu: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 20 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 30 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
13 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index df26bf34b675..6dce43bd60f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -218,7 +218,7 @@ void amdgpu_amdkfd_unreserve_memory_limit(struct amdgpu_bo
*bo)
static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
struct amdgpu_amdkfd_fence *ef)
{
- struct reservation_object *resv = bo->tbo.resv;
+ struct reservation_object *resv = bo->tbo.base.resv;
struct reservation_object_list *old, *new;
unsigned int i, j, k;
@@ -812,7 +812,7 @@ static int process_sync_pds_resv(struct amdkfd_process_info
*process_info,
struct amdgpu_bo *pd = peer_vm->root.base.bo;
ret = amdgpu_sync_resv(NULL,
- sync, pd->tbo.resv,
+ sync, pd->tbo.base.resv,
AMDGPU_FENCE_OWNER_UNDEFINED, false);
if (ret)
return ret;
@@ -887,7 +887,7 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
**process_info,
AMDGPU_FENCE_OWNER_KFD, false);
if (ret)
goto wait_pd_fail;
- ret = reservation_object_reserve_shared(vm->root.base.bo->tbo.resv, 1);
+ ret =
reservation_object_reserve_shared(vm->root.base.bo->tbo.base.resv, 1);
if (ret)
goto reserve_shared_fail;
amdgpu_bo_fence(vm->root.base.bo,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index dc63707e426f..118ec7514277 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -402,7 +402,7 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
struct ttm_operation_ctx ctx = {
.interruptible = true,
.no_wait_gpu = false,
- .resv = bo->tbo.resv,
+ .resv = bo->tbo.base.resv,
.flags = 0
};
uint32_t domain;
@@ -734,7 +734,7 @@ static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p)
list_for_each_entry(e, &p->validated, tv.head) {
struct amdgpu_bo *bo = ttm_to_amdgpu_bo(e->tv.bo);
- struct reservation_object *resv = bo->tbo.resv;
+ struct reservation_object *resv = bo->tbo.base.resv;
r = amdgpu_sync_resv(p->adev, &p->job->sync, resv, p->filp,
amdgpu_bo_explicit_sync(bo));
@@ -1732,7 +1732,7 @@ int amdgpu_cs_find_mapping(struct amdgpu_cs_parser
*parser,
*map = mapping;
/* Double check that the BO is reserved by this CS */
- if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != &parser->ticket)
+ if (READ_ONCE((*bo)->tbo.base.resv->lock.ctx) != &parser->ticket)
return -EINVAL;
if (!((*bo)->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS)) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 535650967b1a..b5d020e15c35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -204,7 +204,7 @@ int amdgpu_display_crtc_page_flip_target(struct drm_crtc
*crtc,
goto unpin;
}
- r = reservation_object_get_fences_rcu(new_abo->tbo.resv, &work->excl,
+ r = reservation_object_get_fences_rcu(new_abo->tbo.base.resv,
&work->excl,
&work->shared_count,
&work->shared);
if (unlikely(r != 0)) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index c56819bcad8e..cd4fe9dd8863 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -216,7 +216,7 @@ static int amdgpu_dma_buf_map_attach(struct dma_buf
*dma_buf,
* fences on the reser
[PATCH v2 11/18] drm/ttm: switch ttm core from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_driver.h| 12 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 96 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 16 ++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 6 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 20 +++---
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
6 files changed, 76 insertions(+), 76 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9b8ba492f24..5b54e3254d13 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -654,14 +654,14 @@ static inline int __ttm_bo_reserve(struct
ttm_buffer_object *bo,
if (WARN_ON(ticket))
return -EBUSY;
- success = reservation_object_trylock(bo->resv);
+ success = reservation_object_trylock(bo->base.resv);
return success ? 0 : -EBUSY;
}
if (interruptible)
- ret = reservation_object_lock_interruptible(bo->resv, ticket);
+ ret = reservation_object_lock_interruptible(bo->base.resv,
ticket);
else
- ret = reservation_object_lock(bo->resv, ticket);
+ ret = reservation_object_lock(bo->base.resv, ticket);
if (ret == -EINTR)
return -ERESTARTSYS;
return ret;
@@ -745,10 +745,10 @@ static inline int ttm_bo_reserve_slowpath(struct
ttm_buffer_object *bo,
WARN_ON(!kref_read(&bo->kref));
if (interruptible)
- ret = ww_mutex_lock_slow_interruptible(&bo->resv->lock,
+ ret = ww_mutex_lock_slow_interruptible(&bo->base.resv->lock,
ticket);
else
- ww_mutex_lock_slow(&bo->resv->lock, ticket);
+ ww_mutex_lock_slow(&bo->base.resv->lock, ticket);
if (likely(ret == 0))
ttm_bo_del_sub_from_lru(bo);
@@ -773,7 +773,7 @@ static inline void ttm_bo_unreserve(struct
ttm_buffer_object *bo)
else
ttm_bo_move_to_lru_tail(bo, NULL);
spin_unlock(&bo->bdev->glob->lru_lock);
- reservation_object_unlock(bo->resv);
+ reservation_object_unlock(bo->base.resv);
}
/*
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3e605b9ee2f3..e0792fd38b54 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -173,7 +173,7 @@ static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object
*bo,
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_type_manager *man;
- reservation_object_assert_held(bo->resv);
+ reservation_object_assert_held(bo->base.resv);
if (!list_empty(&bo->lru))
return;
@@ -244,7 +244,7 @@ static void ttm_bo_bulk_move_set_pos(struct
ttm_lru_bulk_move_pos *pos,
void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
struct ttm_lru_bulk_move *bulk)
{
- reservation_object_assert_held(bo->resv);
+ reservation_object_assert_held(bo->base.resv);
ttm_bo_del_from_lru(bo);
ttm_bo_add_to_lru(bo);
@@ -277,8 +277,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
if (!pos->first)
continue;
- reservation_object_assert_held(pos->first->resv);
- reservation_object_assert_held(pos->last->resv);
+ reservation_object_assert_held(pos->first->base.resv);
+ reservation_object_assert_held(pos->last->base.resv);
man = &pos->first->bdev->man[TTM_PL_TT];
list_bulk_move_tail(&man->lru[i], &pos->first->lru,
@@ -292,8 +292,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
if (!pos->first)
continue;
- reservation_object_assert_held(pos->first->resv);
- reservation_object_assert_held(pos->last->resv);
+ reservation_object_assert_held(pos->first->base.resv);
+ reservation_object_assert_held(pos->last->base.resv);
man = &pos->first->bdev->man[TTM_PL_VRAM];
list_bulk_move_tail(&man->lru[i], &pos->first->lru,
@@ -307,8 +307,8 @@ void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move
*bulk)
if (!pos->first)
continue;
- reservation_object_assert_held(pos->first->resv);
- reservation_object_assert_held(pos->last->resv);
+ reservation_object_assert_held(pos->first->base.resv);
+ reservation_object_assert_held(pos->last->base.resv);
lru = &pos->first->bdev->glob->swap_lru[i];
list_bulk_move_tail(lru, &pos->first->swap, &pos->last->swap);
@@ -439,12 +439,12 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
{
int r;
- if (bo->resv == &
[PATCH v2 15/18] drm/nouveau: switch driver from bo->resv to bo->base.resv
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_prime.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 283ff690350e..89f8e76a2d7d 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -457,7 +457,7 @@ nv50_wndw_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *state)
asyw->image.handle[0] = ctxdma->object.handle;
}
- asyw->state.fence = reservation_object_get_excl_rcu(fb->nvbo->bo.resv);
+ asyw->state.fence =
reservation_object_get_excl_rcu(fb->nvbo->bo.base.resv);
asyw->image.offset[0] = fb->nvbo->bo.offset;
if (wndw->func->prepare) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 376215b2206f..8294bb6e6955 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1323,7 +1323,7 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
{
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct drm_device *dev = drm->dev;
- struct dma_fence *fence = reservation_object_get_excl(bo->resv);
+ struct dma_fence *fence = reservation_object_get_excl(bo->base.resv);
nv10_bo_put_tile_region(dev, *old_tile, fence);
*old_tile = new_tile;
@@ -1654,7 +1654,7 @@ nouveau_ttm_tt_unpopulate(struct ttm_tt *ttm)
void
nouveau_bo_fence(struct nouveau_bo *nvbo, struct nouveau_fence *fence, bool
exclusive)
{
- struct reservation_object *resv = nvbo->bo.resv;
+ struct reservation_object *resv = nvbo->bo.base.resv;
if (exclusive)
reservation_object_add_excl_fence(resv, &fence->base);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index d4964f3397a1..e5f249ab216a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -335,7 +335,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
{
struct nouveau_fence_chan *fctx = chan->fence;
struct dma_fence *fence;
- struct reservation_object *resv = nvbo->bo.resv;
+ struct reservation_object *resv = nvbo->bo.base.resv;
struct reservation_object_list *fobj;
struct nouveau_fence *f;
int ret = 0, i;
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index b1e4852810ed..c7368aa0bdec 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
return -ENOENT;
nvbo = nouveau_gem_object(gem);
- lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true,
+ lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write,
true,
no_wait ? 0 : 30 * HZ);
if (!lret)
ret = -EBUSY;
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 0750caf86e12..b4b06ad34d4f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -112,5 +112,5 @@ struct reservation_object *nouveau_gem_prime_res_obj(struct
drm_gem_object *obj)
{
struct nouveau_bo *nvbo = nouveau_gem_object(obj);
- return nvbo->bo.resv;
+ return nvbo->bo.base.resv;
}
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/18] drm/ttm: use gem reservation object
Drop ttm_resv from ttm_buffer_object, use the gem reservation object
(base._resv) instead.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 40 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 72f6aeda619c..88aa7bf1b18a 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -235,7 +235,6 @@ struct ttm_buffer_object {
struct sg_table *sg;
struct reservation_object *resv;
- struct reservation_object ttm_resv;
struct mutex wu_mutex;
};
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a..516eef3b76d5 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -160,7 +160,8 @@ static void ttm_bo_release_list(struct kref *list_kref)
ttm_tt_destroy(bo->ttm);
atomic_dec(&bo->bdev->glob->bo_count);
dma_fence_put(bo->moving);
- reservation_object_fini(&bo->ttm_resv);
+ if (!ttm_bo_uses_embedded_gem_object(bo))
+ reservation_object_fini(&bo->base._resv);
mutex_destroy(&bo->wu_mutex);
bo->destroy(bo);
ttm_mem_global_free(bdev->glob->mem_glob, acc_size);
@@ -438,14 +439,14 @@ static int ttm_bo_individualize_resv(struct
ttm_buffer_object *bo)
{
int r;
- if (bo->resv == &bo->ttm_resv)
+ if (bo->resv == &bo->base._resv)
return 0;
- BUG_ON(!reservation_object_trylock(&bo->ttm_resv));
+ BUG_ON(!reservation_object_trylock(&bo->base._resv));
- r = reservation_object_copy_fences(&bo->ttm_resv, bo->resv);
+ r = reservation_object_copy_fences(&bo->base._resv, bo->resv);
if (r)
- reservation_object_unlock(&bo->ttm_resv);
+ reservation_object_unlock(&bo->base._resv);
return r;
}
@@ -456,8 +457,8 @@ static void ttm_bo_flush_all_fences(struct
ttm_buffer_object *bo)
struct dma_fence *fence;
int i;
- fobj = reservation_object_get_list(&bo->ttm_resv);
- fence = reservation_object_get_excl(&bo->ttm_resv);
+ fobj = reservation_object_get_list(&bo->base._resv);
+ fence = reservation_object_get_excl(&bo->base._resv);
if (fence && !fence->ops->signaled)
dma_fence_enable_sw_signaling(fence);
@@ -490,11 +491,11 @@ static void ttm_bo_cleanup_refs_or_queue(struct
ttm_buffer_object *bo)
spin_lock(&glob->lru_lock);
ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (!ret) {
- if (reservation_object_test_signaled_rcu(&bo->ttm_resv, true)) {
+ if (reservation_object_test_signaled_rcu(&bo->base._resv,
true)) {
ttm_bo_del_from_lru(bo);
spin_unlock(&glob->lru_lock);
- if (bo->resv != &bo->ttm_resv)
- reservation_object_unlock(&bo->ttm_resv);
+ if (bo->resv != &bo->base._resv)
+ reservation_object_unlock(&bo->base._resv);
ttm_bo_cleanup_memtype_use(bo);
reservation_object_unlock(bo->resv);
@@ -515,8 +516,8 @@ static void ttm_bo_cleanup_refs_or_queue(struct
ttm_buffer_object *bo)
reservation_object_unlock(bo->resv);
}
- if (bo->resv != &bo->ttm_resv)
- reservation_object_unlock(&bo->ttm_resv);
+ if (bo->resv != &bo->base._resv)
+ reservation_object_unlock(&bo->base._resv);
error:
kref_get(&bo->list_kref);
@@ -551,7 +552,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
if (unlikely(list_empty(&bo->ddestroy)))
resv = bo->resv;
else
- resv = &bo->ttm_resv;
+ resv = &bo->base._resv;
if (reservation_object_test_signaled_rcu(resv, true))
ret = 0;
@@ -631,7 +632,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
*bdev, bool remove_all)
kref_get(&bo->list_kref);
list_move_tail(&bo->ddestroy, &removed);
- if (remove_all || bo->resv != &bo->ttm_resv) {
+ if (remove_all || bo->resv != &bo->base._resv) {
spin_unlock(&glob->lru_lock);
reservation_object_lock(bo->resv, NULL);
@@ -1332,9 +1333,16 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->resv = resv;
reservation_object_assert_held(bo->resv);
} else {
- bo->resv = &bo->ttm_resv;
+ bo->resv = &bo->base._resv;
+ }
+ if (!ttm_bo_uses_embedded_gem_object(bo)) {
+ /*
+* bo.gem is not initialized, so we have to setup the
+* struct elemen
[PATCH v2 08/18] drm/ttm: use gem vma_node
Drop vma_node from ttm_buffer_object, use the gem struct
(base.vma_node) instead.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
include/drm/ttm/ttm_bo_api.h | 5 +
drivers/gpu/drm/drm_gem_vram_helper.c | 5 +
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 8
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c| 9 +
drivers/gpu/drm/virtio/virtgpu_prime.c | 3 ---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c| 4 ++--
14 files changed, 22 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index a80a9972ad16..a68d85bd8fab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -191,7 +191,7 @@ static inline unsigned amdgpu_bo_gpu_page_alignment(struct
amdgpu_bo *bo)
*/
static inline u64 amdgpu_bo_mmap_offset(struct amdgpu_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
/**
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index b812d4ae9d0d..8ae54ba7857c 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -60,7 +60,7 @@ static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
static inline u64 qxl_bo_mmap_offset(struct qxl_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
static inline int qxl_bo_wait(struct qxl_bo *bo, u32 *mem_type,
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 9ffd8215d38a..e5554bf9140e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -116,7 +116,7 @@ static inline unsigned radeon_bo_gpu_page_alignment(struct
radeon_bo *bo)
*/
static inline u64 radeon_bo_mmap_offset(struct radeon_bo *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
extern int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 9e2d3062b01d..7146ba00fd5b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -396,7 +396,7 @@ static inline void virtio_gpu_object_unref(struct
virtio_gpu_object **bo)
static inline u64 virtio_gpu_object_mmap_offset(struct virtio_gpu_object *bo)
{
- return drm_vma_node_offset_addr(&bo->tbo.vma_node);
+ return drm_vma_node_offset_addr(&bo->tbo.base.vma_node);
}
static inline int virtio_gpu_object_reserve(struct virtio_gpu_object *bo,
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 88aa7bf1b18a..77bd420a147a 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -152,7 +152,6 @@ struct ttm_tt;
* @ddestroy: List head for the delayed destroy list.
* @swap: List head for swap LRU list.
* @moving: Fence set when BO is moving
- * @vma_node: Address space manager node.
* @offset: The current GPU offset, which can have different meanings
* depending on the memory type. For SYSTEM type memory, it should be 0.
* @cur_placement: Hint of current placement.
@@ -219,9 +218,7 @@ struct ttm_buffer_object {
*/
struct dma_fence *moving;
-
- struct drm_vma_offset_node vma_node;
-
+ /* base.vma_node */
unsigned priority;
/**
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 61d9520cc15f..2e474dee30df 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -163,7 +163,7 @@ EXPORT_SYMBOL(drm_gem_vram_put);
*/
u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo)
{
- return drm_vma_node_offset_addr(&gbo->bo.vma_node);
+ return drm_vma_node_offset_addr(&gbo->bo.base.vma_node);
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
@@ -633,9 +633,6 @@ EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_vunmap);
int drm_gem_vram_driver_gem_prime_mmap(struct drm_gem_object *gem,
struct vm_area_struct *vma)
{
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
-
- gbo->bo.base.vma_node.vm_node.start = gbo->bo.vma_node.vm_node.start;
return drm_gem_prime_mmap(gem, vma);
}
EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_mmap);
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On Fri, Jun 21, 2019 at 1:50 PM Daniel Vetter wrote: > > On Fri, Jun 21, 2019 at 1:37 PM Christian König > wrote: > > > > Am 21.06.19 um 13:03 schrieb Daniel Vetter: > > > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian > > > wrote: > > >> Am 21.06.19 um 12:20 schrieb Emil Velikov: > > >>> In particular, that user-space will "remove" render nodes. > > >> Yes, that is my main concern here. You basically make render nodes > > >> superfluously. That gives userspace all legitimization to also remove > > >> support for them. That is not stupid or evil or whatever, userspace > > >> would just follow the kernel design. > > > This already happened. At least for kms-only display socs we had to > > > hide the separate render node (and there you really have to deal with > > > the separate render node, because it's a distinct driver) entirely > > > within gbm/mesa. > > > > Ok, that is something I didn't knew before and is rather interesting. > > > > > So if you want to depracate render functionality on primary nodes, you > > > _have_ to do that hiding in userspace. Or you'll break a lot of > > > compositors everywhere. Just testing -amdgpu doesn't really prove > > > anything here. So you won't move the larger ecosystem with this at > > > all, that ship sailed. > > > > So what else can we do? That sounds like you suggest we should > > completely drop render node functionality. > > > > I mean it's not my preferred option, but certainly something that > > everybody could do. > > > > My primary concern is that we somehow need to get rid of thinks like GEM > > flink and all that other crufty stuff we still have around on the > > primary node (we should probably make a list of that). > > > > Switching everything over to render nodes just sounded like the best > > alternative so far to archive that. > > tbh I do like that plan too, but it's a lot more work. And I think to > have any push whatsoever we probably need to roll it out in gbm as a > hack to keep things going. But probably not enough. > > I also think that at least some compositors will bother to do the > right thing, and actually bother with render nodes and all that > correctly. It's just that there's way more which dont. > > Also for server rendering it'll be render nodes all the way down I > hope (or we need to seriously educate cloud people about the > permissions they set on their default images, and distros on how this > cloud stuff should work. > > > > At that point this all feels like a bikeshed, and for a bikeshed I > > > don't care what the color is we pick, as long as they're all painted > > > the same. > > > > > > Once we picked a color it's a simple technical matter of how to roll > > > it out, using Kconfig options, or only enabling on new hw, or "merge > > > and fix the regressions as they come" or any of the other well proven > > > paths forward. > > > > Yeah, the problem is I don't see an option which currently works for > > everyone. > > > > I absolutely need a grace time of multiple years until we can apply this > > to amdgpu/radeon. > > Yeah that's what I meant with "pick a color, pick a way to roll it > out". "enable for new hw, roll out years and years later" is one of > the options for roll out. > > > And that under the prerequisite to have a plan to somehow enable that > > functionality now to make it at least painful for userspace to rely on > > hack around that. > > > > > So if you want to do this, please start with the mesa side work (as > > > the biggest userspace, not all of it) with patches to redirect all > > > primary node rendering to render nodes. The code is there already for > > > socs, just needs to be rolled out more. Or we go with the DRM_AUTH > > > horrors. Or a 3rd option, I really don't care which it is, as long as > > > its consistent. > > > > How about this: > > 1. We keep DRM_AUTH around for amdgpu/radeon for now. > > 2. We add a Kconfig option to ignore DRM_AUTH, currently default to N. > > This also works as a workaround for old RADV. > > 3. We start to work on further removing old cruft from the primary node. > > Possible the Kconfig option I suggested to disable GEM flink. > > Hm I'm not worried about flink really. It's gem_open which is the > security gap, and that one has to stay master-only forever. I guess we > could try to disable that so people have to deal with dma-buf (and > once you have that render nodes become a lot easier to use). But then > I still think we have drivers which don't do dma-buf self-import, so > again we're stuck. So maybe first step is to just roll out a default > self-import dma-buf support for every gem driver. Then start ditching > flink/gem_open. Then start ditching render support on primary nodes. > Every step in the way taking a few years of prodding userspace plus > even more years to wait until it's all gone. I forgot one step here: I think we even still have drivers without render node support. As long as those exists (and are still relevant) then userspace needs primary
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/21, Koenig, Christian wrote: > Am 21.06.19 um 12:53 schrieb Emil Velikov: > > On 2019/06/21, Koenig, Christian wrote: > >> [SNIP] > >> Well partially. That RADV broke is unfortunate, but we have done so many > >> customized userspace stuff both based on Mesa/DDX as well as closed > >> source components that it is just highly likely that we would break > >> something else as well. > >> > > As an engineer I like to work with tangibles. The highly likely part is > > probable, but as mentioned multiple times the series allows for a _dead_ > > trivial way to address any such problems. > > Well to clarify my concern is that this won't be so trivial. > > You implemented on workaround for one specific case and it is perfectly > possible that for other cases we would have to completely revert the > removal of DRM_AUTH. > I would encourage you to take a closer look at my patch and point out how parcicular cases cannot be handled. > >>> In particular, that user-space will "remove" render nodes. > >> Yes, that is my main concern here. You basically make render nodes > >> superfluously. That gives userspace all legitimization to also remove > >> support for them. That is not stupid or evil or whatever, userspace > >> would just follow the kernel design. > >> > > Do you have an example of userspace doing such an extremely silly thing? > > It does seem like suspect you're a couple of steps beyond overcautious, > > perhaps rightfully so. Maybe you've seen some closed-source user-space > > going crazy? Or any other projects? > > The key point is that I don't think this is silly or strange or crazy at > all. See the kernel defines the interface userspace can and should use. > > When the kernel defines that everything will work with the primary node > it is perfectly valid for userspace to drop support for the render node. > > I mean why should they keep this? Just because we tell them not to do this? > From your experiense, do user-space developers care about doing (or generally do) the right thing? In either case, as pointed already the cat is out of the bag - has been for years, and if developers did behave as you describe them they would have "removed" render nodes already. > > In other words, being cautious is great, but without references of > > misuse it's very hard for others to draw the full picture. > > > >>> I'm really sad that amdgpu insists on standing out, hope one day it will > >>> converge. Yet since all other maintainers are ok with the series, I'll > >>> start merging patches in a few hours. I'm really sad that amdgpu wants > >>> to stand out, hope it will converge sooner rather than later. > >>> > >>> Christian, how would you like amdgpu handled - with a separate flag in > >>> the driver or shall we special case amdgpu within core drm? > >> No, I ask you to please stick around DRM_AUTH for at least amdgpu and > >> radeon. And NOT enable any render node functionality for them on the > >> primary node. > >> > > My question is how do you want this handled: > > - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or > > - driver_name == amdgpu, in core DRM. > > I want to keep DRM_AUTH in amdgpu and radeon for at least the next 5-10 > years. > Believe we're all fully aware of that fact. I'm asking which _approach_ you prefer. That said, I'll send a new patch/series and we'll nitpick it there. Thanks -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/21, Daniel Vetter wrote: > On Fri, Jun 21, 2019 at 1:50 PM Daniel Vetter wrote: > > > > On Fri, Jun 21, 2019 at 1:37 PM Christian König > > wrote: > > > > > > Am 21.06.19 um 13:03 schrieb Daniel Vetter: > > > > On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian > > > > wrote: > > > >> Am 21.06.19 um 12:20 schrieb Emil Velikov: > > > >>> In particular, that user-space will "remove" render nodes. > > > >> Yes, that is my main concern here. You basically make render nodes > > > >> superfluously. That gives userspace all legitimization to also remove > > > >> support for them. That is not stupid or evil or whatever, userspace > > > >> would just follow the kernel design. > > > > This already happened. At least for kms-only display socs we had to > > > > hide the separate render node (and there you really have to deal with > > > > the separate render node, because it's a distinct driver) entirely > > > > within gbm/mesa. > > > > > > Ok, that is something I didn't knew before and is rather interesting. > > > > > > > So if you want to depracate render functionality on primary nodes, you > > > > _have_ to do that hiding in userspace. Or you'll break a lot of > > > > compositors everywhere. Just testing -amdgpu doesn't really prove > > > > anything here. So you won't move the larger ecosystem with this at > > > > all, that ship sailed. > > > > > > So what else can we do? That sounds like you suggest we should > > > completely drop render node functionality. > > > > > > I mean it's not my preferred option, but certainly something that > > > everybody could do. > > > > > > My primary concern is that we somehow need to get rid of thinks like GEM > > > flink and all that other crufty stuff we still have around on the > > > primary node (we should probably make a list of that). > > > > > > Switching everything over to render nodes just sounded like the best > > > alternative so far to archive that. > > > > tbh I do like that plan too, but it's a lot more work. And I think to > > have any push whatsoever we probably need to roll it out in gbm as a > > hack to keep things going. But probably not enough. > > > > I also think that at least some compositors will bother to do the > > right thing, and actually bother with render nodes and all that > > correctly. It's just that there's way more which dont. > > > > Also for server rendering it'll be render nodes all the way down I > > hope (or we need to seriously educate cloud people about the > > permissions they set on their default images, and distros on how this > > cloud stuff should work. > > > > > > At that point this all feels like a bikeshed, and for a bikeshed I > > > > don't care what the color is we pick, as long as they're all painted > > > > the same. > > > > > > > > Once we picked a color it's a simple technical matter of how to roll > > > > it out, using Kconfig options, or only enabling on new hw, or "merge > > > > and fix the regressions as they come" or any of the other well proven > > > > paths forward. > > > > > > Yeah, the problem is I don't see an option which currently works for > > > everyone. > > > > > > I absolutely need a grace time of multiple years until we can apply this > > > to amdgpu/radeon. > > > > Yeah that's what I meant with "pick a color, pick a way to roll it > > out". "enable for new hw, roll out years and years later" is one of > > the options for roll out. > > > > > And that under the prerequisite to have a plan to somehow enable that > > > functionality now to make it at least painful for userspace to rely on > > > hack around that. > > > > > > > So if you want to do this, please start with the mesa side work (as > > > > the biggest userspace, not all of it) with patches to redirect all > > > > primary node rendering to render nodes. The code is there already for > > > > socs, just needs to be rolled out more. Or we go with the DRM_AUTH > > > > horrors. Or a 3rd option, I really don't care which it is, as long as > > > > its consistent. > > > > > > How about this: > > > 1. We keep DRM_AUTH around for amdgpu/radeon for now. > > > 2. We add a Kconfig option to ignore DRM_AUTH, currently default to N. > > > This also works as a workaround for old RADV. > > > 3. We start to work on further removing old cruft from the primary node. > > > Possible the Kconfig option I suggested to disable GEM flink. > > > > Hm I'm not worried about flink really. It's gem_open which is the > > security gap, and that one has to stay master-only forever. I guess we > > could try to disable that so people have to deal with dma-buf (and > > once you have that render nodes become a lot easier to use). But then > > I still think we have drivers which don't do dma-buf self-import, so > > again we're stuck. So maybe first step is to just roll out a default > > self-import dma-buf support for every gem driver. Then start ditching > > flink/gem_open. Then start ditching render support on primary nodes. > > Every step in the way taking a few years of prod
Re: [PATCH][next] video: fbdev: atmel_lcdfb: remove redundant initialization to variable ret
On 6/12/19 4:13 PM, Ludovic Desroches wrote:
> On Wed, Jun 12, 2019 at 09:55:30AM +0200, Nicolas Ferre - M43238 wrote:
>> On 11/06/2019 at 19:09, Colin King wrote:
>>> External E-Mail
>>>
>>>
>>> From: Colin Ian King
>>>
>>> Currently variable ret is being initialized with -ENOENT however that
>>> value is never read and ret is being re-assigned later on. Hence this
>>> assignment is redundant and can be removed.
>>>
>>> Addresses-Coverity: ("Unused value")
>>> Signed-off-by: Colin Ian King
>>
>> Indeed:
>> Acked-by: Nicolas Ferre
>
> Acked-by: Ludovic Desroches
Patch queued for v5.3, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/6] dma-buf: add dynamic DMA-buf handling v10
Am 21.06.19 um 12:32 schrieb Daniel Vetter: On Fri, Jun 21, 2019 at 11:55 AM Christian König wrote: Am 21.06.19 um 11:20 schrieb Daniel Vetter: On Tue, Jun 18, 2019 at 01:54:50PM +0200, Christian König wrote: [SNIP] Imo the below semantics would be much cleaner: - invalidate may add new fences - invalidate _must_ unmap its mappings - an unmap must wait for current fences before the mapping can be released. Imo there's no reason why unmap is special, and the only thing where we don't use fences to gate access to resources/memory when it's in the process of getting moved around. Well in general I want to avoid waiting for fences as much as possible. But the key point here is that this actually won't help with the problem I'm trying to solve. The point of using fences is not to wait on them. I mean if you have the shadow ttm bo on the lru you also don't wait for that fence to retire before you insert the shadow bo onto the lru. You don't even wait when you try to use that memory again, you just pipeline more stuff on top. Correct. Ok, if I understand it correctly your suggestion is to move the responsibility to delay destruction of mappings until they are no longer used from the importer to the exporter based on the fences of the reservation object. I seriously don't think that this is a good idea because you need to move the tracking who is using which mapping from the importer to the exporter as well. So duplicating quite a bunch of housekeeping. On the other hand that we have this house keeping in the importer because we get it for free from TTM. But I can't think of a way other memory management backends would do this without keeping the sg table around either. In the end it will be the exact same amount of fences and waiting in both solutions. One just leaks less implementationt details (at least in my opinion) across the dma-buf border. I agree that leaking implementation details over the DMA-buf border is a bad idea. But I can assure you that this has absolutely nothing todo with the ghost object handling of TTM. ghost objects doesn't even receive an invalidation, they are just a possible implementation of the delayed destruction of sg tables. btw this is like the 2nd or 3rd time I'm typing this, haven't seen your thoughts on this yet. Yeah, and I'm responding for the 3rd time now that you are misunderstanding why we need this here :) Maybe I can make that clear with an example: 1. You got a sharing between device A (exporter) and B (importer) which uses P2P. 2. Now device C (importer) comes along and wants to use the DMA-buf object as well. 3. The handling now figures out that we can't do P2P between device A and device C (for whatever reason). 4. The map_attachment implementation in device driver A doesn't want to fail with -EBUSY and migrates the DMA-buf somewhere where both device A and device C can access it. 5. This migration will result in sending an invalidation event around. And here it doesn't make sense to send this invalidation event to device C, because we know that device C is actually causing this event and doesn't have a valid mapping. Hm I thought the last time around there was a different scenario, with just one importer: - importer has a mapping, gets an ->invalidate call. - importer arranges for the mappings/usage to get torn down, maybe updating fences, all from ->invalidate. But the mapping itself wont disappear. - exporter moves buffer to new places (for whatever reasons it felt that was the thing to do). - importer does another execbuf, the exporter needs to move the buffer back. Again it calls ->invalidate, but on a mapping it already has called ->invalidate on, and to prevent that silliness we take the importer temporary off the list. Mhm, strange I don't remember giving this explanation. It also doesn't make to much sense, but see below. Your scenario here is new, and iirc my suggestion back then was to count the number of pending mappings so you don't go around calling ->invalidate on mappings that don't exist. Well the key point is we don't call invalidate on mappings, but we call invalidate on attachments. When the invalidate on an attachment is received all the importer should at least start to tear down all mappings. But even if you fix your scenario here there's still the issue that we can receive invalidates on a mapping we've already torn down and which is on the process of disappearing. That's kinda the part I don't think is great semantics. Yeah, that is a rather valid point. Currently it is perfectly valid to receive an invalidation when you don't even have any mappings at all. But this is intentional, because otherwise I would need to move the housekeeping which mappings are currently made from the importer to the exporter. And as explained above that would essentially mean double housekeeping. [SNIP] The reason I don't have that on unmap is that I think migrating things on unmap doesn'
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 13:58 schrieb Emil Velikov: > On 2019/06/21, Koenig, Christian wrote: >> Am 21.06.19 um 12:53 schrieb Emil Velikov: >>> On 2019/06/21, Koenig, Christian wrote: [SNIP] Well partially. That RADV broke is unfortunate, but we have done so many customized userspace stuff both based on Mesa/DDX as well as closed source components that it is just highly likely that we would break something else as well. >>> As an engineer I like to work with tangibles. The highly likely part is >>> probable, but as mentioned multiple times the series allows for a _dead_ >>> trivial way to address any such problems. >> Well to clarify my concern is that this won't be so trivial. >> >> You implemented on workaround for one specific case and it is perfectly >> possible that for other cases we would have to completely revert the >> removal of DRM_AUTH. >> > I would encourage you to take a closer look at my patch and point out > how parcicular cases cannot be handled. Well the last time I looked it only blocked the first call to the IOCTL. If that is no longer the case then what is the actual difference to DRM_AUTH+DRM_ALLOW_RENDER? > In particular, that user-space will "remove" render nodes. Yes, that is my main concern here. You basically make render nodes superfluously. That gives userspace all legitimization to also remove support for them. That is not stupid or evil or whatever, userspace would just follow the kernel design. >>> Do you have an example of userspace doing such an extremely silly thing? >>> It does seem like suspect you're a couple of steps beyond overcautious, >>> perhaps rightfully so. Maybe you've seen some closed-source user-space >>> going crazy? Or any other projects? >> The key point is that I don't think this is silly or strange or crazy at >> all. See the kernel defines the interface userspace can and should use. >> >> When the kernel defines that everything will work with the primary node >> it is perfectly valid for userspace to drop support for the render node. >> >> I mean why should they keep this? Just because we tell them not to do this? >> > From your experiense, do user-space developers care about doing (or > generally do) the right thing? No, not at all. Except for Marek and Michel they just take what works and even Marek is often short-cutting on this. > In either case, as pointed already the cat is out of the bag - has been > for years, and if developers did behave as you describe them they would > have "removed" render nodes already. Currently render nodes are mandatory because they are needed for headless operation. E.g. we have a whole bunch of customers which do transcoding with that on GPUs which don't even have a CRTC or even X running. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev-MMP: Use struct_size() in devm_kzalloc()
On 6/5/19 1:32 AM, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = devm_kzalloc(dev, size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = devm_kzalloc(dev, struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable size is not necessary, hence it
> is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Patch queued for v5.3, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Re: [PATCH] backlight: pwm_bl: Set pin to sleep state when powered down
On 22/05/2019 17:34, Paul Cercueil wrote: When the driver probes, the PWM pin is automatically configured to its default state, which should be the "pwm" function. At which point in the probe... and by who? However, at this point we don't know the actual level of the pin, which may be active or inactive. As a result, if the driver probes without enabling the backlight, the PWM pin might be active, and the backlight would be lit way before being officially enabled. To work around this, if the probe function doesn't enable the backlight, the pin is set to its sleep state instead of the default one, until the backlight is enabled. Whenk the backlight is disabled, the pin is reset to its sleep state. Doesn't this workaround result in a backlight flash between whatever enables it and the new code turning it off again? Signed-off-by: Paul Cercueil > --- drivers/video/backlight/pwm_bl.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index fb45f866b923..422f7903b382 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -50,6 +51,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb) struct pwm_state state; int err; + pinctrl_pm_select_default_state(pb->dev); + pwm_get_state(pb->pwm, &state); if (pb->enabled) return; @@ -90,6 +93,8 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb) regulator_disable(pb->power_supply); pb->enabled = false; + + pinctrl_pm_select_sleep_state(pb->dev); } static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness) @@ -626,6 +631,10 @@ static int pwm_backlight_probe(struct platform_device *pdev) backlight_update_status(bl); platform_set_drvdata(pdev, bl); + + if (bl->props.power == FB_BLANK_POWERDOWN) + pinctrl_pm_select_sleep_state(&pdev->dev); Didn't backlight_update_status(bl) already do this? Daniel. + return 0; err_alloc:
Re: [PATCH] drm/fourcc: Add Arm 16x16 block modifier
On Fri, Jun 21, 2019 at 11:21:08AM +0100, Raymond Smith wrote:
> Add the DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED modifier to
> denote the 16x16 block u-interleaved format used in Arm Utgard and
> Midgard GPUs.
>
> Signed-off-by: Raymond Smith
Reviewed-by: Brian Starkey
Thanks for chasing this down!
> ---
> include/uapi/drm/drm_fourcc.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3..8ed7ecf 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -743,6 +743,16 @@ extern "C" {
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> /*
> + * Arm 16x16 Block U-Interleaved modifier
> + *
> + * This is used by Arm Mali Utgard and Midgard GPUs. It divides the image
> + * into 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED \
> + fourcc_mod_code(ARM, ((1ULL << 55) | 1))
> +
> +/*
> * Allwinner tiled modifier
> *
> * This tiling mode is implemented by the VPU found on all Allwinner
> platforms,
> --
> 2.7.4
>
Re: linux-next: Fixes tags need some work in the drm-fixes tree
On Fri, 2019-06-21 at 21:41 +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 912bbf7e9ca4 ("gpu: ipu-v3: image-convert: Fix image downsize coefficients")
>
> Fixes tag
>
> Fixes: 70b9b6b3bcb21 ("gpu: ipu-v3: image-convert: calculate per-tile
>
> has these problem(s):
>
> - Please don't split Fixes tags across more than one line
>
> In commit
>
> bca4d70cf1b8 ("gpu: ipu-v3: image-convert: Fix input bytesperline for
> packed formats")
>
> Fixes tag
>
> Fixes: d966e23d61a2c ("gpu: ipu-v3: image-convert: fix bytesperline
>
> has these problem(s):
>
> - Please don't split Fixes tags across more than one line
>
> In commit
>
> ff391ecd65a1 ("gpu: ipu-v3: image-convert: Fix input bytesperline
> width/height align")
>
> Fixes tag
>
> Fixes: d966e23d61a2c ("gpu: ipu-v3: image-convert: fix bytesperline
>
> has these problem(s):
>
> - Please don't split Fixes tags across more than one line
>
I was under the impression that dim would have found those, but I only
just realized that "dim checkpatch" doesn't actually do any additional
checks beyond scripts/checkpatch.pl. Fixes tags are checked only as a
part of "dim push". I wonder if this could be changed [1].
[1] https://gitlab.freedesktop.org/drm/maintainer-tools/merge_requests/5
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: Fix heuristic to determine number of brightness levels
On 12/06/2019 19:00, Matthias Kaehlcke wrote:
With commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of
LED linearly to human eye") the number of set bits (aka hweight())
in the PWM period is used in the heuristic to determine the number
of brightness levels, when the brightness table isn't specified in
the DT. The number of set bits doesn't provide a reliable clue about
the length of the period, instead change the heuristic to:
nlevels = period / fls(period)
Also limit the maximum number of brightness levels to 4096 to avoid
excessively large tables.
With this the number of levels increases monotonically with the PWM
period, until the maximum of 4096 levels is reached:
period (ns)# levels
10016
50062
1000 111
5000 416
1 769
5
10 4096
Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to human
eye")
Signed-off-by: Matthias Kaehlcke
As I understand it we can't determine the PWM quantization without
actually programming it so the table could still be oversized after this
patch (e.g. multiple entries end up with same physical brightness) but
since it should always be monotonic and the table size will cap out at a
sane value then:
Acked-by: Daniel Thompson
---
drivers/video/backlight/pwm_bl.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..0b7152fa24f7 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -194,29 +194,17 @@ int pwm_backlight_brightness_default(struct device *dev,
struct platform_pwm_backlight_data *data,
unsigned int period)
{
- unsigned int counter = 0;
- unsigned int i, n;
+ unsigned int i;
u64 retval;
/*
-* Count the number of bits needed to represent the period number. The
-* number of bits is used to calculate the number of levels used for the
-* brightness-levels table, the purpose of this calculation is have a
-* pre-computed table with enough levels to get linear brightness
-* perception. The period is divided by the number of bits so for a
-* 8-bit PWM we have 255 / 8 = 32 brightness levels or for a 16-bit PWM
-* we have 65535 / 16 = 4096 brightness levels.
-*
-* Note that this method is based on empirical testing on different
-* devices with PWM of 8 and 16 bits of resolution.
+* Once we have 4096 levels there's little point going much higher...
+* neither interactive sliders nor animation benefits from having
+* more values in the table.
*/
- n = period;
- while (n) {
- counter += n % 2;
- n >>= 1;
- }
+ data->max_brightness =
+ min((int)DIV_ROUND_UP(period, fls(period)), 4096);
- data->max_brightness = DIV_ROUND_UP(period, counter);
data->levels = devm_kcalloc(dev, data->max_brightness,
sizeof(*data->levels), GFP_KERNEL);
if (!data->levels)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
On 2019/06/21, Koenig, Christian wrote: > Am 21.06.19 um 13:58 schrieb Emil Velikov: > > On 2019/06/21, Koenig, Christian wrote: > >> Am 21.06.19 um 12:53 schrieb Emil Velikov: > >>> On 2019/06/21, Koenig, Christian wrote: > [SNIP] > Well partially. That RADV broke is unfortunate, but we have done so many > customized userspace stuff both based on Mesa/DDX as well as closed > source components that it is just highly likely that we would break > something else as well. > > >>> As an engineer I like to work with tangibles. The highly likely part is > >>> probable, but as mentioned multiple times the series allows for a _dead_ > >>> trivial way to address any such problems. > >> Well to clarify my concern is that this won't be so trivial. > >> > >> You implemented on workaround for one specific case and it is perfectly > >> possible that for other cases we would have to completely revert the > >> removal of DRM_AUTH. > >> > > I would encourage you to take a closer look at my patch and point out > > how parcicular cases cannot be handled. > > Well the last time I looked it only blocked the first call to the IOCTL. > Hmm interesting, you're replied to my patch without even reading it :'-( Can you please give it a close look and reply inline? [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/219238.html > > From your experiense, do user-space developers care about doing (or > > generally do) the right thing? > > No, not at all. Except for Marek and Michel they just take what works > and even Marek is often short-cutting on this. > Interesting, guess I should have asked this question from the start. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] backlight: pwm_bl: Set scale type for CIE 1931 curves
On 13/06/2019 20:43, Matthias Kaehlcke wrote:
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
I'd like to keep discussion on patch 2 open a bit longer (it's not part
of the thread below patch 2 but Pavel had concerns about the sysfs
interface) so this ack won't really push things forward but FWIW:
Acked-by: Daniel Thompson
---
drivers/video/backlight/pwm_bl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index fb45f866b923..f067fe7aa35d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -553,6 +553,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
goto err_alloc;
}
+ memset(&props, 0, sizeof(struct backlight_properties));
+
if (data->levels) {
/*
* For the DT case, only when brightness levels is defined
@@ -591,6 +593,8 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->levels = data->levels;
}
+
+ props.scale = BACKLIGHT_SCALE_CIE1931;
} else {
/*
* That only happens for the non-DT case, where platform data
@@ -601,7 +605,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->lth_brightness = data->lth_brightness * (state.period / pb->scale);
- memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Am 21.06.19 um 14:47 schrieb Emil Velikov: > On 2019/06/21, Koenig, Christian wrote: >> Am 21.06.19 um 13:58 schrieb Emil Velikov: >>> On 2019/06/21, Koenig, Christian wrote: Am 21.06.19 um 12:53 schrieb Emil Velikov: > On 2019/06/21, Koenig, Christian wrote: >> [SNIP] >> Well partially. That RADV broke is unfortunate, but we have done so many >> customized userspace stuff both based on Mesa/DDX as well as closed >> source components that it is just highly likely that we would break >> something else as well. >> > As an engineer I like to work with tangibles. The highly likely part is > probable, but as mentioned multiple times the series allows for a _dead_ > trivial way to address any such problems. Well to clarify my concern is that this won't be so trivial. You implemented on workaround for one specific case and it is perfectly possible that for other cases we would have to completely revert the removal of DRM_AUTH. >>> I would encourage you to take a closer look at my patch and point out >>> how parcicular cases cannot be handled. >> Well the last time I looked it only blocked the first call to the IOCTL. >> > Hmm interesting, you're replied to my patch without even reading it :'-( Well I've NAKed the series because of the exposure of the render node functionality > Can you please give it a close look and reply inline? > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/219238.html So the workaround no longer just blocks the first IOCTL. But then the question is why don't you just keep the DRM_AUTH flag instead of adding the same functionality with a new one? >>> From your experiense, do user-space developers care about doing (or >>> generally do) the right thing? >> No, not at all. Except for Marek and Michel they just take what works >> and even Marek is often short-cutting on this. >> > Interesting, guess I should have asked this question from the start. Well sounds like you don't have to work with a closed source driver team. But as I said I honestly would do the same as user space developer. I mean it's really a bunch of more code to maintain, and getting rid of code is always less work in the long term then keeping it. That kernel developers scream: No no, please don't do that we want to keep using it is completely irrelevant for this. Christian. > > Thanks > Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: omap2: remove rfbi
Hi,
On 4/30/18 9:59 PM, Aaro Koskinen wrote:
> Hi,
>
> On Mon, Apr 30, 2018 at 10:06:11AM +0300, Tomi Valkeinen wrote:
>> On 27/04/18 21:12, Aaro Koskinen wrote:
You should be targeting omapdrm driver instead, fbdev subsystem is closed
for the new hardware support.
>>>
>>> AFAIK, based on N950 display support discussion, it's impossible to get
>>> anything new into omapdrm for a long time. And based on Tomi's comments,
>>> restoring RFBI support with omapfb should be a minor thing.
>>
>> I was perhaps a bit vague, but I didn't say it should be a minor thing.
>> I meant that there should be no architectural obstacles in omapfb, and I
>> think all the generic plumbing to enable N800 display is there in omapfb.
>>
>> That said, it still needs a real amount of work with the rfbi driver,
>> the encoder driver and the panel driver on N800 (the encoder and the
>> panel driver are not in mainline anymore).
>
> Let's see first if I get anything working. After that we can evaluate
> the impact properly once we see the actual patches needed.
It has been over a year now and not much has happened in the case of
fixing rfbi driver so I've queued the old patch removing it (with
updated patch description, please see below) for v5.3 (please note
that it can be trivially reverted using kernel git repository if ever
needed).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] video: fbdev: omap2: remove rfbi
Equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi").
The RFBI driver has been marked as BROKEN and has not been
included in the kernel build for many years. Just remove it
(it can be trivially brought back from git repository if
ever needed).
Cc: Tomi Valkeinen
Cc: Laurent Pinchart
Cc: Aaro Koskinen
Cc: Tony Lindgren
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/omap2/omapfb/dss/Kconfig | 12
drivers/video/fbdev/omap2/omapfb/dss/Makefile |1
drivers/video/fbdev/omap2/omapfb/dss/core.c |6
drivers/video/fbdev/omap2/omapfb/dss/dss.h|4
drivers/video/fbdev/omap2/omapfb/dss/rfbi.c | 1078 --
include/video/omapfb_dss.h| 32
6 files changed, 1133 deletions(-)
delete mode 100644 drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
Index: b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
===
--- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig
@@ -39,18 +39,6 @@ config FB_OMAP2_DSS_DPI
help
DPI Interface. This is the Parallel Display Interface.
-config FB_OMAP2_DSS_RFBI
- bool "RFBI support"
- depends on BROKEN
- help
- MIPI DBI support (RFBI, Remote Framebuffer Interface, in Texas
- Instrument's terminology).
-
- DBI is a bus between the host processor and a peripheral,
- such as a display or a framebuffer chip.
-
- See http://www.mipi.org/ for DBI specifications.
-
config FB_OMAP2_DSS_VENC
bool "VENC support"
default y
Index: b/drivers/video/fbdev/omap2/omapfb/dss/Makefile
===
--- a/drivers/video/fbdev/omap2/omapfb/dss/Makefile
+++ b/drivers/video/fbdev/omap2/omapfb/dss/Makefile
@@ -8,7 +8,6 @@ omapdss-y := core.o dss.o dss_features.o
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
omapdss-$(CONFIG_FB_OMAP2_DSS_DPI) += dpi.o
-omapdss-$(CONFIG_FB_OMAP2_DSS_RFBI) += rfbi.o
omapdss-$(CONFIG_FB_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_FB_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_FB_OMAP2_DSS_DSI) += dsi.o
Index: b/drivers/video/fbdev/omap2/omapfb/dss/core.c
===
--- a/drivers/video/fbdev/omap2/omapfb/dss/core.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/core.c
@@ -218,9 +218,6 @@ static int (*dss_output_drv_reg_funcs[])
#ifdef CONFIG_FB_OMAP2_DSS_SDI
sdi_init_platform_driver,
#endif
-#ifdef CONFIG_FB_OMAP2_DSS_RFBI
- rfbi_init_platform_driver,
-#endif
#ifdef CONFIG_FB_OMAP2_DSS_VENC
venc_init_platform_driver,
#endif
@@ -242,9 +239,6 @@ static void (*dss_output_drv_unreg_funcs
#ifdef CONFIG_FB_OMAP2_DSS_VENC
venc_uninit_platform_driver,
#endif
-#ifdef CONFIG_FB_OMAP2_DSS_RFBI
- rfbi_uninit_platform_driver,
-#endif
#ifdef CONFIG_FB_OMAP2_DSS_SDI
sdi_uninit_platform_driver,
#endif
Index: b/drivers/video/fbdev/omap2/omapfb/dss/dss.h
===
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.h
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.h
@@ -472,10 +472,6 @@ void hdmi4_uninit_platform_driver(void);
int hdmi5_init_platform_driver(void) __init;
void hdmi5_uninit_platform_driver(void);
-/* RFBI */
-int rfbi_init_plat
Re: [PATCH 4/4] backlight: pwm_bl: Set scale type for brightness curves specified in the DT
On 13/06/2019 20:43, Matthias Kaehlcke wrote:
Check if a brightness curve specified in the device tree is linear or
not and set the corresponding property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
To determine if a curve is linear it is compared to a interpolated linear
curve between min and max brightness. The curve is considered linear if
no value deviates more than +/-5% of ${brightness_range} from their
interpolated value.
Signed-off-by: Matthias Kaehlcke
---
drivers/video/backlight/pwm_bl.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index f067fe7aa35d..912407b6d67f 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -404,6 +404,26 @@ int pwm_backlight_brightness_default(struct device *dev,
}
#endif
+static bool pwm_backlight_is_linear(struct platform_pwm_backlight_data *data)
+{
+ unsigned int nlevels = data->max_brightness + 1;
+ unsigned int min_val = data->levels[0];
+ unsigned int max_val = data->levels[nlevels - 1];
+ unsigned int slope = (100 * (max_val - min_val)) / nlevels;
Why 100 (rather than a power of 2)?
It would also be good to have a comment here saying what the maximum
quantization error is. Doesn't have to be over complex just mentioning
something like the following (assuming you agree that its true ;-) ):
Multiplying by XXX means that even in pathalogical cases such as
(max_val - min_val) == nlevels then the error at max_val is less than
1%.
With a suitable comment in the fixed point code:
Acked-by: Daniel Thompson
Daniel.
+ unsigned int margin = (max_val - min_val) / 20; /* 5% */
+ int i;
+
+ for (i = 1; i < nlevels; i++) {
+ unsigned int linear_value = min_val + ((i * slope) / 100);
+ unsigned int delta = abs(linear_value - data->levels[i]);
+
+ if (delta > margin)
+ return false;
+ }
+
+ return true;
+}
+
static int pwm_backlight_initial_power_state(const struct pwm_bl_data *pb)
{
struct device_node *node = pb->dev->of_node;
@@ -567,6 +587,11 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
pb->levels = data->levels;
}
+
+ if (pwm_backlight_is_linear(data))
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+ else
+ props.scale = BACKLIGHT_SCALE_NON_LINEAR;
} else if (!data->max_brightness) {
/*
* If no brightness levels are provided and max_brightness is
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 56/59] drm/todo: Update backlight todo
On 14/06/2019 21:36, Daniel Vetter wrote: Basic helpers have been extracted, now there's a pile more todo still across the entire tree. Signed-off-by: Daniel Vetter No disagreement here... so FWIW: Reviewed-by: Daniel Thompson Daniel. --- Documentation/gpu/todo.rst | 27 +-- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 21a7b7800d3e..c4e7c0672a14 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -422,6 +422,19 @@ fit the available time. Contact: Daniel Vetter +Backlight Refactoring +- + +Backlight drivers have a triple enable/disable state, which is a bit overkill. +Plan to fix this: + +1. Roll out backlight_enable() and backlight_disable() helpers everywhere. This + has started already. +2. In all, only look at one of the three status bits set by the above helpers. +3. Remove the other two status bits. + +Contact: Daniel Vetter + Driver Specific === @@ -431,20 +444,6 @@ tinydrm Tinydrm is the helper driver for really simple fb drivers. The goal is to make those drivers as simple as possible, so lots of room for refactoring: -- backlight helpers, probably best to put them into a new drm_backlight.c. - This is because drivers/video is de-facto unmaintained. We could also - move drivers/video/backlight to drivers/gpu/backlight and take it all - over within drm-misc, but that's more work. Backlight helpers require a fair - bit of reworking and refactoring. A simple example is the enabling of a backlight. - Tinydrm has helpers for this. It would be good if other drivers can also use the - helper. However, there are various cases we need to consider i.e different - drivers seem to have different ways of enabling/disabling a backlight. - We also need to consider the backlight drivers (like gpio_backlight). The situation - is further complicated by the fact that the backlight is tied to fbdev - via fb_notifier_callback() which has complicated logic. For further details, refer - to the following discussion thread: - https://groups.google.com/forum/#!topic/outreachy-kernel/8rBe30lwtdA - - spi helpers, probably best put into spi core/helper code. Thierry said the spi maintainer is fast&reactive, so shouldn't be a big issue. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
Hi Brian On Tue, 27 Nov 2018 at 00:44, Brian Dodge wrote: > Thank you Pavel, that is a good point. > > The chip vendor has indicated that there is no reason to maintain the > old/improper prefix and wishes to go forward (only) with the "arctic" > prefix and any existing dts files are or will be updated. > Looks like this patch series has fallen into the cracks a little. I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor. Daniel. > On 11/11/18 6:30 AM, Pavel Machek wrote: > > Hi! > > > >> The vendor-prefixes.txt file properly refers to ArcticSand > >> as arctic but the driver improperly abbreviated the prefix > >> to arc. This was a mistake in the original patch > >> > >> Signed-off-by: Brian Dodge > >> --- > >> drivers/video/backlight/arcxcnn_bl.c | 22 +++--- > >> 1 file changed, 11 insertions(+), 11 deletions(-) > >> > >>* > >> - * Copyright 2016 ArcticSand, Inc. > >> - * Author : Brian Dodge > >> + * Copyright 2018 pSemi, Inc. > >> + * Author : Brian Dodge > > Ummm. Copyright 2016-2018? > > > >> @@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp) > >> if (ret == 0) > >> lp->pdata->initial_brightness = prog_val; > >> > >> -ret = of_property_read_u32(node, "arc,led-config-0", &prog_val); > >> +ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val); > >> if (ret == 0) > >> lp->pdata->led_config_0 = (u8)prog_val; > >> > > If there's a dts using this, you want to update it at the same > > time. You may want to support both names going forward. > > > Pavel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer] On 27/11/2018 00:44, Brian Dodge wrote: Thank you Pavel, that is a good point. The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated. Looks like this patch series has fallen into the cracks a little. I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor. Daniel. On 11/11/18 6:30 AM, Pavel Machek wrote: Hi! The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch Signed-off-by: Brian Dodge --- drivers/video/backlight/arcxcnn_bl.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) * - * Copyright 2016 ArcticSand, Inc. - * Author : Brian Dodge + * Copyright 2018 pSemi, Inc. + * Author : Brian Dodge Ummm. Copyright 2016-2018? @@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp) if (ret == 0) lp->pdata->initial_brightness = prog_val; - ret = of_property_read_u32(node, "arc,led-config-0", &prog_val); + ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val); if (ret == 0) lp->pdata->led_config_0 = (u8)prog_val; If there's a dts using this, you want to update it at the same time. You may want to support both names going forward. Pavel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/29] docs: console.txt: convert docs to ReST and rename to *.rst
On Tue, Jun 18, 2019 at 05:53:24PM -0300, Mauro Carvalho Chehab wrote: > Convert this small file to ReST in preparation for adding it to > the driver-api book. > > While this is not part of the driver-api book, mark it as > :orphan:, in order to avoid build warnings. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 00/18] drm/ttm: make ttm bo a gem bo subclass
One little comment on patch #8: + /* base.vma_node */ Is that really useful? I would just drop it. Apart from that Patches #1, #2, #4, #5, #7 - #12, #14, #15, #18 are Reviewed-by: Christian König . Patches #3, #6, #13, #16, #17 are Acked-by: Christian König . You should try to get an rb for the respective maintainer for patches #3 and #6. When that's done I think we can merge it. Any preference for the tree where this goes upstream? If not I suggest to use drm-misc-next. Thanks for the nice cleanup, Christian. Am 21.06.19 um 13:57 schrieb Gerd Hoffmann: v2: - build fixes. - also drop ttm_buffer_object->resv Gerd Hoffmann (18): drm/ttm: add gem base object drm/vram: use embedded gem object drm/qxl: use embedded gem object drm/radeon: use embedded gem object drm/amdgpu: use embedded gem object drm/nouveau: use embedded gem object drm/ttm: use gem reservation object drm/ttm: use gem vma_node drm/vram: drop drm_gem_vram_driver_gem_prime_mmap drm/ttm: set both resv and base.resv pointers drm/ttm: switch ttm core from bo->resv to bo->base.resv drm/radeon: switch driver from bo->resv to bo->base.resv drm/vmwgfx: switch driver from bo->resv to bo->base.resv drm/amdgpu: switch driver from bo->resv to bo->base.resv drm/nouveau: switch driver from bo->resv to bo->base.resv drm/qxl: switch driver from bo->resv to bo->base.resv drm/virtio: switch driver from bo->resv to bo->base.resv drm/ttm: drop ttm_buffer_object->resv drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 3 +- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 - drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 6 +- drivers/gpu/drm/qxl/qxl_object.h | 6 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_object.h| 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- include/drm/drm_gem_vram_helper.h | 7 +- include/drm/ttm/ttm_bo_api.h | 25 +++- include/drm/ttm/ttm_bo_driver.h | 12 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 28 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 30 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- drivers/gpu/drm/ast/ast_main.c| 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 36 ++--- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +- drivers/gpu/drm/mgag200/mgag200_main.c| 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +- drivers/gpu/drm/nouveau/nouveau_display.c | 10 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 19 +-- drivers/gpu/drm/nouveau/nouveau_prime.c | 6 +- drivers/gpu/drm/qxl/qxl_cmd.c | 4 +- drivers/gpu/drm/qxl/qxl_debugfs.c | 4 +- drivers/gpu/drm/qxl/qxl_display.c | 8 +- drivers/gpu/drm/qxl/qxl_gem.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 20 +-- drivers/gpu/drm/qxl/qxl_release.c | 8 +- drivers/gpu/drm/qxl/qxl_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- drivers/gpu/drm/radeon/radeon_cs.c| 4 +- drivers/gpu/drm/radeon/radeon_display.c | 6 +- drivers/gpu/drm/radeon/radeon_gem.c | 8 +- drivers/gpu/drm/radeon/radeon_mn.c| 2 +- drivers/gpu/drm/radeon/radeon_object.c| 22 +-- drivers/gpu/drm/radeon/radeon_prime.c | 4 +- drivers/gpu/drm/radeon/radeon_test.c | 8 +- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c| 6 +- drivers/gpu/drm/ttm/ttm_bo.c | 136 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-- drivers/gpu/drm/ttm/ttm_bo_vm.c | 15 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c| 20 +-- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_main.c | 2 +- drivers/gpu/drm/virtio/virtgpu_i
Re: Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
On 21/06/2019 14:46, Daniel Thompson wrote: [Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer] On 27/11/2018 00:44, Brian Dodge wrote: Thank you Pavel, that is a good point. The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated. Looks like this patch series has fallen into the cracks a little. I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor. In fact there's a publicly available example using this binding: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/factory-gru-8652.B-chromeos-4.4/arch/arm64/boot/dts/rockchip/rk3399-gru-gru.dtsi I'm not sure it could be changed without maintaining support for old names. Daniel. Daniel. On 11/11/18 6:30 AM, Pavel Machek wrote: Hi! The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch Signed-off-by: Brian Dodge --- drivers/video/backlight/arcxcnn_bl.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) * - * Copyright 2016 ArcticSand, Inc. - * Author : Brian Dodge + * Copyright 2018 pSemi, Inc. + * Author : Brian Dodge Ummm. Copyright 2016-2018? @@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp) if (ret == 0) lp->pdata->initial_brightness = prog_val; - ret = of_property_read_u32(node, "arc,led-config-0", &prog_val); + ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val); if (ret == 0) lp->pdata->led_config_0 = (u8)prog_val; If there's a dts using this, you want to update it at the same time. You may want to support both names going forward. Pavel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: Set pin to sleep state when powered down
On Fri, Jun 21, 2019 at 01:41:45PM +0100, Daniel Thompson wrote: > On 22/05/2019 17:34, Paul Cercueil wrote: > > When the driver probes, the PWM pin is automatically configured to its > > default state, which should be the "pwm" function. > > At which point in the probe... and by who? The driver core will select the "default" state of a device right before calling the driver's probe, see: drivers/base/pinctrl.c: pinctrl_bind_pins() which is called from: drivers/base/dd.c: really_probe() > > However, at this > > point we don't know the actual level of the pin, which may be active or > > inactive. As a result, if the driver probes without enabling the > > backlight, the PWM pin might be active, and the backlight would be > > lit way before being officially enabled. > > > > To work around this, if the probe function doesn't enable the backlight, > > the pin is set to its sleep state instead of the default one, until the > > backlight is enabled. Whenk the backlight is disabled, the pin is reset > > to its sleep state. > Doesn't this workaround result in a backlight flash between whatever enables > it and the new code turning it off again? Yeah, I think it would. I guess if you're very careful on how you set up the device tree you might be able to work around it. Besides the default and idle standard pinctrl states, there's also the "init" state. The core will select that instead of the default state if available. However there's also pinctrl_init_done() which will try again to switch to the default state after probe has finished and the driver didn't switch away from the init state. So you could presumably set up the device tree such that you have three states defined: "default" would be the one where the PWM pin is active, "idle" would be used when backlight is off (PWM pin inactive) and then another "init" state that would be the same as "idle" to be used during probe. During probe the driver could then switch to the "idle" state so that the pin shouldn't glitch. I'm not sure this would actually work because I think the way that pinctrl handles states both "init" and "idle" would be the same pointer values and therefore pinctrl_init_done() would think the driver didn't change away from the "init" state because it is the same pointer value as the "idle" state that the driver selected. One way to work around that would be to duplicate the "idle" state definition and associate one instance of it with the "idle" state and the other with the "init" state. At that point both states should be different (different pointer values) and we'd get the init state selected automatically before probe, select "idle" during probe and then the core will leave it alone. That's of course ugly because we duplicate the pinctrl state in DT, but perhaps it's the least ugly solution. Adding Linus for visibility. Perhaps he can share some insight. On that note, I'm wondering if perhaps it'd make sense for pinctrl to support some mode where a device would start out in idle mode. That is, where pinctrl_bind_pins() would select the "idle" mode as the default before probe. With something like that we could easily support this use-case without glitching. I suppose yet another variant would be for the PWM backlight to not use any of the standard pinctrl states at all. Instead it could just define custom states, say "active" and "inactive". Looking at the code that would prevent pinctrl_bind_pins() from doing anything with pinctrl states and given the driver exact control over when each of the states will be selected. That's somewhat suboptimal because we can't make use of the pinctrl PM helpers and it'd require more boilerplate. Thierry > > Signed-off-by: Paul Cercueil > --- > > drivers/video/backlight/pwm_bl.c | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/video/backlight/pwm_bl.c > > b/drivers/video/backlight/pwm_bl.c > > index fb45f866b923..422f7903b382 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -16,6 +16,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -50,6 +51,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb) > > struct pwm_state state; > > int err; > > + pinctrl_pm_select_default_state(pb->dev); > > + > > pwm_get_state(pb->pwm, &state); > > if (pb->enabled) > > return; > > @@ -90,6 +93,8 @@ static void pwm_backlight_power_off(struct pwm_bl_data > > *pb) > > regulator_disable(pb->power_supply); > > pb->enabled = false; > > + > > + pinctrl_pm_select_sleep_state(pb->dev); > > } > > static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness) > > @@ -626,6 +631,10 @@ static int pwm_backlight_probe(struct platform_device > > *pdev) > > backlight_update_status(bl); > > platform_set_drvdata(pdev, bl); > > + > > + if (bl->props.power == FB_BLANK_POWERDOWN) > > +
Re: [PATCH v3 2/2] drm/panel: Add support for Raydium RM67191 panel driver
Hi Robert,
On Thu, Jun 20, 2019 at 10:31 AM Robert Chiras wrote:
> +fail:
> + if (rad->reset)
> + gpiod_set_value_cansleep(rad->reset, 1);
gpiod_set_value_cansleep() can handle NULL, so no need for the if() check.
> +static const struct display_timing rad_default_timing = {
> + .pixelclock = { 13200, 13200, 13200 },
Having the same information listed three times does not seem useful.
You could use a drm_display_mode structure with a single entry instead.
> + videomode_from_timing(&rad_default_timing, &panel->vm);
> +
> + of_property_read_u32(np, "width-mm", &panel->width_mm);
> + of_property_read_u32(np, "height-mm", &panel->height_mm);
> +
> + panel->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
Since this is optional it would be better to use
devm_gpiod_get_optional() instead.
> +
> + if (IS_ERR(panel->reset))
> + panel->reset = NULL;
> + else
> + gpiod_set_value_cansleep(panel->reset, 1);
This is not handling defer probing, so it would be better to do like this:
panel->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(panel->reset))
return PTR_ERR(panel->reset);
> + memset(&bl_props, 0, sizeof(bl_props));
> + bl_props.type = BACKLIGHT_RAW;
> + bl_props.brightness = 255;
> + bl_props.max_brightness = 255;
> +
> + panel->backlight = devm_backlight_device_register(dev, dev_name(dev),
> + dev, dsi,
> + &rad_bl_ops,
> + &bl_props);
Could you put more parameters into the same line?
Using 4 lines seems excessive.
> + if (IS_ERR(panel->backlight)) {
> + ret = PTR_ERR(panel->backlight);
> + dev_err(dev, "Failed to register backlight (%d)\n", ret);
> + return ret;
> + }
> +
> + drm_panel_init(&panel->panel);
> + panel->panel.funcs = &rad_panel_funcs;
> + panel->panel.dev = dev;
> + dev_set_drvdata(dev, panel);
> +
> + ret = drm_panel_add(&panel->panel);
> +
Unneeded blank line
> + if (ret < 0)
> + return ret;
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0)
> + drm_panel_remove(&panel->panel);
> +
> + return ret;
You did not handle the "power" regulator.
> +static int __maybe_unused rad_panel_suspend(struct device *dev)
> +{
> + struct rad_panel *rad = dev_get_drvdata(dev);
> +
> + if (!rad->reset)
> + return 0;
> +
> + devm_gpiod_put(dev, rad->reset);
> + rad->reset = NULL;
> +
> + return 0;
> +}
> +
> +static int __maybe_unused rad_panel_resume(struct device *dev)
> +{
> + struct rad_panel *rad = dev_get_drvdata(dev);
> +
> + if (rad->reset)
> + return 0;
> +
> + rad->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
Why do you call devm_gpiod_get() once again?
I am having a hard time to understand the need for this suspend/resume hooks.
Can't you simply remove them?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
Hi Robert, On Thu, Jun 20, 2019 at 10:32 AM Robert Chiras wrote: > > Add dt-bindings documentation for Raydium RM67191 DSI panel. > > Signed-off-by: Robert Chiras > Reviewed-by: Sam Ravnborg > --- > .../bindings/display/panel/raydium,rm67191.txt | 39 > ++ > 1 file changed, 39 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt > b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt > new file mode 100644 > index 000..52af272 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt > @@ -0,0 +1,39 @@ > +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol > + > +Required properties: > +- compatible: "raydium,rm67191" > +- reg: virtual channel for MIPI-DSI protocol > + must be <0> > +- dsi-lanes: number of DSI lanes to be used > + must be <3> or <4> > +- port:input port node with endpoint definition as > + defined in > Documentation/devicetree/bindings/graph.txt; > + the input port should be connected to a MIPI-DSI > device > + driver > + > +Optional properties: > +- reset-gpios: a GPIO spec for the RST_B GPIO pin > +- width-mm:see panel-common.txt > +- height-mm: see panel-common.txt > +- video-mode: 0 - burst-mode > + 1 - non-burst with sync event > + 2 - non-burst with sync po ulse No power-supply property?
Re: [PATCH 1/3] drm/stm: drv: fix suspend/resume
Hi Emil,
The msm driver tests the return value & set state to NULL if no error is
detected.
the ltdc driver tests the return value & force to suspend if an error is
detected.
It's not exactly the same.
Best regards
--
Yannick Fertré | TINA: 166 7152 | Tel: +33 244027152 | Mobile: +33 620600270
Microcontrollers and Digital ICs Group | Microcontrolleurs Division
On 6/20/19 7:12 PM, Emil Velikov wrote:
> Hi Yannick,
>
> On Mon, 17 Jun 2019 at 08:18, Yannick Fertré wrote:
>
>> @@ -155,15 +154,17 @@ static __maybe_unused int drv_resume(struct device
>> *dev)
>> struct ltdc_device *ldev = ddev->dev_private;
>> int ret;
>>
>> + if (WARN_ON(!ldev->suspend_state))
>> + return -ENOENT;
>> +
>> pm_runtime_force_resume(dev);
>> ret = drm_atomic_helper_resume(ddev, ldev->suspend_state);
>> - if (ret) {
>> + if (ret)
> Hmm the msm driver uses !ret here. Suspecting that you want the same,
> although I haven't checked in detail.
>
> HTH
> -Emil
--
Yannick Fertré | TINA: 166 7152 | Tel: +33 244027152 | Mobile: +33 620600270
Microcontrollers and Digital ICs Group | Microcontrolleurs Division
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [EXT] Re: [PATCH v3 1/2] dt-bindings: display: panel: Add support for Raydium RM67191 panel
Hi Fabio, On Vi, 2019-06-21 at 11:00 -0300, Fabio Estevam wrote: > Hi Robert, > > On Thu, Jun 20, 2019 at 10:32 AM Robert Chiras > wrote: > > > > > > Add dt-bindings documentation for Raydium RM67191 DSI panel. > > > > Signed-off-by: Robert Chiras > > Reviewed-by: Sam Ravnborg > > --- > > .../bindings/display/panel/raydium,rm67191.txt | 39 > > ++ > > 1 file changed, 39 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/raydium,rm67191.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/raydium,rm67191.t > > xt > > b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.t > > xt > > new file mode 100644 > > index 000..52af272 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/panel/raydium,rm67191.t > > xt > > @@ -0,0 +1,39 @@ > > +Raydium RM67171 OLED LCD panel with MIPI-DSI protocol > > + > > +Required properties: > > +- compatible: "raydium,rm67191" > > +- reg: virtual channel for MIPI-DSI protocol > > + must be <0> > > +- dsi-lanes: number of DSI lanes to be used > > + must be <3> or <4> > > +- port:input port node with endpoint definition as > > + defined in > > Documentation/devicetree/bindings/graph.txt; > > + the input port should be connected to a > > MIPI-DSI device > > + driver > > + > > +Optional properties: > > +- reset-gpios: a GPIO spec for the RST_B GPIO pin > > +- width-mm:see panel-common.txt > > +- height-mm: see panel-common.txt > > +- video-mode: 0 - burst-mode > > + 1 - non-burst with sync event > > + 2 - non-burst with sync po ulse > No power-supply property? From what I've seen in the schematics, the power lines on the DSI port on all the i.MX8 cores are coming from a PMIC providing power for all the peripherals. Since I didn't find a way to cut the power on a single peripheral (like DSI, for example) it doesn't make sense for power- supply property. For now, at least.
Re: [PATCH 2/2] drm: Set crc->opened = false before setting crc source to NULL.
On 2019-06-05 1:06 p.m., Dingchen Zhang wrote:
> to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc
> are called in the hook to set crc source.
>
> Cc:Leo Li , Harry , Nick
>
> Signed-off-by: Dingchen Zhang
I wonder how this isn't creating problems for Rockchip with the Analogix
bridge.
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index e20adef9d623..0e8bcc130383 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -249,6 +249,13 @@ static int crtc_crc_release(struct inode *inode, struct
> file *filep)
> struct drm_crtc *crtc = filep->f_inode->i_private;
> struct drm_crtc_crc *crc = &crtc->crc;
>
> + /* terminate the infinite while loop if 'drm_dp_aux_crc_work' running */
> + if (crc->opened) {
> + spin_lock_irq(&crc->lock);
> + crc->opened = false;
> + spin_unlock_irq(&crc->lock);
> + }
> +
> crtc->funcs->set_crc_source(crtc, NULL);
>
> spin_lock_irq(&crc->lock);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
