Re: [PATCH 2/2] panfrost: Add compatible string for bifrost
On Mon, 5 Oct 2020 at 08:44, Tomeu Vizoso wrote:
>
> On Fri, 19 Jun 2020 at 11:00, Steven Price wrote:
> >
> > On 11/06/2020 09:58, Tomeu Vizoso wrote:
> > > Mesa now supports some Bifrost devices, so enable it.
> > >
> > > Signed-off-by: Tomeu Vizoso
> >
> > Reviewed-by: Steven Price
> >
> > I've also dug out my Hikey960 (from the box it's been in since lock down
> > started), so I'll see if I can get things running on there, at the
> > moment I'm seeing some DATA_INVALID_FAULT regressions running my hacked
> > DDK :(
>
> Hi!
>
> Has this one fallen through the cracks?
Oops, sorry about the noise, I had an old checkout.
Cheers,
Tomeu
> Thanks,
>
> Tomeu
>
> >
> > Steve
> >
> > > ---
> > > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > index 882fecc33fdb..8ff8e140f91e 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > @@ -677,6 +677,7 @@ static const struct of_device_id dt_match[] = {
> > > { .compatible = "arm,mali-t830", .data = &default_data, },
> > > { .compatible = "arm,mali-t860", .data = &default_data, },
> > > { .compatible = "arm,mali-t880", .data = &default_data, },
> > > + { .compatible = "arm,mali-bifrost", .data = &default_data, },
> > > {}
> > > };
> > > MODULE_DEVICE_TABLE(of, dt_match);
> > >
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: remove unintended executable mode
Besides the intended change, commit 3437f5f6c979 ("drm/amdgpu: add gfx
support for van gogh (v2)") also set the source files gfx_v10_0.c to be
executable, i.e., changed from old mode 644 to new mode 755.
Set to the usual mode for source and headers files. No functional change.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20201002
Alex, please pick this minor non-urgent cleanup patch on your -next tree.
Huang Rui, please ack. You might want to check your development environment
introducing those executable modes on files.
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100755 => 100644 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
old mode 100755
new mode 100644
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
On 10/2/20 4:03 PM, Douglas Anderson wrote:
> On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
> link training was failing. Specifically, we'd see:
>
> ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training
> failed, link is off (-5)
>
> The panel was hooked up to a logic analyzer and it was found that, as
> part of link training, the bridge chip was writing a 0x1 to DPCD
> address 00600h and the panel responded NACK. As can be seen in header
> files, the write of 0x1 to DPCD address 0x600h means we were trying to
> write the value DP_SET_POWER_D0 to the register DP_SET_POWER. The
> panel vendor says that a NACK in this case is not unexpected and means
> "not ready, try again".
>
> In testing, we found that this panel would respond with a NACK in
> about 1/25 times. Adding the retry logic worked fine and the most
> number of tries needed was 3. Just to be safe, we'll add 10 tries
> here and we'll add a little blurb to the logs if we ever need more
> than 5.
>
> Signed-off-by: Douglas Anderson
> ---
>
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++
> 1 file changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index ecdf9b01340f..6e12cda69b54 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -106,6 +106,8 @@
> #define SN_NUM_GPIOS 4
> #define SN_GPIO_PHYSICAL_OFFSET 1
>
> +#define SN_LINK_TRAINING_TRIES 10
> +
> /**
> * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver.
> * @dev: Pointer to our device.
> @@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> {
> unsigned int val;
> int ret;
> + int i;
>
> /* set dp clk frequency value */
> regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,
> @@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge
> *pdata, int dp_rate_idx,
> goto exit;
> }
>
> - /* Semi auto link training mode */
> - regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> - ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,
> -val == ML_TX_MAIN_LINK_OFF ||
> -val == ML_TX_NORMAL_MODE, 1000,
> -500 * 1000);
> - if (ret) {
> - *last_err_str = "Training complete polling failed";
> - } else if (val == ML_TX_MAIN_LINK_OFF) {
> - *last_err_str = "Link training failed, link is off";
> - ret = -EIO;
> + /*
> + * We'll try to link train several times. As part of link training
> + * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If
> + * the panel isn't ready quite it might respond NAK here which means
> + * we need to try again.
> + */
> + for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {
> + /* Semi auto link training mode */
> + regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);
> + ret = regmap_read_poll_timeout(pdata->regmap,
> SN_ML_TX_MODE_REG, val,
> + val == ML_TX_MAIN_LINK_OFF ||
> + val == ML_TX_NORMAL_MODE, 1000,
> + 500 * 1000);
> + if (ret) {
> + *last_err_str = "Training complete polling failed";
> + } else if (val == ML_TX_MAIN_LINK_OFF) {
> + *last_err_str = "Link training failed, link is off";
> + ret = -EIO;
> + continue;
> + }
> +
> + break;
> }
>
> + /* If we saw quite a few retries, add a note about it */
> + if (!ret && i > SN_LINK_TRAINING_TRIES / 2)
> + DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n",
> i);
> +
> exit:
> /* Disable the PLL if we failed */
> if (ret)
Apologies for the previous HTML email, I was trying a new mail client
and... will not be switching to it.
Anyway.. again, this time in text..
Tested on the Lenovo C630, and haven’t seen the message, although I
hadn’t seen the described issue before either.
Tested-By: Steev Klimaszewski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- address review comments
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 26 +
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 44 ++---
drivers/gpu/drm/msm/dp/dp_power.h | 2 +-
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..6eb9cdad1421 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@ struct dp_ctrl_private {
struct dp_parser *parser;
struct dp_catalog *catalog;
+ struct opp_table *opp_table;
+
struct completion idle_comp;
struct completion video_comp;
};
@@ -1836,6 +1839,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
struct dp_parser *parser)
{
struct dp_ctrl_private *ctrl;
+ int ret;
if (!dev || !panel || !aux ||
!link || !catalog) {
@@ -1849,6 +1853,19 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device tree\n");
+ ctrl->opp_table = NULL;
+ } else {
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret && ret != -ENODEV) {
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+ }
+
init_completion(&ctrl->idle_comp);
init_completion(&ctrl->video_comp);
@@ -1866,4 +1883,13 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ if (ctrl->opp_table) {
+ dev_pm_opp_of_remove_table(ctrl->dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..269f83550b46 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -698,7 +698,7 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error;
}
- dp->power = dp_power_get(dp->parser);
+ dp->power = dp_power_get(dev, dp->parser);
if (IS_ERR(dp->power)) {
rc = PTR_ERR(dp->power);
DRM_ERROR("failed to initialize power, rc = %d\n", rc);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..9c4ea00a5f2a 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,51 @@ static int dp_power_clk_deinit(struct dp_power_private
*power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private *power,
+ struct dss_clk *clk_arry, int num_clk, int enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev, rate);
+ if (rc)
+ break;
+ }
+
+ }
+ }
+ return rc;
+}
+
static int dp_power_clk_set_rate(struct dp_power_private *power,
enum dp_pm_type module, bool enable)
{
int rc = 0;
struct dss_module_power *mp = &power->parser->mp[module];
- if (enable) {
- rc = msm_dss_clk_set_rate(mp->clk_config, mp->num_clk);
+ if (module == DP_CTRL_PM) {
+ rc = dp_power_clk_set_link_rate(power, mp->clk_config,
mp->num_clk, enable);
if (rc) {
-
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > That leaves the only interesting places as vb2_dc_get_userptr() and > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > REQUIRED behavior in the function's comment about checking PTEs. It > > just DMA maps them. Badly broken. > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > Yeah, see also the follow_pfn trickery in > videobuf_dma_contig_user_get(), I think this is fully intentional and > userspace abi we can't break :-/ We don't need to break uABI, it just needs to work properly in the kernel: vma = find_vma_intersection() dma_buf = dma_buf_get_from_vma(vma) sg = dma_buf_p2p_dma_map(dma_buf) [.. do dma ..] dma_buf_unmap(sg) dma_buf_put(dma_buf) It is as we discussed before, dma buf needs to be discoverable from a VMA, at least for users doing this kind of stuff. > Yup this should be done with dma_buf instead, and v4l has that. But > old uapi and all that. This is why I said we might need a new > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > case where the driver manages the underlying iomem range (or whatever > it is) dynamically and moves buffer objects around, like drm drivers > do. But I looked, and we've run out of vma->vm_flags :-( A VM flag doesn't help - we need to introduce some kind of lifetime, and that has to be derived from the VMA. It needs data not just a flag > The other problem is that I also have no real working clue about all > the VM_* flags and what they all mean, and whether drm drivers set the > right ones in all cases (they probably don't, but oh well). > Documentation for this stuff in headers is a bit thin at times. Yah, I don't really know either :\ The comment above vm_normal_page() is a bit helpful. Don't know what VM_IO/VM_PFNMAP mean in their 3 combinations There are very few places that set VM_PFNMAP without VM_IO.. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: add voltage corners voting support base on dp link rate
On 2020-09-30 09:24, Rajendra Nayak wrote:
On 9/30/2020 1:54 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2020-09-29 10:10:26)
Set link rate by using OPP set rate api so that CX level will be set
accordingly base on the link rate.
s/base/based/
Signed-off-by: Kuogee Hsieh
---
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..e1595d829e04 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1849,6 +1853,21 @@ struct dp_ctrl *dp_ctrl_get(struct device
*dev, struct dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
I see that downstream has multiple DP clocks which end up voting on
CX, we don't have a
way of associating multiple OPP tables with a device upstream, so
whats usually done is
(assuming all the clocks get scaled in lock step, which I assume is
the case here) we pick
the clock with the 'highest' CX requirement and associate that with
the OPP table.
I haven't looked but I am hoping thats how we have decided to
associate "ctrl_link" clock
here?
yes, only ctrl_link use dev_pm_opp_set_rate() to set rate.
+
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device
tree\n");
+ ctrl->opp_table = NULL;
+ } else {
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret && ret != -ENODEV) {
+ dev_err(dev, "add DP OPP table\n");
This is debug noise right?
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+ }
+
init_completion(&ctrl->idle_comp);
init_completion(&ctrl->video_comp);
@@ -1864,6 +1883,18 @@ struct dp_ctrl *dp_ctrl_get(struct device
*dev, struct dp_link *link,
return &ctrl->dp_ctrl;
}
-void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
+void dp_ctrl_put(struct device *dev, struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ if (!dp_ctrl)
Can this happen?
+ return;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private,
dp_ctrl);
+
+ if (ctrl->opp_table != NULL) {
This is usually written as
if (ctrl->opp_table)
+ dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.h
b/drivers/gpu/drm/msm/dp/dp_ctrl.h
index f60ba93c8678..19b412a93e02 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.h
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.h
@@ -31,6 +31,6 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev,
struct dp_link *link,
struct dp_panel *panel, struct drm_dp_aux
*aux,
struct dp_power *power, struct dp_catalog
*catalog,
struct dp_parser *parser);
-void dp_ctrl_put(struct dp_ctrl *dp_ctrl);
+void dp_ctrl_put(struct device *dev, struct dp_ctrl *dp_ctrl);
Is 'dev' not inside 'dp_ctrl'?
#endif /* _DP_CTRL_H_ */
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..3d75bf09e38f 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,49 @@ static int dp_power_clk_deinit(struct
dp_power_private *power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private
*power,
+ struct dss_clk *clk_arry, int num_clk, int
enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev,
rate);
Why do we keep going if rc is non-zero?
+ }
+
+ }
+ }
+ return rc;
+}
+
static int dp_power_clk_set_rate(struct dp_power_private *power,
enum dp_pm_type module, bool enable)
{
int rc = 0;
struct dss_module_power *mp = &power->parser->mp[module];
- if (enable) {
- rc = msm_dss_clk_set_rate(mp->clk_config,
mp->num_clk);
+ if (module == DP_CTRL_PM) {
+ rc = dp_power_clk_set
[PATCH] dt-bindings: mxsfb: Add compatible for i.MX8MM
NXP's i.MX8MM has an LCDIF as well. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Guido Günther Cc: Lucas Stach Cc: NXP Linux Team Cc: Rob Herring Cc: Shawn Guo --- Documentation/devicetree/bindings/display/mxsfb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt index c985871c46b3..f2f4a8189eda 100644 --- a/Documentation/devicetree/bindings/display/mxsfb.txt +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -6,6 +6,7 @@ Required properties: - compatible: Should be "fsl,imx23-lcdif" for i.MX23. Should be "fsl,imx28-lcdif" for i.MX28. Should be "fsl,imx6sx-lcdif" for i.MX6SX. + Should be "fsl,imx8mm-lcdif" for i.MX8MM. Should be "fsl,imx8mq-lcdif" for i.MX8MQ. - reg: Address and length of the register set for LCDIF - interrupts: Should contain LCDIF interrupt -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
Hi,
Le dim. 4 oct. 2020 à 21:59, Sam Ravnborg a écrit :
Hi Paul.
On Sun, Oct 04, 2020 at 04:17:58PM +0200, Paul Cercueil wrote:
This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
In the changelog please refer to commits like this:
37054fc81443 ("gpu/drm: ingenic: Add option to mmap GEM buffers
cached")
Use "dim cite 37054fc81443cc6a8c3a38395f384412b8373d82" to get the
right format.
At the very moment this commit was created, the DMA API it relied
on was
modified in the DMA tree, which caused the driver to break in
linux-next.
Revert it for now, and it will be resubmitted later to work with
the new
DMA API.
Signed-off-by: Paul Cercueil
With the changelog updated:
Acked-by: Sam Ravnborg
Pushed to drm-misc-next with the changelog fix, thanks.
Stephen:
Now it should build fine again. Could you remove the BROKEN flag?
Cheers,
-Paul
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114
+-
drivers/gpu/drm/ingenic/ingenic-drm.h | 4 -
drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 +--
3 files changed, 4 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 0225dc1f5eb8..7d8b0ad52979 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,8 +9,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -24,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -100,11 +97,6 @@ struct ingenic_drm {
struct notifier_block clock_nb;
};
-static bool ingenic_drm_cached_gem_buf;
-module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf,
bool, 0400);
-MODULE_PARM_DESC(cached_gem_buffers,
- "Enable fully cached GEM buffers [default=false]");
-
static bool ingenic_drm_writeable_reg(struct device *dev, unsigned
int reg)
{
switch (reg) {
@@ -402,8 +394,6 @@ static int
ingenic_drm_plane_atomic_check(struct drm_plane *plane,
plane->state->fb->format->format !=
state->fb->format->format))
crtc_state->mode_changed = true;
- drm_atomic_helper_check_plane_damage(state->state, state);
-
return 0;
}
@@ -521,38 +511,6 @@ void ingenic_drm_plane_config(struct device
*dev,
}
}
-void ingenic_drm_sync_data(struct device *dev,
- struct drm_plane_state *old_state,
- struct drm_plane_state *state)
-{
- const struct drm_format_info *finfo = state->fb->format;
- struct ingenic_drm *priv = dev_get_drvdata(dev);
- struct drm_atomic_helper_damage_iter iter;
- unsigned int offset, i;
- struct drm_rect clip;
- dma_addr_t paddr;
- void *addr;
-
- if (!ingenic_drm_cached_gem_buf)
- return;
-
- drm_atomic_helper_damage_iter_init(&iter, old_state, state);
-
- drm_atomic_for_each_plane_damage(&iter, &clip) {
- for (i = 0; i < finfo->num_planes; i++) {
- paddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
- addr = phys_to_virt(paddr);
-
- /* Ignore x1/x2 values, invalidate complete lines */
- offset = clip.y1 * state->fb->pitches[i];
-
- dma_cache_sync(priv->dev, addr + offset,
- (clip.y2 - clip.y1) *
state->fb->pitches[i],
- DMA_TO_DEVICE);
- }
- }
-}
-
static void ingenic_drm_update_palette(struct ingenic_drm *priv,
const struct drm_color_lut *lut)
{
@@ -581,8 +539,6 @@ static void
ingenic_drm_plane_atomic_update(struct drm_plane *plane,
if (state && state->fb) {
crtc_state = state->crtc->state;
- ingenic_drm_sync_data(priv->dev, oldstate, state);
-
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
@@ -752,69 +708,7 @@ static void ingenic_drm_disable_vblank(struct
drm_crtc *crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
JZ_LCD_CTRL_EOF_IRQ, 0);
}
-static struct drm_framebuffer *
-ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file
*file,
-const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- if (ingenic_drm_cached_gem_buf)
- return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
-
- return drm_gem_fb_create(dev, file, mode_cmd);
-}
-
-static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
- struct device *dev = cma_obj->base.dev->dev;
- unsigned long attrs;
-
Re: [PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
On 28-08-20, 11:37, Viresh Kumar wrote: > dev_pm_opp_of_remove_table() doesn't report any errors when it fails to > find the OPP table with error -ENODEV (i.e. OPP table not present for > the device). And we can call dev_pm_opp_of_remove_table() > unconditionally here. > > While at it, also create a label to put clkname. > > Signed-off-by: Viresh Kumar Can someone please apply this and the other drm patch (2/8) ? -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: bridge: dw-hdmi: Constify dw_hdmi_i2s_ops
The only usage of dw_hdmi_i2s_ops is to assign its address to the ops
field in the hdmi_codec_pdata struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index 9fef6413741d..feb04f127b55 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -170,7 +170,7 @@ static int dw_hdmi_i2s_hook_plugged_cb(struct device *dev,
void *data,
return dw_hdmi_set_plugged_cb(hdmi, fn, codec_dev);
}
-static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
+static const struct hdmi_codec_ops dw_hdmi_i2s_ops = {
.hw_params = dw_hdmi_i2s_hw_params,
.audio_startup = dw_hdmi_i2s_audio_startup,
.audio_shutdown = dw_hdmi_i2s_audio_shutdown,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
This reverts commit 37054fc81443cc6a8c3a38395f384412b8373d82.
At the very moment this commit was created, the DMA API it relied on was
modified in the DMA tree, which caused the driver to break in
linux-next.
Revert it for now, and it will be resubmitted later to work with the new
DMA API.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114 +-
drivers/gpu/drm/ingenic/ingenic-drm.h | 4 -
drivers/gpu/drm/ingenic/ingenic-ipu.c | 12 +--
3 files changed, 4 insertions(+), 126 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 0225dc1f5eb8..7d8b0ad52979 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,8 +9,6 @@
#include
#include
#include
-#include
-#include
#include
#include
#include
@@ -24,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -100,11 +97,6 @@ struct ingenic_drm {
struct notifier_block clock_nb;
};
-static bool ingenic_drm_cached_gem_buf;
-module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, bool, 0400);
-MODULE_PARM_DESC(cached_gem_buffers,
-"Enable fully cached GEM buffers [default=false]");
-
static bool ingenic_drm_writeable_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -402,8 +394,6 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
plane->state->fb->format->format != state->fb->format->format))
crtc_state->mode_changed = true;
- drm_atomic_helper_check_plane_damage(state->state, state);
-
return 0;
}
@@ -521,38 +511,6 @@ void ingenic_drm_plane_config(struct device *dev,
}
}
-void ingenic_drm_sync_data(struct device *dev,
- struct drm_plane_state *old_state,
- struct drm_plane_state *state)
-{
- const struct drm_format_info *finfo = state->fb->format;
- struct ingenic_drm *priv = dev_get_drvdata(dev);
- struct drm_atomic_helper_damage_iter iter;
- unsigned int offset, i;
- struct drm_rect clip;
- dma_addr_t paddr;
- void *addr;
-
- if (!ingenic_drm_cached_gem_buf)
- return;
-
- drm_atomic_helper_damage_iter_init(&iter, old_state, state);
-
- drm_atomic_for_each_plane_damage(&iter, &clip) {
- for (i = 0; i < finfo->num_planes; i++) {
- paddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
- addr = phys_to_virt(paddr);
-
- /* Ignore x1/x2 values, invalidate complete lines */
- offset = clip.y1 * state->fb->pitches[i];
-
- dma_cache_sync(priv->dev, addr + offset,
- (clip.y2 - clip.y1) *
state->fb->pitches[i],
- DMA_TO_DEVICE);
- }
- }
-}
-
static void ingenic_drm_update_palette(struct ingenic_drm *priv,
const struct drm_color_lut *lut)
{
@@ -581,8 +539,6 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
if (state && state->fb) {
crtc_state = state->crtc->state;
- ingenic_drm_sync_data(priv->dev, oldstate, state);
-
addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
width = state->src_w >> 16;
height = state->src_h >> 16;
@@ -752,69 +708,7 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
*crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
}
-static struct drm_framebuffer *
-ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- if (ingenic_drm_cached_gem_buf)
- return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
-
- return drm_gem_fb_create(dev, file, mode_cmd);
-}
-
-static int ingenic_drm_gem_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
-{
- struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
- struct device *dev = cma_obj->base.dev->dev;
- unsigned long attrs;
- int ret;
-
- if (ingenic_drm_cached_gem_buf)
- attrs = DMA_ATTR_NON_CONSISTENT;
- else
- attrs = DMA_ATTR_WRITE_COMBINE;
-
- /*
-* Clear the VM_PFNMAP flag that was set by drm_gem_mmap(), and set the
-* vm_pgoff (used as a fake buffer offset by DRM) to 0 as we want to map
-* the whole buffer.
-*/
- vma->vm_flags &= ~VM_PFNMAP;
- vma->vm_pgoff = 0;
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
-
- ret = dma_mmap_attrs(dev, vma, cma_obj->vaddr, cma_obj->paddr,
-vma->vm_end - vma-
RE: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training
From: Douglas AndersonSent: Friday, October 2, 2020 4:04 PMTo: Andrzej Hajda; Neil Armstrong; Sam RavnborgCc: Rob Clark; Bjorn Andersson; Steev Klimaszewski; Douglas Anderson; Daniel Vetter; David Airlie; Jernej Skrabec; Jonas Karlman; Laurent Pinchart; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.orgSubject: [PATCH] drm/bridge: ti-sn65dsi86: Add retries for link training On some panels hooked up to the ti-sn65dsi86 bridge chip we found thatlink training was failing. Specifically, we'd see: ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training failed, link is off (-5) The panel was hooked up to a logic analyzer and it was found that, aspart of link training, the bridge chip was writing a 0x1 to DPCDaddress 00600h and the panel responded NACK. As can be seen in headerfiles, the write of 0x1 to DPCD address 0x600h means we were trying towrite the value DP_SET_POWER_D0 to the register DP_SET_POWER. Thepanel vendor says that a NACK in this case is not unexpected and means"not ready, try again". In testing, we found that this panel would respond with a NACK inabout 1/25 times. Adding the retry logic worked fine and the mostnumber of tries needed was 3. Just to be safe, we'll add 10 trieshere and we'll add a little blurb to the logs if we ever need morethan 5. Signed-off-by: Douglas Anderson --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 40 +++ 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.cindex ecdf9b01340f..6e12cda69b54 100644--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c@@ -106,6 +106,8 @@ #define SN_NUM_GPIOS 4 #define SN_GPIO_PHYSICAL_OFFSET 1 +#define SN_LINK_TRAINING_TRIES 10+ /** * struct ti_sn_bridge - Platform data for ti-sn65dsi86 driver. * @dev: Pointer to our device.@@ -673,6 +675,7 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, { unsigned int val; int ret;+ int i; /* set dp clk frequency value */ regmap_update_bits(pdata->regmap, SN_DATARATE_CONFIG_REG,@@ -689,19 +692,34 @@ static int ti_sn_link_training(struct ti_sn_bridge *pdata, int dp_rate_idx, goto exit; } - /* Semi auto link training mode */- regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);- ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,- val == ML_TX_MAIN_LINK_OFF ||- val == ML_TX_NORMAL_MODE, 1000,- 500 * 1000);- if (ret) {- *last_err_str = "Training complete polling failed";- } else if (val == ML_TX_MAIN_LINK_OFF) {- *last_err_str = "Link training failed, link is off";- ret = -EIO;+ /*+ * We'll try to link train several times. As part of link training+ * the bridge chip will write DP_SET_POWER_D0 to DP_SET_POWER. If+ * the panel isn't ready quite it might respond NAK here which means+ * we need to try again.+ */+ for (i = 0; i < SN_LINK_TRAINING_TRIES; i++) {+ /* Semi auto link training mode */+ regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0x0A);+ ret = regmap_read_poll_timeout(pdata->regmap, SN_ML_TX_MODE_REG, val,+ val == ML_TX_MAIN_LINK_OFF ||+ val == ML_TX_NORMAL_MODE, 1000,+ 500 * 1000);+ if (ret) {+ *last_err_str = "Training complete polling failed";+ } else if (val == ML_TX_MAIN_LINK_OFF) {+ *last_err_str = "Link training failed, link is off";+ ret = -EIO;+ continue;+ }++ break; } + /* If we saw quite a few retries, add a note about it */+ if (!ret && i > SN_LINK_TRAINING_TRIES / 2)+ DRM_DEV_INFO(pdata->dev, "Link training needed %d retries\n", i);+ exit: /* Disable the PLL if we failed */ if (ret)-- 2.28.0.806.g8561365e88-goog Tested on the Lenovo C630, and haven’t seen the message, although I hadn’t seen the described issue before either.Tested-By: Steev Klimaszewski
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sat, Oct 03, 2020 at 03:52:32PM -0700, John Hubbard wrote:
> On 10/3/20 2:45 AM, Daniel Vetter wrote:
> > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
> > >
> > > On 10/2/20 10:53 AM, Daniel Vetter wrote:
> > > > For $reasons I've stumbled over this code and I'm not sure the change
> > > > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> > > > convert get_user_pages() --> pin_user_pages()") was entirely correct.
> > > >
> > > > This here is used for long term buffers (not just quick I/O) like
> > > > RDMA, and John notes this in his patch. But I thought the rule for
> > > > these is that they need to add FOLL_LONGTERM, which John's patch
> > > > didn't do.
> > >
> > > Yep. The earlier gup --> pup conversion patches were intended to not
> > > have any noticeable behavior changes, and FOLL_LONGTERM, with it's
> > > special cases and such, added some risk that I wasn't ready to take
> > > on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
> > > up. So there was some doubt at least in my mind, about which sites
> > > should have it.
> > >
> > > But now that we're here, I think it's really good that you've brought
> > > this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.
> >
> > So should I keep this patch, or will it collide with a series you're
> > working on?
>
> It doesn't collide with anything on my end yet, because I've been slow to
> pick up on the need for changing callsites to add FOLL_LONGTERM. :)
>
> And it looks like that's actually a problem, because:
>
> >
> > Also with the firmed up rules, correct that I can also drop the
> > vma_is_fsdax check when the FOLL_LONGTERM flag is set?
>
> That's the right direction to go *in general*, but I see that the
> pin_user_pages code is still a bit stuck in the past. And this patch
> won't actually work, with or without that vma_is_fsdax() check.
> Because:
>
> get_vaddr_frames(FOLL_LONGTERM)
>pin_user_pages_locked()
> if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
> return -EINVAL;
There is no particular reason this code needs to have the mm sem at
that point.
It should call pin_user_pages_fast() and only if that fails get the mmap
lock and extract the VMA to do broken hackery.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On Fri, 02 Oct 2020, Rob Herring wrote: > Another round of wack-a-mole. The json-schema default is additional > unknown properties are allowed, but for DT all properties should be > defined. > > Cc: Thierry Reding > Cc: Linus Walleij > Cc: Stephen Boyd > Cc: Shawn Guo > Cc: Bjorn Andersson > Cc: Baolin Wang > Cc: Guenter Roeck > Cc: Jonathan Cameron > Cc: Mauro Carvalho Chehab > Cc: Laurent Pinchart > Cc: Lee Jones > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Bjorn Helgaas > Cc: Vinod Koul > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Greg Kroah-Hartman > Cc: Daniel Lezcano > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-hw...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: openipmi-develo...@lists.sourceforge.net > Cc: linux-l...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-m...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: linux-ser...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Signed-off-by: Rob Herring > --- > > I'll take this thru the DT tree. [...] > .../bindings/mfd/gateworks-gsc.yaml | 2 ++ > .../bindings/mfd/xylon,logicvc.yaml | 14 +++-- Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
> Hi Robin,
>
> On 16/09/2020 01:51, Robin Murphy wrote:
> > According to a downstream commit I found in the Khadas vendor kernel,
> > the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
> > how to handle this properly) we should describe it as such. Otherwise
> > the mismatch leads to all manner of fun with mismatched attributes and
> > inadvertently snooping stale data from caches, which would account for
> > at least some of the brokenness observed on this platform.
> >
> > Signed-off-by: Robin Murphy
> > ---
> > arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> > b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> > index 9b8548e5f6e5..ee8fcae9f9f0 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> > @@ -135,3 +135,7 @@ map1 {
> > };
> > };
> > };
> > +
> > +&mali {
> > + dma-coherent;
> > +};
> >
>
> Thanks a lot for digging, I'll run a test to confirm it fixes the issue !
Sorry for the late reply. I triggered a dEQP run with this patch applied
and I see a bunch of "panfrost ffe4.gpu: matching BO is not heap type"
errors (see below for a full backtrace). That doesn't seem to happen when
we drop this dma-coherent property.
[ 690.945731] [ cut here ]
[ 690.950003] panfrost ffe4.gpu: matching BO is not heap type (GPU VA =
319a000)
[ 690.950051] WARNING: CPU: 0 PID: 120 at
drivers/gpu/drm/panfrost/panfrost_mmu.c:465
panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.968854] Modules linked in:
[ 690.971878] CPU: 0 PID: 120 Comm: irq/27-panfrost Tainted: GW
5.9.0-rc5-02434-g7d8109ec5a42 #784
[ 690.981964] Hardware name: Khadas VIM3 (DT)
[ 690.986107] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
[ 690.991627] pc : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.997232] lr : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.002836] sp : 800011bcbcd0
[ 691.006114] x29: 800011bcbcf0 x28: f3fe3800
[ 691.011375] x27: ceaf5350 x26: ca5fc500
[ 691.016636] x25: f32409c0 x24: 0001
[ 691.021897] x23: f3240880 x22: f3e3a800
[ 691.027159] x21: x20:
[ 691.032420] x19: 00010001 x18: 0020
[ 691.037681] x17: x16:
[ 691.042942] x15: f3fe3c70 x14:
[ 691.048204] x13: 8000116c2428 x12: 8000116c2086
[ 691.053466] x11: 800011bcbcd0 x10: 800011bcbcd0
[ 691.058727] x9 : fffe x8 :
[ 691.063988] x7 : 7420706165682074 x6 : 8000116c1816
[ 691.069249] x5 : x4 :
[ 691.074510] x3 : x2 : 8000e348c000
[ 691.079771] x1 : f1b91ff9af2df000 x0 :
[ 691.085033] Call trace:
[ 691.087452] panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.092712] irq_thread_fn+0x2c/0xa0
[ 691.096246] irq_thread+0x184/0x208
[ 691.099699] kthread+0x140/0x160
[ 691.102890] ret_from_fork+0x10/0x34
[ 691.106424] ---[ end trace b5dd8c2dfada8236 ]---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
> On 05/10/2020 09:15, Boris Brezillon wrote:
> > Hi Robin, Neil,
> >
> > On Wed, 16 Sep 2020 10:26:43 +0200
> > Neil Armstrong wrote:
> >
> >> Hi Robin,
> >>
> >> On 16/09/2020 01:51, Robin Murphy wrote:
> >>> According to a downstream commit I found in the Khadas vendor kernel,
> >>> the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
> >>> how to handle this properly) we should describe it as such. Otherwise
> >>> the mismatch leads to all manner of fun with mismatched attributes and
> >>> inadvertently snooping stale data from caches, which would account for
> >>> at least some of the brokenness observed on this platform.
> >>>
> >>> Signed-off-by: Robin Murphy
> >>> ---
> >>> arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
> >>> 1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> >>> b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> >>> index 9b8548e5f6e5..ee8fcae9f9f0 100644
> >>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> >>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
> >>> @@ -135,3 +135,7 @@ map1 {
> >>> };
> >>> };
> >>> };
> >>> +
> >>> +&mali {
> >>> + dma-coherent;
> >>> +};
> >>>
> >>
> >> Thanks a lot for digging, I'll run a test to confirm it fixes the issue !
> >
> > Sorry for the late reply. I triggered a dEQP run with this patch applied
> > and I see a bunch of "panfrost ffe4.gpu: matching BO is not heap type"
> > errors (see below for a full backtrace). That doesn't seem to happen when
> > we drop this dma-coherent property.
> >
> > [ 690.945731] [ cut here ]
> > [ 690.950003] panfrost ffe4.gpu: matching BO is not heap type (GPU VA
> > = 319a000)
> > [ 690.950051] WARNING: CPU: 0 PID: 120 at
> > drivers/gpu/drm/panfrost/panfrost_mmu.c:465
> > panfrost_mmu_irq_handler_thread+0x47c/0x650
> > [ 690.968854] Modules linked in:
> > [ 690.971878] CPU: 0 PID: 120 Comm: irq/27-panfrost Tainted: GW
> > 5.9.0-rc5-02434-g7d8109ec5a42 #784
> > [ 690.981964] Hardware name: Khadas VIM3 (DT)
> > [ 690.986107] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
> > [ 690.991627] pc : panfrost_mmu_irq_handler_thread+0x47c/0x650
> > [ 690.997232] lr : panfrost_mmu_irq_handler_thread+0x47c/0x650
> > [ 691.002836] sp : 800011bcbcd0
> > [ 691.006114] x29: 800011bcbcf0 x28: f3fe3800
> > [ 691.011375] x27: ceaf5350 x26: ca5fc500
> > [ 691.016636] x25: f32409c0 x24: 0001
> > [ 691.021897] x23: f3240880 x22: f3e3a800
> > [ 691.027159] x21: x20:
> > [ 691.032420] x19: 00010001 x18: 0020
> > [ 691.037681] x17: x16:
> > [ 691.042942] x15: f3fe3c70 x14:
> > [ 691.048204] x13: 8000116c2428 x12: 8000116c2086
> > [ 691.053466] x11: 800011bcbcd0 x10: 800011bcbcd0
> > [ 691.058727] x9 : fffe x8 :
> > [ 691.063988] x7 : 7420706165682074 x6 : 8000116c1816
> > [ 691.069249] x5 : x4 :
> > [ 691.074510] x3 : x2 : 8000e348c000
> > [ 691.079771] x1 : f1b91ff9af2df000 x0 :
> > [ 691.085033] Call trace:
> > [ 691.087452] panfrost_mmu_irq_handler_thread+0x47c/0x650
> > [ 691.092712] irq_thread_fn+0x2c/0xa0
> > [ 691.096246] irq_thread+0x184/0x208
> > [ 691.099699] kthread+0x140/0x160
> > [ 691.102890] ret_from_fork+0x10/0x34
> > [ 691.106424] ---[ end trace b5dd8c2dfada8236 ]---
> >
>
> It's quite possible this is caused by the GPU seeing a stale page table
> entry, so perhaps coherency isn't working as well as it should...
>
> Do you get an "Unhandled Page fault" message after this?
Yep (see below).
--->8---
[ 689.640491] [ cut here ]
[ 689.644754] panfrost ffe4.gpu: matching BO is not heap type (GPU VA =
3146000)
[ 689.644802] WARNING: CPU: 0 PID: 120 at
drivers/gpu/drm/panfrost/panfrost_mmu.c:465
panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 689.663607] Modules linked in:
[ 689.31] CPU: 0 PID: 120 Comm: irq/27-panfrost Tainted: GW
5.9.0-rc5-02434-g7d8109ec5a42 #784
[ 689.676717] Hardware name: Khadas VIM3 (DT)
[ 689.680860] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
[ 689.686380] pc : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 689.691987] lr : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 689.697590] sp : 800011bcbcd0
[ 689.700867] x29: 800011bcbcf0 x28: f3fe3800
[ 689.706128] x27: d89cf750 x26: da34a800
[ 689.711389] x25: f32409c0 x24: 0001
[ 689.716650] x23: f3240880 x22: d456e000
[ 689.721911] x21: x20:
[ 689.727173] x19: 00010001 x18: 0020
[
Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.
Signed-off-by: Robin Murphy
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 9b8548e5f6e5..ee8fcae9f9f0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -135,3 +135,7 @@ map1 {
};
};
};
+
+&mali {
+ dma-coherent;
+};
Thanks a lot for digging, I'll run a test to confirm it fixes the issue !
Sorry for the late reply. I triggered a dEQP run with this patch applied
and I see a bunch of "panfrost ffe4.gpu: matching BO is not heap type"
errors (see below for a full backtrace). That doesn't seem to happen when
we drop this dma-coherent property.
[ 690.945731] [ cut here ]
[ 690.950003] panfrost ffe4.gpu: matching BO is not heap type (GPU VA =
319a000)
[ 690.950051] WARNING: CPU: 0 PID: 120 at
drivers/gpu/drm/panfrost/panfrost_mmu.c:465
panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.968854] Modules linked in:
[ 690.971878] CPU: 0 PID: 120 Comm: irq/27-panfrost Tainted: GW
5.9.0-rc5-02434-g7d8109ec5a42 #784
[ 690.981964] Hardware name: Khadas VIM3 (DT)
[ 690.986107] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
[ 690.991627] pc : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.997232] lr : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.002836] sp : 800011bcbcd0
[ 691.006114] x29: 800011bcbcf0 x28: f3fe3800
[ 691.011375] x27: ceaf5350 x26: ca5fc500
[ 691.016636] x25: f32409c0 x24: 0001
[ 691.021897] x23: f3240880 x22: f3e3a800
[ 691.027159] x21: x20:
[ 691.032420] x19: 00010001 x18: 0020
[ 691.037681] x17: x16:
[ 691.042942] x15: f3fe3c70 x14:
[ 691.048204] x13: 8000116c2428 x12: 8000116c2086
[ 691.053466] x11: 800011bcbcd0 x10: 800011bcbcd0
[ 691.058727] x9 : fffe x8 :
[ 691.063988] x7 : 7420706165682074 x6 : 8000116c1816
[ 691.069249] x5 : x4 :
[ 691.074510] x3 : x2 : 8000e348c000
[ 691.079771] x1 : f1b91ff9af2df000 x0 :
[ 691.085033] Call trace:
[ 691.087452] panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.092712] irq_thread_fn+0x2c/0xa0
[ 691.096246] irq_thread+0x184/0x208
[ 691.099699] kthread+0x140/0x160
[ 691.102890] ret_from_fork+0x10/0x34
[ 691.106424] ---[ end trace b5dd8c2dfada8236 ]---
It's quite possible this is caused by the GPU seeing a stale page table
entry, so perhaps coherency isn't working as well as it should...
Do you get an "Unhandled Page fault" message after this? It might give
some clues. Coherency issues are a pain to debug though and it's of
course possible there are issues on this specific platform.
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent
On 05/10/2020 09:39, Boris Brezillon wrote:
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snooping stale data from caches, which would account for
at least some of the brokenness observed on this platform.
Signed-off-by: Robin Murphy
---
arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
index 9b8548e5f6e5..ee8fcae9f9f0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b.dtsi
@@ -135,3 +135,7 @@ map1 {
};
};
};
+
+&mali {
+ dma-coherent;
+};
Thanks a lot for digging, I'll run a test to confirm it fixes the issue !
Sorry for the late reply. I triggered a dEQP run with this patch applied
and I see a bunch of "panfrost ffe4.gpu: matching BO is not heap type"
errors (see below for a full backtrace). That doesn't seem to happen when
we drop this dma-coherent property.
[ 690.945731] [ cut here ]
[ 690.950003] panfrost ffe4.gpu: matching BO is not heap type (GPU VA =
319a000)
[ 690.950051] WARNING: CPU: 0 PID: 120 at
drivers/gpu/drm/panfrost/panfrost_mmu.c:465
panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.968854] Modules linked in:
[ 690.971878] CPU: 0 PID: 120 Comm: irq/27-panfrost Tainted: GW
5.9.0-rc5-02434-g7d8109ec5a42 #784
[ 690.981964] Hardware name: Khadas VIM3 (DT)
[ 690.986107] pstate: 6005 (nZCv daif -PAN -UAO BTYPE=--)
[ 690.991627] pc : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 690.997232] lr : panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.002836] sp : 800011bcbcd0
[ 691.006114] x29: 800011bcbcf0 x28: f3fe3800
[ 691.011375] x27: ceaf5350 x26: ca5fc500
[ 691.016636] x25: f32409c0 x24: 0001
[ 691.021897] x23: f3240880 x22: f3e3a800
[ 691.027159] x21: x20:
[ 691.032420] x19: 00010001 x18: 0020
[ 691.037681] x17: x16:
[ 691.042942] x15: f3fe3c70 x14:
[ 691.048204] x13: 8000116c2428 x12: 8000116c2086
[ 691.053466] x11: 800011bcbcd0 x10: 800011bcbcd0
[ 691.058727] x9 : fffe x8 :
[ 691.063988] x7 : 7420706165682074 x6 : 8000116c1816
[ 691.069249] x5 : x4 :
[ 691.074510] x3 : x2 : 8000e348c000
[ 691.079771] x1 : f1b91ff9af2df000 x0 :
[ 691.085033] Call trace:
[ 691.087452] panfrost_mmu_irq_handler_thread+0x47c/0x650
[ 691.092712] irq_thread_fn+0x2c/0xa0
[ 691.096246] irq_thread+0x184/0x208
[ 691.099699] kthread+0x140/0x160
[ 691.102890] ret_from_fork+0x10/0x34
[ 691.106424] ---[ end trace b5dd8c2dfada8236 ]---
It's quite possible this is caused by the GPU seeing a stale page table
entry, so perhaps coherency isn't working as well as it should...
Do you get an "Unhandled Page fault" message after this?
Yep (see below).
--->8---
[...]
[ 689.805864] panfrost ffe4.gpu: Unhandled Page fault in AS0 at VA
0x03146080
[ 689.805864] Reason: TODO
[ 689.805864] raw fault status: 0x10003C3
[ 689.805864] decoded fault status: SLAVE FAULT
[ 689.805864] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[ 689.805864] access type 0x3: WRITE
[ 689.805864] source id 0x100
[ 690.170419] panfrost ffe4.gpu: gpu sched timeout, js=1, config=0x7300,
status=0x8, head=0x3101100, tail=0x3101100, sched_job=4b442768
[ 690.770373] panfrost ffe4.gpu: error powering up gpu shader
[ 690.945123] panfrost ffe4.gpu: error powering up gpu shader
[ 690.945731] [ cut here ]
That's a write fault from level 3 of the page table triggered by shader
core 0 in a fragment job. So could be writing out the frame buffer.
It would be interesting to see if a patch like below would work round
it:
8<
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index e8f7b11352d2..5144860afdea 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -460,9 +460,12 @@ static int panfrost_mmu_map_fault_addr(struct
panfrost_device *pfdev, int as,
bo = bomapping->obj;
if (!bo->is_heap) {
- dev_WARN(pfdev->dev, "matching BO is not heap type (GPU VA =
%llx)",
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote: [...] > .../arm/tegra/nvidia,tegra20-pmc.yaml | 2 ++ [...] > .../bindings/sound/nvidia,tegra186-dspk.yaml | 2 ++ > .../sound/nvidia,tegra210-admaif.yaml | 2 ++ > .../bindings/sound/nvidia,tegra210-dmic.yaml | 2 ++ > .../bindings/sound/nvidia,tegra210-i2s.yaml | 2 ++ [...] > .../bindings/usb/nvidia,tegra-xudc.yaml | 2 ++ [...] Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user memory region
Hi Jianxin,
Am 04.10.20 um 21:12 schrieb Jianxin Xiong:
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buffer is registered as a memory region,
the file descriptor is passed to the RDMA driver along with other
parameters.
Implement the common code for importing dma-buf object and mapping
dma-buf pages.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
well first of all really nice work you have done here.
Since I'm not an expert on RDMA or its drivers I can't really review any
of that part.
But at least from the DMA-buf side it looks like you are using the
interface correctly as intended.
So feel free to add an Acked-by: Christian König
if it helps.
Thanks,
Christian.
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/umem.c| 4 +
drivers/infiniband/core/umem_dmabuf.c | 291 ++
drivers/infiniband/core/umem_dmabuf.h | 14 ++
drivers/infiniband/core/umem_odp.c| 12 ++
include/rdma/ib_umem.h| 19 ++-
6 files changed, 340 insertions(+), 2 deletions(-)
create mode 100644 drivers/infiniband/core/umem_dmabuf.c
create mode 100644 drivers/infiniband/core/umem_dmabuf.h
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index 24cb71a..b8d51a7 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
uverbs_cmd.o uverbs_marshall.o \
uverbs_std_types_srq.o \
uverbs_std_types_wq.o \
uverbs_std_types_qp.o
-ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
+ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 831bff8..59ec36c 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -2,6 +2,7 @@
* Copyright (c) 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Cisco Systems. All rights reserved.
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -42,6 +43,7 @@
#include
#include "uverbs.h"
+#include "umem_dmabuf.h"
static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int dirty)
{
@@ -318,6 +320,8 @@ void ib_umem_release(struct ib_umem *umem)
{
if (!umem)
return;
+ if (umem->is_dmabuf)
+ return ib_umem_dmabuf_release(umem);
if (umem->is_odp)
return ib_umem_odp_release(to_ib_umem_odp(umem));
diff --git a/drivers/infiniband/core/umem_dmabuf.c b/drivers/infiniband/core/umem_dmabuf.c
new file mode 100644
index 000..10ed646
--- /dev/null
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "uverbs.h"
+
+struct ib_umem_dmabuf {
+ struct ib_umem_odp umem_odp;
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ atomic_t notifier_seq;
+};
+
+static inline struct ib_umem_dmabuf *to_ib_umem_dmabuf(struct ib_umem *umem)
+{
+ struct ib_umem_odp *umem_odp = to_ib_umem_odp(umem);
+ return container_of(umem_odp, struct ib_umem_dmabuf, umem_odp);
+}
+
+static void ib_umem_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
+{
+ struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
+ struct ib_umem_odp *umem_odp = &umem_dmabuf->umem_odp;
+ struct mmu_notifier_range range = {};
+ unsigned long current_seq;
+
+ /* no concurrent invalidation due to the dma_resv lock */
+
+ dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
+
+ if (!umem_dmabuf->sgt)
+ return;
+
+ range.start = ib_umem_start(umem_odp);
+ range.end = ib_umem_end(umem_odp);
+ range.flags = MMU_NOTIFIER_RANGE_BLOCKABLE;
+ current_seq = atomic_read(&umem_dmabuf->notifier_seq);
+ umem_odp->notifier.ops->invalidate(&umem_odp->notifier, &range,
+ current_seq);
+
+ atomic_inc(&umem_dmabuf->notifier_seq);
+}
+
+static struct dma_buf_attach_ops ib_umem_dmabuf_attach_ops = {
+ .allow_peer2peer = 1,
+ .move_notify = ib_umem_dmabuf_i
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote: > Another round of wack-a-mole. The json-schema default is additional > unknown properties are allowed, but for DT all properties should be > defined. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
Hi Paul, On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil wrote: > > Pushed to drm-misc-next with the changelog fix, thanks. > > Stephen: > Now it should build fine again. Could you remove the BROKEN flag? Thanks for letting me know, but the fix has not appeared in any drm tree included in linux-next yet ... If it doesn't show up by the time I will merge the drm tree tomorrow, I will apply this revert patch myself (instead of the patch marking the driver BROKEN). -- Cheers, Stephen Rothwell pgpu0Xm2WahXl.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm: commit_work scheduling
On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä > wrote: > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > > > > > > > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter wrote: > > > > > > > > > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark > > > > > > wrote: > > > > > > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > The android userspace treats the display pipeline as a realtime > > > > > > > problem. > > > > > > > And arguably, if your goal is to not miss frame deadlines (ie. > > > > > > > vblank), > > > > > > > it is. (See https://lwn.net/Articles/809545/ for the best > > > > > > > explaination > > > > > > > that I found.) > > > > > > > > > > > > > > But this presents a problem with using workqueues for non-blocking > > > > > > > atomic commit_work(), because the SCHED_FIFO userspace thread(s) > > > > > > > can > > > > > > > preempt the worker. Which is not really the outcome you want.. > > > > > > > once > > > > > > > the required fences are scheduled, you want to push the atomic > > > > > > > commit > > > > > > > down to hw ASAP. > > > > > > > > > > > > > > But the decision of whether commit_work should be RT or not really > > > > > > > depends on what userspace is doing. For a pure CFS userspace > > > > > > > display > > > > > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > > > > > > > > > To handle this, convert non-blocking commit_work() to use per-CRTC > > > > > > > kthread workers, instead of system_unbound_wq. Per-CRTC workers > > > > > > > are > > > > > > > used to avoid serializing commits when userspace is using a > > > > > > > per-CRTC > > > > > > > update loop. And the last patch exposes the task id to userspace > > > > > > > as > > > > > > > a CRTC property, so that userspace can adjust the priority and > > > > > > > sched > > > > > > > policy to fit it's needs. > > > > > > > > > > > > > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > > > > > favor of exposing the kworker tid to userspace so that user- > > > > > > > space can set priority/policy. > > > > > > > > > > > > Yeah I think this looks more reasonable. Still a bit irky interface, > > > > > > so I'd like to get some kworker/rt ack on this. Other opens: > > > > > > - needs userspace, the usual drill > > > > > > > > > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > > > > > userspace will become a standalone helper or daemon, mostly because > > > > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm > > > > > still entertaining the possibility of switching between rt and cfs > > > > > depending on what is in the foreground (ie. only do rt for android > > > > > apps). > > > > > > > > > > > - we need this also for vblank workers, otherwise this wont work for > > > > > > drivers needing those because of another priority inversion. > > > > > > > > > > I have a thought on that, see below.. > > > > > > > > Hm, not seeing anything about vblank worker below? > > > > > > > > > > - we probably want some indication of whether this actually does > > > > > > something useful, not all drivers use atomic commit helpers. Not > > > > > > sure > > > > > > how to do that. > > > > > > > > > > I'm leaning towards converting the other drivers over to use the > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic state. > > > > > I can add a patch to that, but figured I could postpone that churn > > > > > until there is some by-in on this whole idea. > > > > > > > > i915 has its own commit code, it's not even using the current commit > > > > helpers (nor the commit_work). Not sure how much other fun there is. > > > > > > I don't think we want per-crtc threads for this in i915. Seems > > > to me easier to guarantee atomicity across multiple crtcs if > > > we just commit them from the same thread. > > > > Oh, and we may have to commit things in a very specific order > > to guarantee the hw doesn't fall over, so yeah definitely per-crtc > > thread is a no go. > > If I'm understanding the i915 code, this is only the case for modeset > commits? I suppose we could achieve the same result by just deciding > to pick the kthread of the first CRTC for modeset commits. I'm not > really so much concerned about parallelism for modeset. I'm not entirely happy about the random differences between modesets and other commits. Ideally we wouldn't need any. Anyways, even if we ignore modesets we still have the issue with atomicity guarantees across multiple crtcs. So I think we still don't want per-crtc threads, rather it should be thread for each commit. Well, if the crtcs aren't running in lockstep then maybe we could shove them off to separate threads, but that'll just complicate things needlessly
Re: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE
Ping? Bunch of trivial cleanups and removal of the caching placement flags. Any comments on this? Thanks, Christian. Am 01.10.20 um 13:28 schrieb Christian König: Not used any more. Signed-off-by: Christian König --- include/drm/ttm/ttm_tt.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index 91691240a509..5d1835d44084 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -34,7 +34,6 @@ struct ttm_resource; struct ttm_buffer_object; struct ttm_operation_ctx; -#define TTM_PAGE_FLAG_WRITE (1 << 3) #define TTM_PAGE_FLAG_SWAPPED (1 << 4) #define TTM_PAGE_FLAG_ZERO_ALLOC (1 << 6) #define TTM_PAGE_FLAG_DMA32 (1 << 7) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display
On Sat, Oct 03, 2020 at 04:58:51AM +, Chrisanthus, Anitha wrote: > > > > -Original Message- > > From: Daniel Vetter > > Sent: Friday, October 2, 2020 2:19 AM > > To: Chrisanthus, Anitha > > Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J > > ; Dea, Edmund J ; > > Vetter, Daniel > > Subject: Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay Display > > > > On Thu, Oct 1, 2020 at 8:02 PM Chrisanthus, Anitha > > wrote: > > > > > > Hi Daniel, > > > I was finally able to test the driver with 5.9 kernel with minor changes > > > in > > the driver. > > > Ran the igt_vblank test and it passed/skipped all the subtests except the > > pipe-A-accuracy-idle test. > > > Results are attached. Investigated the failing test and it seems like > > drm_handle_vblank() is taking too long sometimes. I can work on this after > > we merge. > > > > kms_flip is the one that should check whether vblank events and page > > flip events agree. Which I think isn't the case with your current > > code. > Thanks. I will run that test and work on the failures. I did send v8 > with 5.9 testing changes today and also sent the YAML file v1 today to > devicet...@vger.kernel.org, not sure if I should cc dri-devel,, should > I? I think usually people send out the entire series, first device tree yaml, then bindings, then drivers, to everyone. It helps with context I think (But I don't review dt stuff myself). -Daniel > > Anitha > > -Daniel > > > > > > > > Will send out V8 with the minor changes and device tree YAML binding > > file ASAP. Will work on the rest of the review comments after. > > > > > > Thanks, > > > Anitha > > > > > > > From: Daniel Vetter > > > > Sent: Thursday, September 10, 2020 1:31 AM > > > > To: Chrisanthus, Anitha > > > > Cc: dri-devel@lists.freedesktop.org; Paauwe, Bob J > > > > ; Dea, Edmund J ; > > > > Vetter, Daniel > > > > Subject: Re: [PATCH v7 2/4] drm/kmb: Add support for KeemBay > > Display > > > > > > > > On Mon, Aug 31, 2020 at 01:02:50PM -0700, Anitha Chrisanthus > > wrote: > > > > > This is a basic KMS atomic modesetting display driver for KeemBay > > family > > > > of > > > > > SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge > > > > > driver at the connector level. > > > > > > > > > > Single CRTC with LCD controller->mipi DSI-> ADV bridge > > > > > > > > > > Only 1080p resolution and single plane is supported at this time. > > > > > > > > > > v2: moved extern to .h, removed license text > > > > > use drm_dev_init, upclassed dev_private, removed > > HAVE_IRQ.(Sam) > > > > > > > > > > v3: Squashed all 59 commits to one > > > > > > > > > > v4: review changes from Sam Ravnborg > > > > > renamed dev_p to kmb > > > > > moved clocks under kmb_clock, consolidated clk initializations > > > > > use drmm functions > > > > > use DRM_GEM_CMA_DRIVER_OPS_VMAP > > > > > > > > > > v5: corrected spellings > > > > > v6: corrected checkpatch warnings > > > > > v7: review changes Sam Ravnborg and Thomas Zimmerman > > > > > removed kmb_crtc.h kmb_crtc_cleanup (Thomas) > > > > > renamed mode_set, kmb_load, inlined unload (Thomas) > > > > > moved remaining logging to drm_*(Thomas) > > > > > re-orged driver initialization (Thomas) > > > > > moved plane_status to drm_private (Sam) > > > > > removed unnecessary logs and defines and ifdef codes (Sam) > > > > > call helper_check in plane_atomic_check (Sam) > > > > > renamed set to get for bpp and format functions(Sam) > > > > > use drm helper functions for reset, duplicate/destroy state > > > > > instead > > > > > of kmb functions (Sam) > > > > > removed kmb_priv from kmb_plane and removed > > kmb_plane_state > > > > (Sam) > > > > > > > > > > Cc: Sam Ravnborg > > > > > Signed-off-by: Anitha Chrisanthus > > > > > Reviewed-by: Bob Paauwe > > > > > > > > Sam asked me to take a look at this too, looks reasonable overall. I've > > > > spotted a few small things plus a potential functional issue around > > > > vblank/event handling. I strongly recommend running the igt test suite > > > > over the driver to see whether it all works reasonably ok. See below for > > > > details. > > > > > > > > > --- > > > > > drivers/gpu/drm/kmb/kmb_crtc.c | 224 + > > > > > drivers/gpu/drm/kmb/kmb_drv.c | 676 > > > > > > > > > drivers/gpu/drm/kmb/kmb_drv.h | 170 ++ > > > > > drivers/gpu/drm/kmb/kmb_plane.c | 480 > > > > > > > > > drivers/gpu/drm/kmb/kmb_plane.h | 110 +++ > > > > > 5 files changed, 1660 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c > > > > > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c > > > > > create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h > > > > > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c > > > > > create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h > > > > > > > > > > diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c > > > > b/driver
Re: [PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells
On Wed, 30 Sep 2020 17:35:31 -0500, Bjorn Andersson wrote:
> While the signal on GPIO4 to drive the backlight controller indeed is
> pulse width modulated its purpose is specifically to control the
> brightness of a backlight.
>
> Drop the #pwm-cells and instead expose a new property to configure the
> granularity of the backlight PWM signal.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml:
properties:ti,backlight-scale: {'description': 'The granularity of brightness
for the PWM signal provided on GPIO4, if this property is specified.',
'minimum': 0, 'maximum': 65535} is not valid under any of the given schemas
(Possible causes of the failure):
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml:
properties:ti,backlight-scale: 'not' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml:
ignoring, error in schema: properties: ti,backlight-scale
warning: no schema found in file:
./Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
See https://patchwork.ozlabs.org/patch/1374751
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
--upgrade
Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: fix double free of gma_connector
On Sat, Oct 03, 2020 at 12:39:28PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis reports this problem:
>
> cdv_intel_dp.c:2101:2: warning: Attempt to free released memory
> kfree(gma_connector);
> ^~~~
>
> In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off()
> fails, the handler calls cdv_intel_dp_destroy(connector) which does
> the first free of gma_connector. So adjust the goto label and skip
> the second free.
>
> Fixes: d112a8163f83 ("gma500/cdv: Add eDP support")
> Signed-off-by: Tom Rix
Thanks for your patch, queued in drm-misc-next for 5.11.
-Daniel
> ---
> drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> index 720a767118c9..deb4fd13591d 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
> @@ -2083,7 +2083,7 @@ cdv_intel_dp_init(struct drm_device *dev, struct
> psb_intel_mode_device *mode_dev
> DRM_INFO("failed to retrieve link info, disabling
> eDP\n");
> drm_encoder_cleanup(encoder);
> cdv_intel_dp_destroy(connector);
> - goto err_priv;
> + goto err_connector;
> } else {
> DRM_DEBUG_KMS("DPCD: Rev=%x LN_Rate=%x LN_CNT=%x
> LN_DOWNSP=%x\n",
> intel_dp->dpcd[0], intel_dp->dpcd[1],
> --
> 2.18.1
>
--
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 07/14] drm/msm: Refcount submits
On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Before we remove dev->struct_mutex from the retire path, we have to deal
> with the situation of a submit retiring before the submit ioctl returns.
>
> To deal with this, ring->submits will hold a reference to the submit,
> which is dropped when the submit is retired. And the submit ioctl path
> holds it's own ref, which it drops when it is done with the submit.
>
> Also, add to submit list *after* getting/pinning bo's, to prevent badness
> in case the completed fence is corrupted, and retire_worker mistakenly
> believes the submit is done too early.
>
> Signed-off-by: Rob Clark
Why not embed the dma_fence instead of pointer and use that refcount? i915
does that, and imo kinda makes sense instead of more refcounted things.
But might not make sense for msm.
-Daniel
> ---
> drivers/gpu/drm/msm/msm_drv.h| 1 -
> drivers/gpu/drm/msm/msm_gem.h| 13 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 12 ++--
> drivers/gpu/drm/msm/msm_gpu.c| 21 -
> 4 files changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 50978e5db376..535f9e718e2d 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -277,7 +277,6 @@ void msm_unregister_mmu(struct drm_device *dev, struct
> msm_mmu *mmu);
>
> bool msm_use_mmu(struct drm_device *dev);
>
> -void msm_gem_submit_free(struct msm_gem_submit *submit);
> int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
> struct drm_file *file);
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index a1bf741b9b89..e05b1530aca6 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -136,6 +136,7 @@ void msm_gem_free_work(struct work_struct *work);
> * lasts for the duration of the submit-ioctl.
> */
> struct msm_gem_submit {
> + struct kref ref;
> struct drm_device *dev;
> struct msm_gpu *gpu;
> struct msm_gem_address_space *aspace;
> @@ -169,6 +170,18 @@ struct msm_gem_submit {
> } bos[];
> };
>
> +void __msm_gem_submit_destroy(struct kref *kref);
> +
> +static inline void msm_gem_submit_get(struct msm_gem_submit *submit)
> +{
> + kref_get(&submit->ref);
> +}
> +
> +static inline void msm_gem_submit_put(struct msm_gem_submit *submit)
> +{
> + kref_put(&submit->ref, __msm_gem_submit_destroy);
> +}
> +
> /* helper to determine of a buffer in submit should be dumped, used for both
> * devcoredump and debugfs cmdstream dumping:
> */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index e1d1f005b3d4..7d653bdc92dc 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -42,6 +42,7 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> if (!submit)
> return NULL;
>
> + kref_init(&submit->ref);
> submit->dev = dev;
> submit->aspace = queue->ctx->aspace;
> submit->gpu = gpu;
> @@ -60,12 +61,12 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return submit;
> }
>
> -void msm_gem_submit_free(struct msm_gem_submit *submit)
> +void __msm_gem_submit_destroy(struct kref *kref)
> {
> + struct msm_gem_submit *submit =
> + container_of(kref, struct msm_gem_submit, ref);
> +
> dma_fence_put(submit->fence);
> - spin_lock(&submit->ring->submit_lock);
> - list_del(&submit->node);
> - spin_unlock(&submit->ring->submit_lock);
> put_pid(submit->pid);
> msm_submitqueue_put(submit->queue);
>
> @@ -805,8 +806,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> submit_cleanup(submit);
> if (has_ww_ticket)
> ww_acquire_fini(&submit->ticket);
> - if (ret)
> - msm_gem_submit_free(submit);
> + msm_gem_submit_put(submit);
> out_unlock:
> if (ret && (out_fence_fd >= 0))
> put_unused_fd(out_fence_fd);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 8d1e254f964a..fd3fc6f36ab1 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -712,7 +712,12 @@ static void retire_submit(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
>
> pm_runtime_mark_last_busy(&gpu->pdev->dev);
> pm_runtime_put_autosuspend(&gpu->pdev->dev);
> - msm_gem_submit_free(submit);
> +
> + spin_lock(&ring->submit_lock);
> + list_del(&submit->node);
> + spin_unlock(&ring->submit_lock);
> +
> + msm_gem_submit_put(submit);
> }
>
> static void retire_submits(struct msm_gpu *gpu)
> @@ -786,10 +791,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
>
> submit->seqno = ++ring->seqno;
>
> - spin_l
Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path
On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
>
> On Sun, 4 Oct 2020 12:21:45
> > From: Rob Clark
> >
> > Now that the inactive_list is protected by mm_lock, and everything
> > else on per-obj basis is protected by obj->lock, we no longer depend
> > on struct_mutex.
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_gem.c | 1 -
> > drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
> > 2 files changed, 55 deletions(-)
> >
> [...]
>
> > @@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct
> > shrink_control *sc)
> > {
> > struct msm_drm_private *priv =
> > container_of(shrinker, struct msm_drm_private, shrinker);
> > - struct drm_device *dev = priv->dev;
> > struct msm_gem_object *msm_obj;
> > unsigned long freed = 0;
> > - bool unlock;
> > -
> > - if (!msm_gem_shrinker_lock(dev, &unlock))
> > - return SHRINK_STOP;
> >
> > mutex_lock(&priv->mm_lock);
>
> Better if the change in behavior is documented that SHRINK_STOP will
> no longer be needed.
btw I read through this and noticed you have your own obj lock, plus
mutex_lock_nested. I strongly recommend to just cut over to dma_resv_lock
for all object lock needs (soc drivers have been terrible with this
unfortuntaly), and in the shrinker just use dma_resv_trylock instead of
trying to play clever games outsmarting lockdep.
I recently wrote an entire blog length rant on why I think
mutex_lock_nested is too dangerous to be useful:
https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
Not anything about this here, just general comment. The problem extends to
shmem helpers and all that also having their own locks for everything.
-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] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
On Mon, Oct 05, 2020 at 11:01:50PM +1100, Stephen Rothwell wrote: > Hi Paul, > > On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil wrote: > > > > Pushed to drm-misc-next with the changelog fix, thanks. > > > > Stephen: > > Now it should build fine again. Could you remove the BROKEN flag? > > Thanks for letting me know, but the fix has not appeared in any drm > tree included in linux-next yet ... > > If it doesn't show up by the time I will merge the drm tree tomorrow, I > will apply this revert patch myself (instead of the patch marking the > driver BROKEN). Yeah it should have been pushed to drm-misc-next-fixes per https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch Paul, can you pls git cherry-pick -x this over to drm-misc-next-fixes? Thanks, 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] drm: bridge: dw-hdmi: Constify dw_hdmi_i2s_ops
On Sun, Oct 04, 2020 at 10:06:53PM +0200, Rikard Falkeborn wrote:
> The only usage of dw_hdmi_i2s_ops is to assign its address to the ops
> field in the hdmi_codec_pdata struct, which is a const pointer. Make it
> const to allow the compiler to put it in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
Queued up in drm-misc-next for 5.11, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> index 9fef6413741d..feb04f127b55 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -170,7 +170,7 @@ static int dw_hdmi_i2s_hook_plugged_cb(struct device
> *dev, void *data,
> return dw_hdmi_set_plugged_cb(hdmi, fn, codec_dev);
> }
>
> -static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
> +static const struct hdmi_codec_ops dw_hdmi_i2s_ops = {
> .hw_params = dw_hdmi_i2s_hw_params,
> .audio_startup = dw_hdmi_i2s_audio_startup,
> .audio_shutdown = dw_hdmi_i2s_audio_shutdown,
> --
> 2.28.0
>
--
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 v2 0/3] drm: commit_work scheduling
On Mon, Oct 05, 2020 at 03:15:24PM +0300, Ville Syrjälä wrote: > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote: > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä > > wrote: > > > > > > On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote: > > > > On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote: > > > > > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark wrote: > > > > > > > > > > > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark > > > > > > > wrote: > > > > > > > > > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > The android userspace treats the display pipeline as a realtime > > > > > > > > problem. > > > > > > > > And arguably, if your goal is to not miss frame deadlines (ie. > > > > > > > > vblank), > > > > > > > > it is. (See https://lwn.net/Articles/809545/ for the best > > > > > > > > explaination > > > > > > > > that I found.) > > > > > > > > > > > > > > > > But this presents a problem with using workqueues for > > > > > > > > non-blocking > > > > > > > > atomic commit_work(), because the SCHED_FIFO userspace > > > > > > > > thread(s) can > > > > > > > > preempt the worker. Which is not really the outcome you want.. > > > > > > > > once > > > > > > > > the required fences are scheduled, you want to push the atomic > > > > > > > > commit > > > > > > > > down to hw ASAP. > > > > > > > > > > > > > > > > But the decision of whether commit_work should be RT or not > > > > > > > > really > > > > > > > > depends on what userspace is doing. For a pure CFS userspace > > > > > > > > display > > > > > > > > pipeline, commit_work() should remain SCHED_NORMAL. > > > > > > > > > > > > > > > > To handle this, convert non-blocking commit_work() to use > > > > > > > > per-CRTC > > > > > > > > kthread workers, instead of system_unbound_wq. Per-CRTC > > > > > > > > workers are > > > > > > > > used to avoid serializing commits when userspace is using a > > > > > > > > per-CRTC > > > > > > > > update loop. And the last patch exposes the task id to > > > > > > > > userspace as > > > > > > > > a CRTC property, so that userspace can adjust the priority and > > > > > > > > sched > > > > > > > > policy to fit it's needs. > > > > > > > > > > > > > > > > > > > > > > > > v2: Drop client cap and in-kernel setting of priority/policy in > > > > > > > > favor of exposing the kworker tid to userspace so that user- > > > > > > > > space can set priority/policy. > > > > > > > > > > > > > > Yeah I think this looks more reasonable. Still a bit irky > > > > > > > interface, > > > > > > > so I'd like to get some kworker/rt ack on this. Other opens: > > > > > > > - needs userspace, the usual drill > > > > > > > > > > > > fwiw, right now the userspace is "modetest + chrt".. *probably* the > > > > > > userspace will become a standalone helper or daemon, mostly because > > > > > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. > > > > > > I'm > > > > > > still entertaining the possibility of switching between rt and cfs > > > > > > depending on what is in the foreground (ie. only do rt for android > > > > > > apps). > > > > > > > > > > > > > - we need this also for vblank workers, otherwise this wont work > > > > > > > for > > > > > > > drivers needing those because of another priority inversion. > > > > > > > > > > > > I have a thought on that, see below.. > > > > > > > > > > Hm, not seeing anything about vblank worker below? > > > > > > > > > > > > - we probably want some indication of whether this actually does > > > > > > > something useful, not all drivers use atomic commit helpers. Not > > > > > > > sure > > > > > > > how to do that. > > > > > > > > > > > > I'm leaning towards converting the other drivers over to use the > > > > > > per-crtc kwork, and then dropping the 'commit_work` from atomic > > > > > > state. > > > > > > I can add a patch to that, but figured I could postpone that churn > > > > > > until there is some by-in on this whole idea. > > > > > > > > > > i915 has its own commit code, it's not even using the current commit > > > > > helpers (nor the commit_work). Not sure how much other fun there is. > > > > > > > > I don't think we want per-crtc threads for this in i915. Seems > > > > to me easier to guarantee atomicity across multiple crtcs if > > > > we just commit them from the same thread. > > > > > > Oh, and we may have to commit things in a very specific order > > > to guarantee the hw doesn't fall over, so yeah definitely per-crtc > > > thread is a no go. > > > > If I'm understanding the i915 code, this is only the case for modeset > > commits? I suppose we could achieve the same result by just deciding > > to pick the kthread of the first CRTC for modeset commits. I'm not > > really so much concerned about parallelism for modeset. > > I'm not entirely happy about the random differences between modesets > and other commits. Id
Re: [Freedreno] [PATCH 02/14] drm/msm: Drop chatty trace
On Sun, Oct 04, 2020 at 12:21:34PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> It is somewhat redundant with the gpu tracepoints, and anyways not too
> useful to justify spamming the log when debug traces are enabled.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 55d16489d0f3..31fce3ac0cdc 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -535,7 +535,6 @@ static void recover_worker(struct work_struct *work)
>
> static void hangcheck_timer_reset(struct msm_gpu *gpu)
> {
> - DBG("%s", gpu->name);
> mod_timer(&gpu->hangcheck_timer,
> round_jiffies_up(jiffies + DRM_MSM_HANGCHECK_JIFFIES));
> }
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 03/14] drm/msm: Move update_fences()
On Sun, Oct 04, 2020 at 12:21:35PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Small cleanup, update_fences() is used in the hangcheck path, but also
> in the normal retire path.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 31fce3ac0cdc..ca8c95b32c8b 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -265,6 +265,20 @@ int msm_gpu_hw_init(struct msm_gpu *gpu)
> return ret;
> }
>
> +static void update_fences(struct msm_gpu *gpu, struct msm_ringbuffer *ring,
> + uint32_t fence)
> +{
> + struct msm_gem_submit *submit;
> +
> + list_for_each_entry(submit, &ring->submits, node) {
> + if (submit->seqno > fence)
> + break;
> +
> + msm_update_fence(submit->ring->fctx,
> + submit->fence->seqno);
> + }
> +}
> +
> #ifdef CONFIG_DEV_COREDUMP
> static ssize_t msm_gpu_devcoredump_read(char *buffer, loff_t offset,
> size_t count, void *data, size_t datalen)
> @@ -411,20 +425,6 @@ static void msm_gpu_crashstate_capture(struct msm_gpu
> *gpu,
> * Hangcheck detection for locked gpu:
> */
>
> -static void update_fences(struct msm_gpu *gpu, struct msm_ringbuffer *ring,
> - uint32_t fence)
> -{
> - struct msm_gem_submit *submit;
> -
> - list_for_each_entry(submit, &ring->submits, node) {
> - if (submit->seqno > fence)
> - break;
> -
> - msm_update_fence(submit->ring->fctx,
> - submit->fence->seqno);
> - }
> -}
> -
> static struct msm_gem_submit *
> find_submit(struct msm_ringbuffer *ring, uint32_t fence)
> {
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 04/14] drm/msm: Add priv->mm_lock to protect active/inactive lists
On Sun, Oct 04, 2020 at 12:21:36PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Rather than relying on the big dev->struct_mutex hammer, introduce a
> more specific lock for protecting the bo lists.
Most excellent.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
> drivers/gpu/drm/msm/msm_drv.c | 1 +
> drivers/gpu/drm/msm/msm_drv.h | 13 +++-
> drivers/gpu/drm/msm/msm_gem.c | 28 +++---
> drivers/gpu/drm/msm/msm_gem_shrinker.c | 12 +++
> drivers/gpu/drm/msm/msm_gpu.h | 5 -
> 6 files changed, 52 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
> b/drivers/gpu/drm/msm/msm_debugfs.c
> index ee2e270f464c..64afbed89821 100644
> --- a/drivers/gpu/drm/msm/msm_debugfs.c
> +++ b/drivers/gpu/drm/msm/msm_debugfs.c
> @@ -112,6 +112,11 @@ static int msm_gem_show(struct drm_device *dev, struct
> seq_file *m)
> {
> struct msm_drm_private *priv = dev->dev_private;
> struct msm_gpu *gpu = priv->gpu;
> + int ret;
> +
> + ret = mutex_lock_interruptible(&priv->mm_lock);
> + if (ret)
> + return ret;
>
> if (gpu) {
> seq_printf(m, "Active Objects (%s):\n", gpu->name);
> @@ -121,6 +126,8 @@ static int msm_gem_show(struct drm_device *dev, struct
> seq_file *m)
> seq_printf(m, "Inactive Objects:\n");
> msm_gem_describe_objects(&priv->inactive_list, m);
>
> + mutex_unlock(&priv->mm_lock);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 49685571dc0e..dc6efc089285 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -441,6 +441,7 @@ static int msm_drm_init(struct device *dev, struct
> drm_driver *drv)
> init_llist_head(&priv->free_list);
>
> INIT_LIST_HEAD(&priv->inactive_list);
> + mutex_init(&priv->mm_lock);
>
> drm_mode_config_init(ddev);
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index b9dd8f8f4887..50978e5db376 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -174,8 +174,19 @@ struct msm_drm_private {
> struct msm_rd_state *hangrd; /* debugfs to dump hanging submits */
> struct msm_perf_state *perf;
>
> - /* list of GEM objects: */
> + /*
> + * List of inactive GEM objects. Every bo is either in the
> inactive_list
> + * or gpu->active_list (for the gpu it is active on[1])
> + *
> + * These lists are protected by mm_lock. If struct_mutex is involved,
> it
> + * should be aquired prior to mm_lock. One should *not* hold mm_lock in
> + * get_pages()/vmap()/etc paths, as they can trigger the shrinker.
> + *
> + * [1] if someone ever added support for the old 2d cores, there could
> be
> + * more than one gpu object
> + */
> struct list_head inactive_list;
> + struct mutex mm_lock;
>
> /* worker for delayed free of objects: */
> struct work_struct free_work;
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index a870b3ad129d..b04ed8b52f9d 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -746,13 +746,17 @@ int msm_gem_sync_object(struct drm_gem_object *obj,
> void msm_gem_active_get(struct drm_gem_object *obj, struct msm_gpu *gpu)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> - WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
> + struct msm_drm_private *priv = obj->dev->dev_private;
> +
> + might_sleep();
> WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
>
> if (!atomic_fetch_inc(&msm_obj->active_count)) {
> + mutex_lock(&priv->mm_lock);
> msm_obj->gpu = gpu;
> list_del_init(&msm_obj->mm_list);
> list_add_tail(&msm_obj->mm_list, &gpu->active_list);
> + mutex_unlock(&priv->mm_lock);
> }
> }
>
> @@ -761,12 +765,14 @@ void msm_gem_active_put(struct drm_gem_object *obj)
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> struct msm_drm_private *priv = obj->dev->dev_private;
>
> - WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
> + might_sleep();
>
> if (!atomic_dec_return(&msm_obj->active_count)) {
> + mutex_lock(&priv->mm_lock);
> msm_obj->gpu = NULL;
> list_del_init(&msm_obj->mm_list);
> list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
> + mutex_unlock(&priv->mm_lock);
> }
> }
>
> @@ -921,13 +927,16 @@ static void free_object(struct msm_gem_object *msm_obj)
> {
> struct drm_gem_object *obj = &msm_obj->base;
> struct drm_device *dev = obj->dev;
> + struct msm_drm_private *priv = dev->dev_private;
>
> WARN_ON(!mutex_is_locked(&dev->struct
Re: [PATCH 05/14] drm/msm: Document and rename preempt_lock
On Sun, Oct 04, 2020 at 12:21:37PM -0700, Rob Clark wrote: > From: Rob Clark > > Before adding another lock, give ring->lock a more descriptive name. Reviewed-by: Jordan Crouse > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++-- > drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 ++-- > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++-- > drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +- > drivers/gpu/drm/msm/msm_ringbuffer.h | 7 ++- > 5 files changed, 17 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c > b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c > index c941c8138f25..543437a2186e 100644 > --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c > +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c > @@ -36,7 +36,7 @@ void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer > *ring, > OUT_RING(ring, upper_32_bits(shadowptr(a5xx_gpu, ring))); > } > > - spin_lock_irqsave(&ring->lock, flags); > + spin_lock_irqsave(&ring->preempt_lock, flags); > > /* Copy the shadow to the actual register */ > ring->cur = ring->next; > @@ -44,7 +44,7 @@ void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer > *ring, > /* Make sure to wrap wptr if we need to */ > wptr = get_wptr(ring); > > - spin_unlock_irqrestore(&ring->lock, flags); > + spin_unlock_irqrestore(&ring->preempt_lock, flags); > > /* Make sure everything is posted before making a decision */ > mb(); > diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c > b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c > index 7e04509c4e1f..183de1139eeb 100644 > --- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c > +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c > @@ -45,9 +45,9 @@ static inline void update_wptr(struct msm_gpu *gpu, struct > msm_ringbuffer *ring) > if (!ring) > return; > > - spin_lock_irqsave(&ring->lock, flags); > + spin_lock_irqsave(&ring->preempt_lock, flags); > wptr = get_wptr(ring); > - spin_unlock_irqrestore(&ring->lock, flags); > + spin_unlock_irqrestore(&ring->preempt_lock, flags); > > gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr); > } > @@ -62,9 +62,9 @@ static struct msm_ringbuffer *get_next_ring(struct msm_gpu > *gpu) > bool empty; > struct msm_ringbuffer *ring = gpu->rb[i]; > > - spin_lock_irqsave(&ring->lock, flags); > + spin_lock_irqsave(&ring->preempt_lock, flags); > empty = (get_wptr(ring) == ring->memptrs->rptr); > - spin_unlock_irqrestore(&ring->lock, flags); > + spin_unlock_irqrestore(&ring->preempt_lock, flags); > > if (!empty) > return ring; > @@ -132,9 +132,9 @@ void a5xx_preempt_trigger(struct msm_gpu *gpu) > } > > /* Make sure the wptr doesn't update while we're in motion */ > - spin_lock_irqsave(&ring->lock, flags); > + spin_lock_irqsave(&ring->preempt_lock, flags); > a5xx_gpu->preempt[ring->id]->wptr = get_wptr(ring); > - spin_unlock_irqrestore(&ring->lock, flags); > + spin_unlock_irqrestore(&ring->preempt_lock, flags); > > /* Set the address of the incoming preemption record */ > gpu_write64(gpu, REG_A5XX_CP_CONTEXT_SWITCH_RESTORE_ADDR_LO, > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > index 8915882e..fc85f008d69d 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > @@ -65,7 +65,7 @@ static void a6xx_flush(struct msm_gpu *gpu, struct > msm_ringbuffer *ring) > OUT_RING(ring, upper_32_bits(shadowptr(a6xx_gpu, ring))); > } > > - spin_lock_irqsave(&ring->lock, flags); > + spin_lock_irqsave(&ring->preempt_lock, flags); > > /* Copy the shadow to the actual register */ > ring->cur = ring->next; > @@ -73,7 +73,7 @@ static void a6xx_flush(struct msm_gpu *gpu, struct > msm_ringbuffer *ring) > /* Make sure to wrap wptr if we need to */ > wptr = get_wptr(ring); > > - spin_unlock_irqrestore(&ring->lock, flags); > + spin_unlock_irqrestore(&ring->preempt_lock, flags); > > /* Make sure everything is posted before making a decision */ > mb(); > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c > b/drivers/gpu/drm/msm/msm_ringbuffer.c > index 935bf9b1d941..1b6958e908dc 100644 > --- a/drivers/gpu/drm/msm/msm_ringbuffer.c > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c > @@ -46,7 +46,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu > *gpu, int id, > ring->memptrs_iova = memptrs_iova; > > INIT_LIST_HEAD(&ring->submits); > - spin_lock_init(&ring->lock); > + spin_lock_init(&ring->preempt_lock); > > snprintf(name, sizeof(name), "gpu-ring-%d", ring->id); > > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h > b/drivers/gpu/drm/msm/msm_ringbuffer.h > in
Re: [Freedreno] [PATCH 06/14] drm/msm: Protect ring->submits with it's own lock
On Sun, Oct 04, 2020 at 12:21:38PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> One less place to rely on dev->struct_mutex.
>
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
> drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
> drivers/gpu/drm/msm/msm_ringbuffer.h | 6 +
> 4 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index aa5c60a7132d..e1d1f005b3d4 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -63,7 +63,9 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> void msm_gem_submit_free(struct msm_gem_submit *submit)
> {
> dma_fence_put(submit->fence);
> + spin_lock(&submit->ring->submit_lock);
> list_del(&submit->node);
> + spin_unlock(&submit->ring->submit_lock);
> put_pid(submit->pid);
> msm_submitqueue_put(submit->queue);
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index ca8c95b32c8b..8d1e254f964a 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -270,6 +270,7 @@ static void update_fences(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
> {
> struct msm_gem_submit *submit;
>
> + spin_lock(&ring->submit_lock);
> list_for_each_entry(submit, &ring->submits, node) {
> if (submit->seqno > fence)
> break;
> @@ -277,6 +278,7 @@ static void update_fences(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
> msm_update_fence(submit->ring->fctx,
> submit->fence->seqno);
> }
> + spin_unlock(&ring->submit_lock);
> }
>
> #ifdef CONFIG_DEV_COREDUMP
> @@ -430,11 +432,14 @@ find_submit(struct msm_ringbuffer *ring, uint32_t fence)
> {
> struct msm_gem_submit *submit;
>
> - WARN_ON(!mutex_is_locked(&ring->gpu->dev->struct_mutex));
> -
> - list_for_each_entry(submit, &ring->submits, node)
> - if (submit->seqno == fence)
> + spin_lock(&ring->submit_lock);
> + list_for_each_entry(submit, &ring->submits, node) {
> + if (submit->seqno == fence) {
> + spin_unlock(&ring->submit_lock);
> return submit;
> + }
> + }
> + spin_unlock(&ring->submit_lock);
>
> return NULL;
> }
> @@ -523,8 +528,10 @@ static void recover_worker(struct work_struct *work)
> for (i = 0; i < gpu->nr_rings; i++) {
> struct msm_ringbuffer *ring = gpu->rb[i];
>
> + spin_lock(&ring->submit_lock);
> list_for_each_entry(submit, &ring->submits, node)
> gpu->funcs->submit(gpu, submit);
> + spin_unlock(&ring->submit_lock);
> }
> }
>
> @@ -711,7 +718,6 @@ static void retire_submit(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
> static void retire_submits(struct msm_gpu *gpu)
> {
> struct drm_device *dev = gpu->dev;
> - struct msm_gem_submit *submit, *tmp;
> int i;
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> @@ -720,9 +726,24 @@ static void retire_submits(struct msm_gpu *gpu)
> for (i = 0; i < gpu->nr_rings; i++) {
> struct msm_ringbuffer *ring = gpu->rb[i];
>
> - list_for_each_entry_safe(submit, tmp, &ring->submits, node) {
> - if (dma_fence_is_signaled(submit->fence))
> + while (true) {
> + struct msm_gem_submit *submit = NULL;
> +
> + spin_lock(&ring->submit_lock);
> + submit = list_first_entry_or_null(&ring->submits,
> + struct msm_gem_submit, node);
> + spin_unlock(&ring->submit_lock);
> +
> + /*
> + * If no submit, we are done. If submit->fence hasn't
> + * been signalled, then later submits are not signalled
> + * either, so we are also done.
> + */
> + if (submit && dma_fence_is_signaled(submit->fence)) {
> retire_submit(gpu, ring, submit);
> + } else {
> + break;
> + }
> }
> }
> }
> @@ -765,7 +786,9 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
>
> submit->seqno = ++ring->seqno;
>
> + spin_lock(&ring->submit_lock);
> list_add_tail(&submit->node, &ring->submits);
> + spin_unlock(&ring->submit_lock);
>
> msm_rd_dump_submit(priv->rd, submit, NULL);
>
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuf
[PATCH] drm/ttm: nuke ttm_bo_evict_mm and rename mgr function v2
Make it more clear what the resource manager function
does and nuke the wrapper function.
v2: nuke the wrapper
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 -
drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ++--
drivers/gpu/drm/qxl/qxl_object.c | 10 --
drivers/gpu/drm/radeon/radeon_object.c| 6 +-
drivers/gpu/drm/ttm/ttm_bo.c | 18 -
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
drivers/gpu/drm/ttm/ttm_resource.c| 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 ---
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 20 ---
include/drm/ttm/ttm_resource.h| 4 ++--
16 files changed, 49 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index abe0c2729e1c..a5e08dc54e4a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1319,6 +1319,7 @@ static int amdgpu_debugfs_evict_gtt(struct seq_file *m,
void *data)
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
struct amdgpu_device *adev = drm_to_adev(dev);
+ struct ttm_resource_manager *man;
int r;
r = pm_runtime_get_sync(dev->dev);
@@ -1327,7 +1328,9 @@ static int amdgpu_debugfs_evict_gtt(struct seq_file *m,
void *data)
return r;
}
- seq_printf(m, "(%d)\n", ttm_bo_evict_mm(&adev->mman.bdev, TTM_PL_TT));
+ man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
+ r = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
+ seq_printf(m, "(%d)\n", r);
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index f203e4a6a3f2..1721739def84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -136,7 +136,7 @@ void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
ttm_resource_manager_set_used(man, false);
- ret = ttm_resource_manager_force_list_clean(&adev->mman.bdev, man);
+ ret = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
if (ret)
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 964f9512dd6e..1aa516429c80 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1019,6 +1019,8 @@ void amdgpu_bo_unpin(struct amdgpu_bo *bo)
*/
int amdgpu_bo_evict_vram(struct amdgpu_device *adev)
{
+ struct ttm_resource_manager *man;
+
/* late 2.6.33 fix IGP hibernate - we need pm ops to do this correct */
#ifndef CONFIG_HIBERNATION
if (adev->flags & AMD_IS_APU) {
@@ -1026,7 +1028,9 @@ int amdgpu_bo_evict_vram(struct amdgpu_device *adev)
return 0;
}
#endif
- return ttm_bo_evict_mm(&adev->mman.bdev, TTM_PL_VRAM);
+
+ man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
+ return ttm_resource_manager_evict_all(&adev->mman.bdev, man);
}
static const char *amdgpu_vram_names[] = {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 01c1171afbe0..7747be644dd0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -212,7 +212,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
ttm_resource_manager_set_used(man, false);
- ret = ttm_resource_manager_force_list_clean(&adev->mman.bdev, man);
+ ret = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
if (ret)
return;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 72640bca1617..d141a5f004af 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -820,6 +820,7 @@ static int
nouveau_do_suspend(struct drm_device *dev, bool runtime)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ struct ttm_resource_manager *man;
int ret;
nouveau_svm_suspend(drm);
@@ -836,7 +837,9 @@ nouveau_do_suspend(struct drm_device *dev, bool runtime)
}
NV_DEBUG(drm, "evicting buffers...\n");
- ttm_bo_evict_mm(&drm->ttm.bdev, TTM_PL_VRAM);
+
+ man = ttm_manager_type(&drm->ttm.bdev, TTM_PL_VRAM
Re: [PATCH RESEND] drm/bridge: tc358764: restore connector support
W dniu 04.10.2020 o 21:14, Sam Ravnborg pisze: > Hi Marek. > > On Wed, Sep 30, 2020 at 01:40:42PM +0200, Marek Szyprowski wrote: >> This patch restores DRM connector registration in the TC358764 bridge >> driver and restores usage of the old drm_panel_* API, thus allows dynamic >> panel registration. This fixes panel operation on Exynos5250-based >> Arndale board. >> >> This is equivalent to the revert of the following commits: >> 1644127f83bc "drm/bridge: tc358764: add drm_panel_bridge support" >> 385ca38da29c "drm/bridge: tc358764: drop drm_connector_(un)register" >> and removal of the calls to drm_panel_attach()/drm_panel_detach(), which >> were no-ops and has been removed in meanwhile. >> >> Signed-off-by: Marek Szyprowski >> Reviewed-by: Andrzej Hajda > Thanks for providing the revert so we can have this fixed in upstream. > So far I have had no time to dive deeper into what is going wrong but > and the revert is the right cause of action for now. > > I expect Andrzej to pick it up as he has already reviewed it. > > Sam Done Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 07/14] drm/msm: Refcount submits
On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Before we remove dev->struct_mutex from the retire path, we have to deal
> with the situation of a submit retiring before the submit ioctl returns.
>
> To deal with this, ring->submits will hold a reference to the submit,
> which is dropped when the submit is retired. And the submit ioctl path
> holds it's own ref, which it drops when it is done with the submit.
>
> Also, add to submit list *after* getting/pinning bo's, to prevent badness
> in case the completed fence is corrupted, and retire_worker mistakenly
> believes the submit is done too early.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_drv.h| 1 -
> drivers/gpu/drm/msm/msm_gem.h| 13 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 12 ++--
> drivers/gpu/drm/msm/msm_gpu.c| 21 -
> 4 files changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 50978e5db376..535f9e718e2d 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -277,7 +277,6 @@ void msm_unregister_mmu(struct drm_device *dev, struct
> msm_mmu *mmu);
>
> bool msm_use_mmu(struct drm_device *dev);
>
> -void msm_gem_submit_free(struct msm_gem_submit *submit);
> int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
> struct drm_file *file);
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index a1bf741b9b89..e05b1530aca6 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -136,6 +136,7 @@ void msm_gem_free_work(struct work_struct *work);
> * lasts for the duration of the submit-ioctl.
> */
> struct msm_gem_submit {
> + struct kref ref;
> struct drm_device *dev;
> struct msm_gpu *gpu;
> struct msm_gem_address_space *aspace;
> @@ -169,6 +170,18 @@ struct msm_gem_submit {
> } bos[];
> };
>
> +void __msm_gem_submit_destroy(struct kref *kref);
> +
> +static inline void msm_gem_submit_get(struct msm_gem_submit *submit)
> +{
> + kref_get(&submit->ref);
> +}
> +
> +static inline void msm_gem_submit_put(struct msm_gem_submit *submit)
> +{
> + kref_put(&submit->ref, __msm_gem_submit_destroy);
> +}
> +
> /* helper to determine of a buffer in submit should be dumped, used for both
> * devcoredump and debugfs cmdstream dumping:
> */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index e1d1f005b3d4..7d653bdc92dc 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -42,6 +42,7 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> if (!submit)
> return NULL;
>
> + kref_init(&submit->ref);
> submit->dev = dev;
> submit->aspace = queue->ctx->aspace;
> submit->gpu = gpu;
> @@ -60,12 +61,12 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return submit;
> }
>
> -void msm_gem_submit_free(struct msm_gem_submit *submit)
> +void __msm_gem_submit_destroy(struct kref *kref)
> {
> + struct msm_gem_submit *submit =
> + container_of(kref, struct msm_gem_submit, ref);
> +
> dma_fence_put(submit->fence);
> - spin_lock(&submit->ring->submit_lock);
> - list_del(&submit->node);
> - spin_unlock(&submit->ring->submit_lock);
> put_pid(submit->pid);
> msm_submitqueue_put(submit->queue);
>
> @@ -805,8 +806,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> submit_cleanup(submit);
> if (has_ww_ticket)
> ww_acquire_fini(&submit->ticket);
> - if (ret)
> - msm_gem_submit_free(submit);
> + msm_gem_submit_put(submit);
> out_unlock:
> if (ret && (out_fence_fd >= 0))
> put_unused_fd(out_fence_fd);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 8d1e254f964a..fd3fc6f36ab1 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -712,7 +712,12 @@ static void retire_submit(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
>
> pm_runtime_mark_last_busy(&gpu->pdev->dev);
> pm_runtime_put_autosuspend(&gpu->pdev->dev);
> - msm_gem_submit_free(submit);
> +
> + spin_lock(&ring->submit_lock);
> + list_del(&submit->node);
> + spin_unlock(&ring->submit_lock);
> +
> + msm_gem_submit_put(submit);
> }
>
> static void retire_submits(struct msm_gpu *gpu)
> @@ -786,10 +791,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
>
> submit->seqno = ++ring->seqno;
>
> - spin_lock(&ring->submit_lock);
> - list_add_tail(&submit->node, &ring->submits);
> - spin_unlock(&ring->submit_lock);
> -
> msm_rd_dump_submit(priv->rd, sub
Re: [Freedreno] [PATCH 08/14] drm/msm: Remove obj->gpu
On Sun, Oct 04, 2020 at 12:21:40PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> It cannot be atomically updated with obj->active_count, and the only
> purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
> retire_submits() is not serialized with incoming submits via
> struct_mutex)
Somebody will prove me wrong but the longer we go without 2D the less likely it
is that we'll ever see it.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.c | 2 --
> drivers/gpu/drm/msm/msm_gem.h | 1 -
> drivers/gpu/drm/msm/msm_gpu.c | 5 -
> 3 files changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index b04ed8b52f9d..c52a3969e60b 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -753,7 +753,6 @@ void msm_gem_active_get(struct drm_gem_object *obj,
> struct msm_gpu *gpu)
>
> if (!atomic_fetch_inc(&msm_obj->active_count)) {
> mutex_lock(&priv->mm_lock);
> - msm_obj->gpu = gpu;
> list_del_init(&msm_obj->mm_list);
> list_add_tail(&msm_obj->mm_list, &gpu->active_list);
> mutex_unlock(&priv->mm_lock);
> @@ -769,7 +768,6 @@ void msm_gem_active_put(struct drm_gem_object *obj)
>
> if (!atomic_dec_return(&msm_obj->active_count)) {
> mutex_lock(&priv->mm_lock);
> - msm_obj->gpu = NULL;
> list_del_init(&msm_obj->mm_list);
> list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
> mutex_unlock(&priv->mm_lock);
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index e05b1530aca6..61147bd96b06 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -64,7 +64,6 @@ struct msm_gem_object {
>*
>*/
> struct list_head mm_list;
> - struct msm_gpu *gpu; /* non-null if active */
>
> /* Transiently in the process of submit ioctl, objects associated
>* with the submit are on submit->bo_list.. this only lasts for
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index fd3fc6f36ab1..c9ff19a75169 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -800,11 +800,6 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit)
> struct drm_gem_object *drm_obj = &msm_obj->base;
> uint64_t iova;
>
> - /* can't happen yet.. but when we add 2d support we'll have
> - * to deal w/ cross-ring synchronization:
> - */
> - WARN_ON(is_active(msm_obj) && (msm_obj->gpu != gpu));
> -
> /* submit takes a reference to the bo and iova until retired: */
> drm_gem_object_get(&msm_obj->base);
> msm_gem_get_and_pin_iova(&msm_obj->base, submit->aspace, &iova);
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing
On Mon, Oct 5, 2020 at 10:19 PM Maxime Ripard wrote:
>
> Hi Chen-Yu,
>
> Sorry for the delay
>
> On Sat, Aug 29, 2020 at 02:43:53PM +0800, Chen-Yu Tsai wrote:
> > > +static int sun4i_tcon_register_panel(struct drm_device *drm,
> > > +struct sun4i_tcon *tcon)
> > > +{
> > > + struct device_node *companion;
> > > + struct device_node *remote;
> > > + struct device *dev = tcon->dev;
> > > + bool has_lvds_alt;
> > > + bool has_lvds_rst;
> > > + int ret;
> > > +
> > > + /*
> > > +* If we have an LVDS panel connected to the TCON, we should
> > > +* just probe the LVDS connector. Otherwise, let's just register
> > > +* an RGB panel.
> > > +*/
> > > + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> > > + if (!tcon->quirks->supports_lvds ||
> > > + !of_device_is_compatible(remote, "panel-lvds"))
> > > + return sun4i_rgb_init(drm, tcon);
> >
> > Slightly related: IIRC there are a few LVDS panels supported in panel-simple
> > so they don't use the panel-lvds compatible. Any idea how to deal with
> > those?
>
> I agree that this is an issue, I'm not entirely sure how to fix it. The
> proper fix would be to have multiple output ports, one for each output
> type, but given how our current binding looks like I'm not sure how we
> could retro-fit that without some horror-looking code.
>
> Maybe we can add a property on the endpoint?
I guess that works. :)
Since the LCD and LVDS outputs use the same pins, it's not like we really would
have multiple output ports.
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 09/14] drm/msm: Drop struct_mutex from the retire path
On Sun, Oct 04, 2020 at 12:21:41PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Now that we are not relying on dev->struct_mutex to protect the
> ring->submits lists, drop the struct_mutex lock.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index c9ff19a75169..5e351d1c00e9 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -707,7 +707,7 @@ static void retire_submit(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
>
> msm_gem_active_put(&msm_obj->base);
> msm_gem_unpin_iova(&msm_obj->base, submit->aspace);
> - drm_gem_object_put_locked(&msm_obj->base);
> + drm_gem_object_put(&msm_obj->base);
> }
>
> pm_runtime_mark_last_busy(&gpu->pdev->dev);
> @@ -722,11 +722,8 @@ static void retire_submit(struct msm_gpu *gpu, struct
> msm_ringbuffer *ring,
>
> static void retire_submits(struct msm_gpu *gpu)
> {
> - struct drm_device *dev = gpu->dev;
> int i;
>
> - WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> -
> /* Retire the commits starting with highest priority */
> for (i = 0; i < gpu->nr_rings; i++) {
> struct msm_ringbuffer *ring = gpu->rb[i];
> @@ -756,15 +753,12 @@ static void retire_submits(struct msm_gpu *gpu)
> static void retire_worker(struct work_struct *work)
> {
> struct msm_gpu *gpu = container_of(work, struct msm_gpu, retire_work);
> - struct drm_device *dev = gpu->dev;
> int i;
>
> for (i = 0; i < gpu->nr_rings; i++)
> update_fences(gpu, gpu->rb[i], gpu->rb[i]->memptrs->fence);
>
> - mutex_lock(&dev->struct_mutex);
> retire_submits(gpu);
> - mutex_unlock(&dev->struct_mutex);
> }
>
> /* call from irq handler to schedule work to retire bo's */
> --
> 2.26.2
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: remove no_retry flag
Am 02.10.20 um 14:31 schrieb Daniel Vetter:
On Fri, Oct 2, 2020 at 1:31 PM Christian König
wrote:
Amdgpu was the only user of this.
Signed-off-by: Christian König
Uh this smells like a fishy band-aid. And the original commit
introducing this also doesn't sched any light on why this should
happen, and why it's specific to the amdgpu driver. Do you have some
more memories here?
Nope, I briefly remember that we had a customer which ran into the OOM
killer and instead wanted to get -ENOMEM.
But I honestly don't remember why we have it approached like that.
Christian.
I guess no retry makes sense for a "do you still have memory?" query,
but once we've commit to having that memory, I'm not seeing why we
should not try to find it? Might also tie into the lack of active
shrinking for ttm objects in the system domain.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
drivers/gpu/drm/ttm/ttm_tt.c| 3 ---
include/drm/ttm/ttm_device.h| 2 --
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c5f2b4971ef7..0a4233985870 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1298,6 +1298,9 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_buffer_object *bo,
}
gtt->gobj = &bo->base;
+ /* We opt to avoid OOM on system pages allocations */
+ page_flags |= TTM_PAGE_FLAG_NO_RETRY;
+
if (dma_addressing_limited(adev->dev))
page_flags |= TTM_PAGE_FLAG_DMA32;
@@ -1895,9 +1898,6 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
}
adev->mman.initialized = true;
- /* We opt to avoid OOM on system pages allocations */
- adev->mman.bdev.no_retry = true;
-
/* Initialize VRAM pool with all of VRAM divided into pages */
r = amdgpu_vram_mgr_init(adev);
if (r) {
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e2b1e6c53a04..98514abaa939 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -52,9 +52,6 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
zero_alloc)
if (bo->ttm)
return 0;
- if (bdev->no_retry)
- page_flags |= TTM_PAGE_FLAG_NO_RETRY;
-
switch (bo->type) {
case ttm_bo_type_device:
if (zero_alloc)
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index bfc6dd87f2d3..e0eba36c1309 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -326,8 +326,6 @@ struct ttm_device {
*/
struct delayed_work wq;
-
- bool no_retry;
};
static inline struct ttm_resource_manager *
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 04/12] drm/amdgpu: prevent double kfree ttm->sg
From: Philip Yang [ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ] Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace: [ 420.932812] kernel BUG at /build/linux-do9eLF/linux-4.15.0/mm/slub.c:295! [ 420.934182] invalid opcode: [#1] SMP NOPTI [ 420.935445] Modules linked in: xt_conntrack ipt_MASQUERADE [ 420.951332] Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 1.5.4 07/09/2020 [ 420.952887] RIP: 0010:__slab_free+0x180/0x2d0 [ 420.954419] RSP: 0018:be426291fa60 EFLAGS: 00010246 [ 420.955963] RAX: 9e29263e9c30 RBX: 9e29263e9c30 RCX: 0001814b [ 420.957512] RDX: 9e29263e9c30 RSI: f3d33e98fa40 RDI: 9e297e407a80 [ 420.959055] RBP: be426291fb00 R08: 0001 R09: c0d39ade [ 420.960587] R10: be426291fb20 R11: 9e49ffdd4000 R12: 9e297e407a80 [ 420.962105] R13: f3d33e98fa40 R14: 9e29263e9c30 R15: 9e2954464fd8 [ 420.963611] FS: 7fa2ea097780() GS:9e297e84() knlGS: [ 420.965144] CS: 0010 DS: ES: CR0: 80050033 [ 420.93] CR2: 7f16bfffefb8 CR3: 001ff0c62000 CR4: 00340ee0 [ 420.968193] Call Trace: [ 420.969703] ? __page_cache_release+0x3c/0x220 [ 420.971294] ? amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.972789] kfree+0x168/0x180 [ 420.974353] ? amdgpu_ttm_tt_set_user_pages+0x64/0xc0 [amdgpu] [ 420.975850] ? kfree+0x168/0x180 [ 420.977403] amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.97] ttm_tt_unpopulate.part.10+0x53/0x60 [amdttm] [ 420.980357] ttm_tt_destroy.part.11+0x4f/0x60 [amdttm] [ 420.981814] ttm_tt_destroy+0x13/0x20 [amdttm] [ 420.983273] ttm_bo_cleanup_memtype_use+0x36/0x80 [amdttm] [ 420.984725] ttm_bo_release+0x1c9/0x360 [amdttm] [ 420.986167] amdttm_bo_put+0x24/0x30 [amdttm] [ 420.987663] amdgpu_bo_unref+0x1e/0x30 [amdgpu] [ 420.989165] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x9ca/0xb10 [amdgpu] [ 420.990666] kfd_ioctl_alloc_memory_of_gpu+0xef/0x2c0 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index e59c01a83dace..9a3267f06376f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1052,6 +1052,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) release_sg: kfree(ttm->sg); + ttm->sg = NULL; return r; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 08/12] drm/amd/pm: Removed fixed clock in auto mode DPM
From: Sudheesh Mavila
[ Upstream commit 97cf32996c46d9935cc133d910a75fb687dd6144 ]
SMU10_UMD_PSTATE_PEAK_FCLK value should not be used to set the DPM.
Suggested-by: Evan Quan
Reviewed-by: Evan Quan
Signed-off-by: Sudheesh Mavila
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 9ee8cf8267c88..43f7adff6cb74 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -563,6 +563,8 @@ static int smu10_dpm_force_dpm_level(struct pp_hwmgr *hwmgr,
struct smu10_hwmgr *data = hwmgr->backend;
uint32_t min_sclk = hwmgr->display_config->min_core_set_clock;
uint32_t min_mclk = hwmgr->display_config->min_mem_set_clock/100;
+ uint32_t index_fclk = data->clock_vol_info.vdd_dep_on_fclk->count - 1;
+ uint32_t index_socclk = data->clock_vol_info.vdd_dep_on_socclk->count -
1;
if (hwmgr->smu_version < 0x1E3700) {
pr_info("smu firmware version too old, can not set dpm
level\n");
@@ -676,13 +678,13 @@ static int smu10_dpm_force_dpm_level(struct pp_hwmgr
*hwmgr,
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinFclkByFreq,
hwmgr->display_config->num_display > 3 ?
- SMU10_UMD_PSTATE_PEAK_FCLK :
+
data->clock_vol_info.vdd_dep_on_fclk->entries[0].clk :
min_mclk,
NULL);
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinSocclkByFreq,
- SMU10_UMD_PSTATE_MIN_SOCCLK,
+
data->clock_vol_info.vdd_dep_on_socclk->entries[0].clk,
NULL);
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetHardMinVcn,
@@ -695,11 +697,11 @@ static int smu10_dpm_force_dpm_level(struct pp_hwmgr
*hwmgr,
NULL);
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetSoftMaxFclkByFreq,
- SMU10_UMD_PSTATE_PEAK_FCLK,
+
data->clock_vol_info.vdd_dep_on_fclk->entries[index_fclk].clk,
NULL);
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetSoftMaxSocclkByFreq,
- SMU10_UMD_PSTATE_PEAK_SOCCLK,
+
data->clock_vol_info.vdd_dep_on_socclk->entries[index_socclk].clk,
NULL);
smum_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_SetSoftMaxVcn,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 2/2] drm/amdgpu: prevent double kfree ttm->sg
From: Philip Yang [ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ] Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace: [ 420.932812] kernel BUG at /build/linux-do9eLF/linux-4.15.0/mm/slub.c:295! [ 420.934182] invalid opcode: [#1] SMP NOPTI [ 420.935445] Modules linked in: xt_conntrack ipt_MASQUERADE [ 420.951332] Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 1.5.4 07/09/2020 [ 420.952887] RIP: 0010:__slab_free+0x180/0x2d0 [ 420.954419] RSP: 0018:be426291fa60 EFLAGS: 00010246 [ 420.955963] RAX: 9e29263e9c30 RBX: 9e29263e9c30 RCX: 0001814b [ 420.957512] RDX: 9e29263e9c30 RSI: f3d33e98fa40 RDI: 9e297e407a80 [ 420.959055] RBP: be426291fb00 R08: 0001 R09: c0d39ade [ 420.960587] R10: be426291fb20 R11: 9e49ffdd4000 R12: 9e297e407a80 [ 420.962105] R13: f3d33e98fa40 R14: 9e29263e9c30 R15: 9e2954464fd8 [ 420.963611] FS: 7fa2ea097780() GS:9e297e84() knlGS: [ 420.965144] CS: 0010 DS: ES: CR0: 80050033 [ 420.93] CR2: 7f16bfffefb8 CR3: 001ff0c62000 CR4: 00340ee0 [ 420.968193] Call Trace: [ 420.969703] ? __page_cache_release+0x3c/0x220 [ 420.971294] ? amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.972789] kfree+0x168/0x180 [ 420.974353] ? amdgpu_ttm_tt_set_user_pages+0x64/0xc0 [amdgpu] [ 420.975850] ? kfree+0x168/0x180 [ 420.977403] amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.97] ttm_tt_unpopulate.part.10+0x53/0x60 [amdttm] [ 420.980357] ttm_tt_destroy.part.11+0x4f/0x60 [amdttm] [ 420.981814] ttm_tt_destroy+0x13/0x20 [amdttm] [ 420.983273] ttm_bo_cleanup_memtype_use+0x36/0x80 [amdttm] [ 420.984725] ttm_bo_release+0x1c9/0x360 [amdttm] [ 420.986167] amdttm_bo_put+0x24/0x30 [amdttm] [ 420.987663] amdgpu_bo_unref+0x1e/0x30 [amdgpu] [ 420.989165] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x9ca/0xb10 [amdgpu] [ 420.990666] kfd_ioctl_alloc_memory_of_gpu+0xef/0x2c0 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 05ff98b43c50f..80c60a62d39ef 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -637,6 +637,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) release_sg: kfree(ttm->sg); + ttm->sg = NULL; return r; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 09/12] drm/amd/display: fix return value check for hdcp_work
From: Flora Cui [ Upstream commit 898c7302f4de1d91065e80fc46552b3ec70894ff ] max_caps might be 0, thus hdcp_work might be ZERO_SIZE_PTR Signed-off-by: Flora Cui Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c index 949d10ef83040..6dd1f3f8d9903 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c @@ -568,7 +568,7 @@ struct hdcp_workqueue *hdcp_create_workqueue(struct amdgpu_device *adev, struct int i = 0; hdcp_work = kcalloc(max_caps, sizeof(*hdcp_work), GFP_KERNEL); - if (hdcp_work == NULL) + if (ZERO_OR_NULL_PTR(hdcp_work)) return NULL; hdcp_work->srm = kcalloc(PSP_HDCP_SRM_FIRST_GEN_MAX_SIZE, sizeof(*hdcp_work->srm), GFP_KERNEL); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.14 2/2] drm/amdgpu: prevent double kfree ttm->sg
From: Philip Yang [ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ] Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace: [ 420.932812] kernel BUG at /build/linux-do9eLF/linux-4.15.0/mm/slub.c:295! [ 420.934182] invalid opcode: [#1] SMP NOPTI [ 420.935445] Modules linked in: xt_conntrack ipt_MASQUERADE [ 420.951332] Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 1.5.4 07/09/2020 [ 420.952887] RIP: 0010:__slab_free+0x180/0x2d0 [ 420.954419] RSP: 0018:be426291fa60 EFLAGS: 00010246 [ 420.955963] RAX: 9e29263e9c30 RBX: 9e29263e9c30 RCX: 0001814b [ 420.957512] RDX: 9e29263e9c30 RSI: f3d33e98fa40 RDI: 9e297e407a80 [ 420.959055] RBP: be426291fb00 R08: 0001 R09: c0d39ade [ 420.960587] R10: be426291fb20 R11: 9e49ffdd4000 R12: 9e297e407a80 [ 420.962105] R13: f3d33e98fa40 R14: 9e29263e9c30 R15: 9e2954464fd8 [ 420.963611] FS: 7fa2ea097780() GS:9e297e84() knlGS: [ 420.965144] CS: 0010 DS: ES: CR0: 80050033 [ 420.93] CR2: 7f16bfffefb8 CR3: 001ff0c62000 CR4: 00340ee0 [ 420.968193] Call Trace: [ 420.969703] ? __page_cache_release+0x3c/0x220 [ 420.971294] ? amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.972789] kfree+0x168/0x180 [ 420.974353] ? amdgpu_ttm_tt_set_user_pages+0x64/0xc0 [amdgpu] [ 420.975850] ? kfree+0x168/0x180 [ 420.977403] amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.97] ttm_tt_unpopulate.part.10+0x53/0x60 [amdttm] [ 420.980357] ttm_tt_destroy.part.11+0x4f/0x60 [amdttm] [ 420.981814] ttm_tt_destroy+0x13/0x20 [amdttm] [ 420.983273] ttm_bo_cleanup_memtype_use+0x36/0x80 [amdttm] [ 420.984725] ttm_bo_release+0x1c9/0x360 [amdttm] [ 420.986167] amdttm_bo_put+0x24/0x30 [amdttm] [ 420.987663] amdgpu_bo_unref+0x1e/0x30 [amdgpu] [ 420.989165] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x9ca/0xb10 [amdgpu] [ 420.990666] kfd_ioctl_alloc_memory_of_gpu+0xef/0x2c0 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index bc746131987ff..ae700e445fbc8 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -727,6 +727,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) release_sg: kfree(ttm->sg); + ttm->sg = NULL; return r; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.8 10/12] drm/vmwgfx: Fix error handling in get_node
From: Zack Rusin [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ] ttm_mem_type_manager_func.get_node was changed to return -ENOSPC instead of setting the node pointer to NULL. Unfortunately vmwgfx still had two places where it was explicitly converting -ENOSPC to 0 causing regressions. This fixes those spots by allowing -ENOSPC to be returned. That seems to fix recent regressions with vmwgfx. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Reviewed-by: Martin Krastev Sigend-off-by: Roland Scheidegger Signed-off-by: Sasha Levin --- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c index 7da752ca1c34b..b93c558dd86e0 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c @@ -57,7 +57,7 @@ static int vmw_gmrid_man_get_node(struct ttm_mem_type_manager *man, id = ida_alloc_max(&gman->gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL); if (id < 0) - return (id != -ENOMEM ? 0 : id); + return id; spin_lock(&gman->lock); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c index b7c816ba71663..c8b9335bccd8d 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c @@ -95,7 +95,7 @@ static int vmw_thp_get_node(struct ttm_mem_type_manager *man, mem->start = node->start; } - return 0; + return ret; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 2/2] drm/amdgpu: prevent double kfree ttm->sg
From: Philip Yang [ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ] Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace: [ 420.932812] kernel BUG at /build/linux-do9eLF/linux-4.15.0/mm/slub.c:295! [ 420.934182] invalid opcode: [#1] SMP NOPTI [ 420.935445] Modules linked in: xt_conntrack ipt_MASQUERADE [ 420.951332] Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 1.5.4 07/09/2020 [ 420.952887] RIP: 0010:__slab_free+0x180/0x2d0 [ 420.954419] RSP: 0018:be426291fa60 EFLAGS: 00010246 [ 420.955963] RAX: 9e29263e9c30 RBX: 9e29263e9c30 RCX: 0001814b [ 420.957512] RDX: 9e29263e9c30 RSI: f3d33e98fa40 RDI: 9e297e407a80 [ 420.959055] RBP: be426291fb00 R08: 0001 R09: c0d39ade [ 420.960587] R10: be426291fb20 R11: 9e49ffdd4000 R12: 9e297e407a80 [ 420.962105] R13: f3d33e98fa40 R14: 9e29263e9c30 R15: 9e2954464fd8 [ 420.963611] FS: 7fa2ea097780() GS:9e297e84() knlGS: [ 420.965144] CS: 0010 DS: ES: CR0: 80050033 [ 420.93] CR2: 7f16bfffefb8 CR3: 001ff0c62000 CR4: 00340ee0 [ 420.968193] Call Trace: [ 420.969703] ? __page_cache_release+0x3c/0x220 [ 420.971294] ? amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.972789] kfree+0x168/0x180 [ 420.974353] ? amdgpu_ttm_tt_set_user_pages+0x64/0xc0 [amdgpu] [ 420.975850] ? kfree+0x168/0x180 [ 420.977403] amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.97] ttm_tt_unpopulate.part.10+0x53/0x60 [amdttm] [ 420.980357] ttm_tt_destroy.part.11+0x4f/0x60 [amdttm] [ 420.981814] ttm_tt_destroy+0x13/0x20 [amdttm] [ 420.983273] ttm_bo_cleanup_memtype_use+0x36/0x80 [amdttm] [ 420.984725] ttm_bo_release+0x1c9/0x360 [amdttm] [ 420.986167] amdttm_bo_put+0x24/0x30 [amdttm] [ 420.987663] amdgpu_bo_unref+0x1e/0x30 [amdgpu] [ 420.989165] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x9ca/0xb10 [amdgpu] [ 420.990666] kfd_ioctl_alloc_memory_of_gpu+0xef/0x2c0 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index fcf421263fd96..abad7460084f2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -954,6 +954,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) release_sg: kfree(ttm->sg); + ttm->sg = NULL; return r; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 2/4] drm/amdgpu: prevent double kfree ttm->sg
From: Philip Yang [ Upstream commit 1d0e16ac1a9e800598dcfa5b6bc53b704a103390 ] Set ttm->sg to NULL after kfree, to avoid memory corruption backtrace: [ 420.932812] kernel BUG at /build/linux-do9eLF/linux-4.15.0/mm/slub.c:295! [ 420.934182] invalid opcode: [#1] SMP NOPTI [ 420.935445] Modules linked in: xt_conntrack ipt_MASQUERADE [ 420.951332] Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 1.5.4 07/09/2020 [ 420.952887] RIP: 0010:__slab_free+0x180/0x2d0 [ 420.954419] RSP: 0018:be426291fa60 EFLAGS: 00010246 [ 420.955963] RAX: 9e29263e9c30 RBX: 9e29263e9c30 RCX: 0001814b [ 420.957512] RDX: 9e29263e9c30 RSI: f3d33e98fa40 RDI: 9e297e407a80 [ 420.959055] RBP: be426291fb00 R08: 0001 R09: c0d39ade [ 420.960587] R10: be426291fb20 R11: 9e49ffdd4000 R12: 9e297e407a80 [ 420.962105] R13: f3d33e98fa40 R14: 9e29263e9c30 R15: 9e2954464fd8 [ 420.963611] FS: 7fa2ea097780() GS:9e297e84() knlGS: [ 420.965144] CS: 0010 DS: ES: CR0: 80050033 [ 420.93] CR2: 7f16bfffefb8 CR3: 001ff0c62000 CR4: 00340ee0 [ 420.968193] Call Trace: [ 420.969703] ? __page_cache_release+0x3c/0x220 [ 420.971294] ? amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.972789] kfree+0x168/0x180 [ 420.974353] ? amdgpu_ttm_tt_set_user_pages+0x64/0xc0 [amdgpu] [ 420.975850] ? kfree+0x168/0x180 [ 420.977403] amdgpu_ttm_tt_unpopulate+0x5e/0x80 [amdgpu] [ 420.97] ttm_tt_unpopulate.part.10+0x53/0x60 [amdttm] [ 420.980357] ttm_tt_destroy.part.11+0x4f/0x60 [amdttm] [ 420.981814] ttm_tt_destroy+0x13/0x20 [amdttm] [ 420.983273] ttm_bo_cleanup_memtype_use+0x36/0x80 [amdttm] [ 420.984725] ttm_bo_release+0x1c9/0x360 [amdttm] [ 420.986167] amdttm_bo_put+0x24/0x30 [amdttm] [ 420.987663] amdgpu_bo_unref+0x1e/0x30 [amdgpu] [ 420.989165] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x9ca/0xb10 [amdgpu] [ 420.990666] kfd_ioctl_alloc_memory_of_gpu+0xef/0x2c0 [amdgpu] Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index f15ded1ce9057..c6a1dfe79e809 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -967,6 +967,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) release_sg: kfree(ttm->sg); + ttm->sg = NULL; return r; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE
On Tue, 22 Sep 2020 15:16:48 +0100 Robin Murphy wrote: > Midgard GPUs have ACE-Lite master interfaces which allows systems to > integrate them in an I/O-coherent manner. It seems that from the GPU's > viewpoint, the rest of the system is its outer shareable domain, and so > even when snoop signals are wired up, they are only emitted for outer > shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does > indeed get coherent pagetable walks working nicely for the coherent > T620 in the Arm Juno SoC. > > Reviewed-by: Steven Price > Tested-by: Neil Armstrong > Signed-off-by: Robin Murphy > --- > drivers/iommu/io-pgtable-arm.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c > index dc7bcf858b6d..b4072a18e45d 100644 > --- a/drivers/iommu/io-pgtable-arm.c > +++ b/drivers/iommu/io-pgtable-arm.c > @@ -440,7 +440,13 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct > arm_lpae_io_pgtable *data, > << ARM_LPAE_PTE_ATTRINDX_SHIFT); > } > > - if (prot & IOMMU_CACHE) > + /* > + * Also Mali has its own notions of shareability wherein its Inner > + * domain covers the cores within the GPU, and its Outer domain is > + * "outside the GPU" (i.e. either the Inner or System domain in CPU > + * terms, depending on coherency). > + */ > + if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE) > pte |= ARM_LPAE_PTE_SH_IS; > else > pte |= ARM_LPAE_PTE_SH_OS; Actually, it still doesn't work on s922x :-/. For it to work I correctly, I need to drop the outer shareable flag here. > @@ -1049,6 +1055,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, > void *cookie) > cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) | > ARM_MALI_LPAE_TTBR_READ_INNER | > ARM_MALI_LPAE_TTBR_ADRMODE_TABLE; > + if (cfg->coherent_walk) > + cfg->arm_mali_lpae_cfg.transtab |= > ARM_MALI_LPAE_TTBR_SHARE_OUTER; > + > return &data->iop; > > out_free_data: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/ttm: remove no_retry flag
On Mon, Oct 5, 2020 at 4:37 PM Christian König
wrote:
>
> Am 02.10.20 um 14:31 schrieb Daniel Vetter:
> > On Fri, Oct 2, 2020 at 1:31 PM Christian König
> > wrote:
> >> Amdgpu was the only user of this.
> >>
> >> Signed-off-by: Christian König
> > Uh this smells like a fishy band-aid. And the original commit
> > introducing this also doesn't sched any light on why this should
> > happen, and why it's specific to the amdgpu driver. Do you have some
> > more memories here?
>
> Nope, I briefly remember that we had a customer which ran into the OOM
> killer and instead wanted to get -ENOMEM.
>
> But I honestly don't remember why we have it approached like that.
Well oom killer being supremely unpopular is kinda not news. I think
what you want is that in the buffer create ioctl you don't retry, but
instead fall over if there's no memory. So that userspace knows it
can't allocate more gpu memory.
But in execbuf not trying to find the memory we promised is totally
there is kinda rude. So I think this should be a runtime flag, perhaps
in the ttm_operation_ctx?
The other thing which is really nasty is if we add a shrinker for
SYSTEM objects (using trylocks and all that), and maybe throw out the
swapped shrinker completely and only rely on that first one. Since
when that happens you do want to shrink excessive drag, but not too
much (but I think that should still be covered by the NO_RETRY flag,
iirc that means "shrink a bit, but dont get desperate"). But that's
kinda a bigger discussion.
-Daniel
>
> Christian.
>
> >
> > I guess no retry makes sense for a "do you still have memory?" query,
> > but once we've commit to having that memory, I'm not seeing why we
> > should not try to find it? Might also tie into the lack of active
> > shrinking for ttm objects in the system domain.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
> >> drivers/gpu/drm/ttm/ttm_tt.c| 3 ---
> >> include/drm/ttm/ttm_device.h| 2 --
> >> 3 files changed, 3 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >> index c5f2b4971ef7..0a4233985870 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >> @@ -1298,6 +1298,9 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
> >> ttm_buffer_object *bo,
> >> }
> >> gtt->gobj = &bo->base;
> >>
> >> + /* We opt to avoid OOM on system pages allocations */
> >> + page_flags |= TTM_PAGE_FLAG_NO_RETRY;
> >> +
> >> if (dma_addressing_limited(adev->dev))
> >> page_flags |= TTM_PAGE_FLAG_DMA32;
> >>
> >> @@ -1895,9 +1898,6 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
> >> }
> >> adev->mman.initialized = true;
> >>
> >> - /* We opt to avoid OOM on system pages allocations */
> >> - adev->mman.bdev.no_retry = true;
> >> -
> >> /* Initialize VRAM pool with all of VRAM divided into pages */
> >> r = amdgpu_vram_mgr_init(adev);
> >> if (r) {
> >> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> >> index e2b1e6c53a04..98514abaa939 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> >> @@ -52,9 +52,6 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool
> >> zero_alloc)
> >> if (bo->ttm)
> >> return 0;
> >>
> >> - if (bdev->no_retry)
> >> - page_flags |= TTM_PAGE_FLAG_NO_RETRY;
> >> -
> >> switch (bo->type) {
> >> case ttm_bo_type_device:
> >> if (zero_alloc)
> >> diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
> >> index bfc6dd87f2d3..e0eba36c1309 100644
> >> --- a/include/drm/ttm/ttm_device.h
> >> +++ b/include/drm/ttm/ttm_device.h
> >> @@ -326,8 +326,6 @@ struct ttm_device {
> >> */
> >>
> >> struct delayed_work wq;
> >> -
> >> - bool no_retry;
> >> };
> >>
> >> static inline struct ttm_resource_manager *
> >> --
> >> 2.17.1
> >>
> >
>
--
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 2/2] mm/frame-vec: use FOLL_LONGTERM
Hi! On Fri 02-10-20 15:06:03, Jason Gunthorpe wrote: > This get_vaddr_frames() thing looks impossible to use properly. How on > earth does a driver guarentee > > "If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page > structures and the caller must make sure pfns aren't reused for > anything else while he is using them." > > The only possible way to do that is if the driver restricts the VMAs > to ones it owns and interacts with the vm_private data to refcount > something. > > Since every driver does this wrong anything that uses this is creating > terrifying security issues. > > IMHO this whole API should be deleted :( So I'm the one guilty for introducing this API. The API was created to factor out code in several (mostly V4L AFAIR) drivers thus reducing amount of drivers poking into MM internals and getting things wrong in various cases. It may well be that the API is still broken from "can driver ensure this" POV - I tried to keep things things as they were before in this regard as I have very little knowledge in how these drivers are supposed to work. Anyway, if you can make this go away, sure go ahead :) Honza -- Jan Kara SUSE Labs, CR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, October 1, 2020 7:28 AM >To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com; >airl...@gmail.com; dan...@ffwll.ch >Subject: [PATCH 1/8] drm/ttm: remove TTM_PAGE_FLAG_WRITE > >Not used any more. Reviewed-by: Michael J. Ruhl m >Signed-off-by: Christian König >--- > include/drm/ttm/ttm_tt.h | 1 - > 1 file changed, 1 deletion(-) > >diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h >index 91691240a509..5d1835d44084 100644 >--- a/include/drm/ttm/ttm_tt.h >+++ b/include/drm/ttm/ttm_tt.h >@@ -34,7 +34,6 @@ struct ttm_resource; > struct ttm_buffer_object; > struct ttm_operation_ctx; > >-#define TTM_PAGE_FLAG_WRITE (1 << 3) > #define TTM_PAGE_FLAG_SWAPPED (1 << 4) > #define TTM_PAGE_FLAG_ZERO_ALLOC (1 << 6) > #define TTM_PAGE_FLAG_DMA32 (1 << 7) >-- >2.17.1 > >___ >dri-devel mailing list >dri-devel@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 2/8] drm/ttm: move ttm_set_memory.h out of include
>
>This is not something drivers should use.
It's not?
I am not really sure what you are doing here.
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 3 ++-
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++-
> {include => drivers/gpu}/drm/ttm/ttm_set_memory.h | 0
> 3 files changed, 4 insertions(+), 2 deletions(-)
> rename {include => drivers/gpu}/drm/ttm/ttm_set_memory.h (100%)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 14660f723f71..912c30dcc9db 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -47,7 +47,8 @@
>
> #include
> #include
>-#include
>+
>+#include "ttm_set_memory.h"
>
> #define NUM_PAGES_TO_ALLOC(PAGE_SIZE/sizeof(struct page
>*))
> #define SMALL_ALLOCATION 16
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>index 5e2df11685e7..1045a5c26ee3 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>@@ -49,7 +49,8 @@
> #include
> #include
> #include
>-#include
>+
>+#include "ttm_set_memory.h"
>
> #define NUM_PAGES_TO_ALLOC(PAGE_SIZE/sizeof(struct page
>*))
> #define SMALL_ALLOCATION 4
>diff --git a/include/drm/ttm/ttm_set_memory.h
>b/drivers/gpu/drm/ttm/ttm_set_memory.h
>similarity index 100%
>rename from include/drm/ttm/ttm_set_memory.h
>rename to drivers/gpu/drm/ttm/ttm_set_memory.h
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 3/8] drm/ttm: cleanup ttm_handle_caching_state_failure
>
>Remove unused parameters, shorten the function name.
Looks good to me.
Reviewed-by: Michael J. Ruhl
M
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 912c30dcc9db..111031cbb6df 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -467,11 +467,11 @@ static int ttm_set_pages_caching(struct page
>**pages,
> * any pages that have changed their caching state already put them to the
> * pool.
> */
>-static void ttm_handle_caching_state_failure(struct list_head *pages,
>- int ttm_flags, enum ttm_caching_state cstate,
>- struct page **failed_pages, unsigned cpages)
>+static void ttm_handle_caching_failure(struct page **failed_pages,
>+ unsigned cpages)
> {
> unsigned i;
>+
> /* Failed pages have to be freed */
> for (i = 0; i < cpages; ++i) {
> list_del(&failed_pages[i]->lru);
>@@ -517,9 +517,8 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> r = ttm_set_pages_caching(caching_array,
> cstate, cpages);
> if (r)
>-
> ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+
> ttm_handle_caching_failure(caching_array,
>+ cpages);
> }
> r = -ENOMEM;
> goto out;
>@@ -542,9 +541,8 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> r = ttm_set_pages_caching(caching_array,
> cstate, cpages);
> if (r) {
>-
> ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+
> ttm_handle_caching_failure(caching_array,
>+ cpages);
> goto out;
> }
> cpages = 0;
>@@ -555,9 +553,7 @@ static int ttm_alloc_new_pages(struct list_head
>*pages, gfp_t gfp_flags,
> if (cpages) {
> r = ttm_set_pages_caching(caching_array, cstate, cpages);
> if (r)
>- ttm_handle_caching_state_failure(pages,
>- ttm_flags, cstate,
>- caching_array, cpages);
>+ ttm_handle_caching_failure(caching_array, cpages);
> }
> out:
> kfree(caching_array);
>--
>2.17.1
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE
On 05/10/2020 15:50, Boris Brezillon wrote: On Tue, 22 Sep 2020 15:16:48 +0100 Robin Murphy wrote: Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and so even when snoop signals are wired up, they are only emitted for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely for the coherent T620 in the Arm Juno SoC. Reviewed-by: Steven Price Tested-by: Neil Armstrong Signed-off-by: Robin Murphy --- drivers/iommu/io-pgtable-arm.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c index dc7bcf858b6d..b4072a18e45d 100644 --- a/drivers/iommu/io-pgtable-arm.c +++ b/drivers/iommu/io-pgtable-arm.c @@ -440,7 +440,13 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data, << ARM_LPAE_PTE_ATTRINDX_SHIFT); } - if (prot & IOMMU_CACHE) + /* +* Also Mali has its own notions of shareability wherein its Inner +* domain covers the cores within the GPU, and its Outer domain is +* "outside the GPU" (i.e. either the Inner or System domain in CPU +* terms, depending on coherency). +*/ + if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE) pte |= ARM_LPAE_PTE_SH_IS; else pte |= ARM_LPAE_PTE_SH_OS; Actually, it still doesn't work on s922x :-/. For it to work I correctly, I need to drop the outer shareable flag here. The logic here does seem a bit odd. Originally it was: IOMMU_CACHE -> Inner shared (value 3) !IOMMU_CACHE -> Outer shared (value 2) For Mali we're forcing everything to the second option. But Mali being Mali doesn't do things the same as LPAE, so for Mali we have: 0 - not shared 1 - reserved 2 - inner(*) and outer shareable 3 - inner shareable only (*) where "inner" means internal to the GPU, and "outer" means shared with the CPU "inner". Very confusing! So originally we had: IOMMU_CACHE -> not shared with CPU (only internally in the GPU) !IOMMU_CACHE -> shared with CPU The change above gets us to "always shared", dropping the SH_OS bit would get us to not even shareable between cores (which doesn't sound like what we want). It's not at all clear to me why the change helps, but I suspect we want at least "inner" shareable. Steve @@ -1049,6 +1055,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) | ARM_MALI_LPAE_TTBR_READ_INNER | ARM_MALI_LPAE_TTBR_ADRMODE_TABLE; + if (cfg->coherent_walk) + cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER; + return &data->iop; out_free_data: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: nuke ttm_bo_evict_mm and rename mgr function v2
On Mon, Oct 5, 2020 at 4:27 PM Christian König
wrote:
>
> Make it more clear what the resource manager function
> does and nuke the wrapper function.
>
> v2: nuke the wrapper
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
I think adding a bdev back pointer to res_man would be nice and would
allow us to drop that pointer too, for some really pretty object
oriented feel in the api :-) But maybe follow up patch.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 -
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_object.c | 10 --
> drivers/gpu/drm/radeon/radeon_object.c| 6 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 18 -
> drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
> drivers/gpu/drm/ttm/ttm_resource.c| 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +-
> include/drm/ttm/ttm_bo_api.h | 20 ---
> include/drm/ttm/ttm_resource.h| 4 ++--
> 16 files changed, 49 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index abe0c2729e1c..a5e08dc54e4a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -1319,6 +1319,7 @@ static int amdgpu_debugfs_evict_gtt(struct seq_file *m,
> void *data)
> struct drm_info_node *node = (struct drm_info_node *)m->private;
> struct drm_device *dev = node->minor->dev;
> struct amdgpu_device *adev = drm_to_adev(dev);
> + struct ttm_resource_manager *man;
> int r;
>
> r = pm_runtime_get_sync(dev->dev);
> @@ -1327,7 +1328,9 @@ static int amdgpu_debugfs_evict_gtt(struct seq_file *m,
> void *data)
> return r;
> }
>
> - seq_printf(m, "(%d)\n", ttm_bo_evict_mm(&adev->mman.bdev, TTM_PL_TT));
> + man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
> + r = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
> + seq_printf(m, "(%d)\n", r);
>
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put_autosuspend(dev->dev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index f203e4a6a3f2..1721739def84 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -136,7 +136,7 @@ void amdgpu_gtt_mgr_fini(struct amdgpu_device *adev)
>
> ttm_resource_manager_set_used(man, false);
>
> - ret = ttm_resource_manager_force_list_clean(&adev->mman.bdev, man);
> + ret = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
> if (ret)
> return;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 964f9512dd6e..1aa516429c80 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -1019,6 +1019,8 @@ void amdgpu_bo_unpin(struct amdgpu_bo *bo)
> */
> int amdgpu_bo_evict_vram(struct amdgpu_device *adev)
> {
> + struct ttm_resource_manager *man;
> +
> /* late 2.6.33 fix IGP hibernate - we need pm ops to do this correct
> */
> #ifndef CONFIG_HIBERNATION
> if (adev->flags & AMD_IS_APU) {
> @@ -1026,7 +1028,9 @@ int amdgpu_bo_evict_vram(struct amdgpu_device *adev)
> return 0;
> }
> #endif
> - return ttm_bo_evict_mm(&adev->mman.bdev, TTM_PL_VRAM);
> +
> + man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM);
> + return ttm_resource_manager_evict_all(&adev->mman.bdev, man);
> }
>
> static const char *amdgpu_vram_names[] = {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 01c1171afbe0..7747be644dd0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -212,7 +212,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
>
> ttm_resource_manager_set_used(man, false);
>
> - ret = ttm_resource_manager_force_list_clean(&adev->mman.bdev, man);
> + ret = ttm_resource_manager_evict_all(&adev->mman.bdev, man);
> if (ret)
> return;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 72640bca1617..d141a5f004af 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@
Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'
On Fri, Oct 02, 2020 at 06:41:43PM -0500, Rob Herring wrote: > Another round of wack-a-mole. The json-schema default is additional > unknown properties are allowed, but for DT all properties should be > defined. > > Signed-off-by: Rob Herring > --- > > I'll take this thru the DT tree. > > [...] > .../bindings/power/supply/cw2015_battery.yaml | 2 ++ > .../bindings/power/supply/rohm,bd99954.yaml | 8 > [...] Acked-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE
On Mon, 5 Oct 2020 16:16:32 +0100 Steven Price wrote: > On 05/10/2020 15:50, Boris Brezillon wrote: > > On Tue, 22 Sep 2020 15:16:48 +0100 > > Robin Murphy wrote: > > > >> Midgard GPUs have ACE-Lite master interfaces which allows systems to > >> integrate them in an I/O-coherent manner. It seems that from the GPU's > >> viewpoint, the rest of the system is its outer shareable domain, and so > >> even when snoop signals are wired up, they are only emitted for outer > >> shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does > >> indeed get coherent pagetable walks working nicely for the coherent > >> T620 in the Arm Juno SoC. > >> > >> Reviewed-by: Steven Price > >> Tested-by: Neil Armstrong > >> Signed-off-by: Robin Murphy > >> --- > >> drivers/iommu/io-pgtable-arm.c | 11 ++- > >> 1 file changed, 10 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/iommu/io-pgtable-arm.c > >> b/drivers/iommu/io-pgtable-arm.c > >> index dc7bcf858b6d..b4072a18e45d 100644 > >> --- a/drivers/iommu/io-pgtable-arm.c > >> +++ b/drivers/iommu/io-pgtable-arm.c > >> @@ -440,7 +440,13 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct > >> arm_lpae_io_pgtable *data, > >><< ARM_LPAE_PTE_ATTRINDX_SHIFT); > >>} > >> > >> - if (prot & IOMMU_CACHE) > >> + /* > >> + * Also Mali has its own notions of shareability wherein its Inner > >> + * domain covers the cores within the GPU, and its Outer domain is > >> + * "outside the GPU" (i.e. either the Inner or System domain in CPU > >> + * terms, depending on coherency). > >> + */ > >> + if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE) > >>pte |= ARM_LPAE_PTE_SH_IS; > >>else > >>pte |= ARM_LPAE_PTE_SH_OS; > > > > Actually, it still doesn't work on s922x :-/. For it to work I > > correctly, I need to drop the outer shareable flag here. > > The logic here does seem a bit odd. Originally it was: > > IOMMU_CACHE -> Inner shared (value 3) > !IOMMU_CACHE -> Outer shared (value 2) > > For Mali we're forcing everything to the second option. But Mali being > Mali doesn't do things the same as LPAE, so for Mali we have: > > 0 - not shared > 1 - reserved > 2 - inner(*) and outer shareable > 3 - inner shareable only > > (*) where "inner" means internal to the GPU, and "outer" means shared > with the CPU "inner". Very confusing! > > So originally we had: > IOMMU_CACHE -> not shared with CPU (only internally in the GPU) > !IOMMU_CACHE -> shared with CPU > > The change above gets us to "always shared", dropping the SH_OS bit > would get us to not even shareable between cores (which doesn't sound > like what we want). Thanks for this explanation. > > It's not at all clear to me why the change helps, but I suspect we want > at least "inner" shareable. Right. Looks like all this was caused by a bad conflict resolution during a rebase. Sorry for the noise :-/. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.8 10/12] drm/vmwgfx: Fix error handling in get_node
Not entirely sure how the patches for autosel were selected, but this patch is no good for 5.8, since the patch which introduced the breakage in the first place is only in 5.9 (in particular it was 58e4d686d456c3e356439ae160ff4a0728940b8e, drm/ttm: cleanup ttm_mem_type_manager_func.get_node interface v3), and at least I don't see that one being backported to 5.8. Roland Am 05.10.20 um 16:44 schrieb Sasha Levin: > From: Zack Rusin > > [ Upstream commit f54c4442893b8dfbd3aff8e903c54dfff1aef990 ] > > ttm_mem_type_manager_func.get_node was changed to return -ENOSPC > instead of setting the node pointer to NULL. Unfortunately > vmwgfx still had two places where it was explicitly converting > -ENOSPC to 0 causing regressions. This fixes those spots by > allowing -ENOSPC to be returned. That seems to fix recent > regressions with vmwgfx. > > Signed-off-by: Zack Rusin > Reviewed-by: Roland Scheidegger > Reviewed-by: Martin Krastev > Sigend-off-by: Roland Scheidegger > Signed-off-by: Sasha Levin > --- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c > index 7da752ca1c34b..b93c558dd86e0 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c > @@ -57,7 +57,7 @@ static int vmw_gmrid_man_get_node(struct > ttm_mem_type_manager *man, > > id = ida_alloc_max(&gman->gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL); > if (id < 0) > - return (id != -ENOMEM ? 0 : id); > + return id; > > spin_lock(&gman->lock); > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c > index b7c816ba71663..c8b9335bccd8d 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c > @@ -95,7 +95,7 @@ static int vmw_thp_get_node(struct ttm_mem_type_manager > *man, > mem->start = node->start; > } > > - return 0; > + return ret; > } > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path
On Mon, Oct 5, 2020 at 4:02 PM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected by obj->lock, we no longer depend
> > > on struct_mutex.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_gem.c | 1 -
> > > drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
> > > 2 files changed, 55 deletions(-)
> > >
> > [...]
> >
> > > @@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker,
> > > struct shrink_control *sc)
> > > {
> > > struct msm_drm_private *priv =
> > > container_of(shrinker, struct msm_drm_private, shrinker);
> > > - struct drm_device *dev = priv->dev;
> > > struct msm_gem_object *msm_obj;
> > > unsigned long freed = 0;
> > > - bool unlock;
> > > -
> > > - if (!msm_gem_shrinker_lock(dev, &unlock))
> > > - return SHRINK_STOP;
> > >
> > > mutex_lock(&priv->mm_lock);
> >
> > Better if the change in behavior is documented that SHRINK_STOP will
> > no longer be needed.
>
> btw I read through this and noticed you have your own obj lock, plus
> mutex_lock_nested. I strongly recommend to just cut over to dma_resv_lock
> for all object lock needs (soc drivers have been terrible with this
> unfortuntaly), and in the shrinker just use dma_resv_trylock instead of
> trying to play clever games outsmarting lockdep.
>
> I recently wrote an entire blog length rant on why I think
> mutex_lock_nested is too dangerous to be useful:
>
> https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
>
> Not anything about this here, just general comment. The problem extends to
> shmem helpers and all that also having their own locks for everything.
This is definitely a tangible improvement though - very happy to see
msm_gem_shrinker_lock() go.
Reviewed-by: Kristian H. Kristensen
> -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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, October 05, 2020 6:13 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Sun, Oct 04, 2020 at 12:12:28PM -0700, Jianxin Xiong wrote:
> > Dma-buf is a standard cross-driver buffer sharing mechanism that can
> > be used to support peer-to-peer access from RDMA devices.
> >
> > Device memory exported via dma-buf is associated with a file descriptor.
> > This is passed to the user space as a property associated with the
> > buffer allocation. When the buffer is registered as a memory region,
> > the file descriptor is passed to the RDMA driver along with other
> > parameters.
> >
> > Implement the common code for importing dma-buf object and mapping
> > dma-buf pages.
> >
> > Signed-off-by: Jianxin Xiong
> > Reviewed-by: Sean Hefty
> > Acked-by: Michael J. Ruhl
> > ---
> > drivers/infiniband/core/Makefile | 2 +-
> > drivers/infiniband/core/umem.c| 4 +
> > drivers/infiniband/core/umem_dmabuf.c | 291
> > ++
> > drivers/infiniband/core/umem_dmabuf.h | 14 ++
> > drivers/infiniband/core/umem_odp.c| 12 ++
> > include/rdma/ib_umem.h| 19 ++-
> > 6 files changed, 340 insertions(+), 2 deletions(-) create mode
> > 100644 drivers/infiniband/core/umem_dmabuf.c
> > create mode 100644 drivers/infiniband/core/umem_dmabuf.h
>
> I think this is using ODP too literally, dmabuf isn't going to need fine
> grained page faults, and I'm not sure this locking scheme is OK - ODP is
> horrifically complicated.
>
> If this is the approach then I think we should make dmabuf its own stand
> alone API, reg_user_mr_dmabuf()
That's the original approach in the first version. We can go back there.
>
> The implementation in mlx5 will be much more understandable, it would just do
> dma_buf_dynamic_attach() and program the XLT exactly
> the same as a normal umem.
>
> The move_notify() simply zap's the XLT and triggers a work to reload it after
> the move. Locking is provided by the dma_resv_lock. Only a
> small disruption to the page fault handler is needed.
>
We considered such scheme but didn't go that way due to the lack of
notification when the move is done and thus the work wouldn't know when it can
reload.
Now I think it again, we could probably signal the reload in the page fault
handler.
> > + dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> > + sgt = dma_buf_map_attachment(umem_dmabuf->attach,
> > +DMA_BIDIRECTIONAL);
> > + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
>
> This doesn't look right, this lock has to be held up until the HW is
> programmed
The mapping remains valid until being invalidated again. There is a sequence
number checking before programming the HW.
>
> The use of atomic looks probably wrong as well.
Do you mean umem_dmabuf->notifier_seq? Could you elaborate the concern?
>
> > + k = 0;
> > + total_pages = ib_umem_odp_num_pages(umem_odp);
> > + for_each_sg(umem->sg_head.sgl, sg, umem->sg_head.nents, j) {
> > + addr = sg_dma_address(sg);
> > + pages = sg_dma_len(sg) >> page_shift;
> > + while (pages > 0 && k < total_pages) {
> > + umem_odp->dma_list[k++] = addr | access_mask;
> > + umem_odp->npages++;
> > + addr += page_size;
> > + pages--;
>
> This isn't fragmenting the sg into a page list properly, won't work for
> unaligned things
I thought the addresses are aligned, but will add explicit alignment here.
>
> And really we don't need the dma_list for this case, with a fixed whole
> mapping DMA SGL a normal umem sgl is OK and the normal umem
> XLT programming in mlx5 is fine.
The dma_list is used by both "polulate_mtt()" and "mlx5_ib_invalidate_range",
which are used for XLT programming and invalidating (zapping), respectively.
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/14] drm/msm: Refcount submits
On Mon, Oct 5, 2020 at 6:56 AM Daniel Vetter wrote:
>
> On Sun, Oct 04, 2020 at 12:21:39PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Before we remove dev->struct_mutex from the retire path, we have to deal
> > with the situation of a submit retiring before the submit ioctl returns.
> >
> > To deal with this, ring->submits will hold a reference to the submit,
> > which is dropped when the submit is retired. And the submit ioctl path
> > holds it's own ref, which it drops when it is done with the submit.
> >
> > Also, add to submit list *after* getting/pinning bo's, to prevent badness
> > in case the completed fence is corrupted, and retire_worker mistakenly
> > believes the submit is done too early.
> >
> > Signed-off-by: Rob Clark
>
> Why not embed the dma_fence instead of pointer and use that refcount? i915
> does that, and imo kinda makes sense instead of more refcounted things.
> But might not make sense for msm.
I guess that might work.. the one thing I'd be concerned about is that
the submit (indirectly) holds reference to the file ctx, so userspace
keeping around a fence fd by mistake could keep a set of pgtables live
unnecessarily.. I suppose we could re-work where we drop that
reference.
six of one, half-dozen of the other, I guess
BR,
-R
> -Daniel
>
> > ---
> > drivers/gpu/drm/msm/msm_drv.h| 1 -
> > drivers/gpu/drm/msm/msm_gem.h| 13 +
> > drivers/gpu/drm/msm/msm_gem_submit.c | 12 ++--
> > drivers/gpu/drm/msm/msm_gpu.c| 21 -
> > 4 files changed, 35 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index 50978e5db376..535f9e718e2d 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -277,7 +277,6 @@ void msm_unregister_mmu(struct drm_device *dev, struct
> > msm_mmu *mmu);
> >
> > bool msm_use_mmu(struct drm_device *dev);
> >
> > -void msm_gem_submit_free(struct msm_gem_submit *submit);
> > int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
> > struct drm_file *file);
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> > index a1bf741b9b89..e05b1530aca6 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > @@ -136,6 +136,7 @@ void msm_gem_free_work(struct work_struct *work);
> > * lasts for the duration of the submit-ioctl.
> > */
> > struct msm_gem_submit {
> > + struct kref ref;
> > struct drm_device *dev;
> > struct msm_gpu *gpu;
> > struct msm_gem_address_space *aspace;
> > @@ -169,6 +170,18 @@ struct msm_gem_submit {
> > } bos[];
> > };
> >
> > +void __msm_gem_submit_destroy(struct kref *kref);
> > +
> > +static inline void msm_gem_submit_get(struct msm_gem_submit *submit)
> > +{
> > + kref_get(&submit->ref);
> > +}
> > +
> > +static inline void msm_gem_submit_put(struct msm_gem_submit *submit)
> > +{
> > + kref_put(&submit->ref, __msm_gem_submit_destroy);
> > +}
> > +
> > /* helper to determine of a buffer in submit should be dumped, used for
> > both
> > * devcoredump and debugfs cmdstream dumping:
> > */
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index e1d1f005b3d4..7d653bdc92dc 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -42,6 +42,7 @@ static struct msm_gem_submit *submit_create(struct
> > drm_device *dev,
> > if (!submit)
> > return NULL;
> >
> > + kref_init(&submit->ref);
> > submit->dev = dev;
> > submit->aspace = queue->ctx->aspace;
> > submit->gpu = gpu;
> > @@ -60,12 +61,12 @@ static struct msm_gem_submit *submit_create(struct
> > drm_device *dev,
> > return submit;
> > }
> >
> > -void msm_gem_submit_free(struct msm_gem_submit *submit)
> > +void __msm_gem_submit_destroy(struct kref *kref)
> > {
> > + struct msm_gem_submit *submit =
> > + container_of(kref, struct msm_gem_submit, ref);
> > +
> > dma_fence_put(submit->fence);
> > - spin_lock(&submit->ring->submit_lock);
> > - list_del(&submit->node);
> > - spin_unlock(&submit->ring->submit_lock);
> > put_pid(submit->pid);
> > msm_submitqueue_put(submit->queue);
> >
> > @@ -805,8 +806,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > *data,
> > submit_cleanup(submit);
> > if (has_ww_ticket)
> > ww_acquire_fini(&submit->ticket);
> > - if (ret)
> > - msm_gem_submit_free(submit);
> > + msm_gem_submit_put(submit);
> > out_unlock:
> > if (ret && (out_fence_fd >= 0))
> > put_unused_fd(out_fence_fd);
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index 8d1e254f964a..fd3fc6f36ab1 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @
Re: [Freedreno] [PATCH 00/14] drm/msm: de-struct_mutex-ification
On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote: > > From: Rob Clark > > This doesn't remove *all* the struct_mutex, but it covers the worst > of it, ie. shrinker/madvise/free/retire. The submit path still uses > struct_mutex, but it still needs *something* serialize a portion of > the submit path, and lock_stat mostly just shows the lock contention > there being with other submits. And there are a few other bits of > struct_mutex usage in less critical paths (debugfs, etc). But this > seems like a reasonable step in the right direction. What a great patch set. Daniel has some good points and nothing that requires big changes, but on the other hand, I'm not sure it's something that needs to block this set either. Either way, for the series Reviewed-by: Kristian H. Kristensen > Rob Clark (14): > drm/msm: Use correct drm_gem_object_put() in fail case > drm/msm: Drop chatty trace > drm/msm: Move update_fences() > drm/msm: Add priv->mm_lock to protect active/inactive lists > drm/msm: Document and rename preempt_lock > drm/msm: Protect ring->submits with it's own lock > drm/msm: Refcount submits > drm/msm: Remove obj->gpu > drm/msm: Drop struct_mutex from the retire path > drm/msm: Drop struct_mutex in free_object() path > drm/msm: remove msm_gem_free_work > drm/msm: drop struct_mutex in madvise path > drm/msm: Drop struct_mutex in shrinker path > drm/msm: Don't implicit-sync if only a single ring > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- > drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 +-- > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- > drivers/gpu/drm/msm/msm_debugfs.c | 7 ++ > drivers/gpu/drm/msm/msm_drv.c | 15 +--- > drivers/gpu/drm/msm/msm_drv.h | 19 +++-- > drivers/gpu/drm/msm/msm_gem.c | 76 ++ > drivers/gpu/drm/msm/msm_gem.h | 53 + > drivers/gpu/drm/msm/msm_gem_shrinker.c| 58 ++ > drivers/gpu/drm/msm/msm_gem_submit.c | 17 ++-- > drivers/gpu/drm/msm/msm_gpu.c | 96 ++- > drivers/gpu/drm/msm/msm_gpu.h | 5 +- > drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +- > drivers/gpu/drm/msm/msm_ringbuffer.h | 13 ++- > 14 files changed, 188 insertions(+), 194 deletions(-) > > -- > 2.26.2 > > ___ > Freedreno mailing list > freedr...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path
On Mon, Oct 5, 2020 at 7:02 AM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> >
> > On Sun, 4 Oct 2020 12:21:45
> > > From: Rob Clark
> > >
> > > Now that the inactive_list is protected by mm_lock, and everything
> > > else on per-obj basis is protected by obj->lock, we no longer depend
> > > on struct_mutex.
> > >
> > > Signed-off-by: Rob Clark
> > > ---
> > > drivers/gpu/drm/msm/msm_gem.c | 1 -
> > > drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
> > > 2 files changed, 55 deletions(-)
> > >
> > [...]
> >
> > > @@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker,
> > > struct shrink_control *sc)
> > > {
> > > struct msm_drm_private *priv =
> > > container_of(shrinker, struct msm_drm_private, shrinker);
> > > - struct drm_device *dev = priv->dev;
> > > struct msm_gem_object *msm_obj;
> > > unsigned long freed = 0;
> > > - bool unlock;
> > > -
> > > - if (!msm_gem_shrinker_lock(dev, &unlock))
> > > - return SHRINK_STOP;
> > >
> > > mutex_lock(&priv->mm_lock);
> >
> > Better if the change in behavior is documented that SHRINK_STOP will
> > no longer be needed.
>
> btw I read through this and noticed you have your own obj lock, plus
> mutex_lock_nested. I strongly recommend to just cut over to dma_resv_lock
> for all object lock needs (soc drivers have been terrible with this
> unfortuntaly), and in the shrinker just use dma_resv_trylock instead of
> trying to play clever games outsmarting lockdep.
>
> I recently wrote an entire blog length rant on why I think
> mutex_lock_nested is too dangerous to be useful:
>
> https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
>
> Not anything about this here, just general comment. The problem extends to
> shmem helpers and all that also having their own locks for everything.
the shrinker lock class has existed for a while.. and is based on the
idea that anything in the get-pages/vmap path cannot happen on a
WONTNEED bo.. although perhaps there should be a few more 'if
(WARN_ON(obj->madv != WILLNEED)) return -EBUSY'..
replacing obj->lock with dma_resv lock, might be a nice cleanup.. but
I think it will be a bit churny..
BR,
-R
> -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 6/8] drm/ttm: add caching state to ttm_bus_placement
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 6/8] drm/ttm: add caching state to ttm_bus_placement
>
>And implement setting it up correctly in the drivers.
>
>This allows getting rid of the placement flags for this.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
> drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
> drivers/gpu/drm/nouveau/nouveau_bo.c | 11 +++
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 ++
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
> include/drm/ttm/ttm_resource.h | 8 +---
> 7 files changed, 23 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 7f41a47e7353..5b56a66063fd 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -769,6 +769,7 @@ static int amdgpu_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_reso
>
> mem->bus.offset += adev->gmc.aper_base;
> mem->bus.is_iomem = true;
>+ mem->bus.caching = ttm_write_combined;
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 62235926e077..79151b1c157c 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -961,6 +961,7 @@ static int bo_driver_io_mem_reserve(struct
>ttm_bo_device *bdev,
> case TTM_PL_VRAM:
> mem->bus.offset = (mem->start << PAGE_SHIFT) + vmm-
>>vram_base;
> mem->bus.is_iomem = true;
>+ mem->bus.caching = ttm_write_combined;
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>b/drivers/gpu/drm/nouveau/nouveau_bo.c
>index 1d4b16c0e353..8ed30f471ec7 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>@@ -1124,6 +1124,8 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> struct nouveau_drm *drm = nouveau_bdev(bdev);
> struct nvkm_device *device = nvxx_device(&drm->client.device);
> struct nouveau_mem *mem = nouveau_mem(reg);
>+ struct nvif_mmu *mmu = &drm->client.mmu;
>+ const u8 type = mmu->type[drm->ttm.type_vram].type;
> int ret;
>
> mutex_lock(&drm->ttm.io_reserve_mutex);
>@@ -1139,6 +1141,7 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> reg->bus.offset = (reg->start << PAGE_SHIFT) +
> drm->agp.base;
> reg->bus.is_iomem = !drm->agp.cma;
Don't really know if this is true or not, so I will take your word on it. 😊
>+ reg->bus.caching = ttm_write_combined;
> }
> #endif
> if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 ||
>@@ -1152,6 +1155,14 @@ nouveau_ttm_io_mem_reserve(struct
>ttm_bo_device *bdev, struct ttm_resource *reg)
> reg->bus.offset = (reg->start << PAGE_SHIFT) +
> device->func->resource_addr(device, 1);
> reg->bus.is_iomem = true;
>+
>+ /* Some BARs do not support being ioremapped WC */
>+ if (drm->client.device.info.family >=
>NV_DEVICE_INFO_V0_TESLA &&
>+ type & NVIF_MEM_UNCACHED)
>+ reg->bus.caching = ttm_uncached;
>+ else
>+ reg->bus.caching = ttm_write_combined;
>+
> if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
> union {
> struct nv50_mem_map_v0 nv50;
>diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
>index dcf4ac1480c7..e79d4df99790 100644
>--- a/drivers/gpu/drm/qxl/qxl_ttm.c
>+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
>@@ -83,11 +83,13 @@ int qxl_ttm_io_mem_reserve(struct ttm_bo_device
>*bdev,
> case TTM_PL_VRAM:
> mem->bus.is_iomem = true;
> mem->bus.offset = (mem->start << PAGE_SHIFT) + qdev-
>>vram_base;
>+ mem->bus.caching = ttm_cached;
> break;
> case TTM_PL_PRIV:
> mem->bus.is_iomem = true;
> mem->bus.offset = (mem->start << PAGE_SHIFT) +
> qdev->surfaceram_base;
>+ mem->bus.caching = ttm_cached;
is_iomem = true and ttm_cached is correct?
qxl is a software gpu?
If this is true, then this looks reasonable.
Reviewed-by: Michael J. Ruhl
M
> break;
> default:
> return -EINVAL;
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>b/drivers/gpu/
Re: [PATCH] Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
On Mon, Oct 5, 2020 at 4:47 PM Paul Cercueil wrote: > > Hi, > > Le lun. 5 oct. 2020 à 16:05, Daniel Vetter a écrit : > > On Mon, Oct 05, 2020 at 11:01:50PM +1100, Stephen Rothwell wrote: > >> Hi Paul, > >> > >> On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil > >> wrote: > >> > > >> > Pushed to drm-misc-next with the changelog fix, thanks. > >> > > >> > Stephen: > >> > Now it should build fine again. Could you remove the BROKEN flag? > >> > >> Thanks for letting me know, but the fix has not appeared in any drm > >> tree included in linux-next yet ... > >> > >> If it doesn't show up by the time I will merge the drm tree > >> tomorrow, I > >> will apply this revert patch myself (instead of the patch marking > >> the > >> driver BROKEN). > > > > Yeah it should have been pushed to drm-misc-next-fixes per > > > > https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch > > > > Paul, can you pls git cherry-pick -x this over to drm-misc-next-fixes? > > I had a few commits on top of it in drm-misc-next, so the revert > doesn't apply cleanly in drm-misc-next-fixes... I can revert it there, > but then we'd have a different revert commit in drm-misc-next and > drm-misc-next-next. > > Sorry for the mess. What should I do? We need the revert in drm-misc-next-fixes or the drm-next pull request doesn't work out. So cherry-pick over, fix up conflicts, push the tree, and don't forget to fix up the conflicts when dim rebuilds drm-tip. Also tell drm-misc maintainers what you've done, they probably want to do a backmerge to clean this up a bit once the drm-next pull request has landed. -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 2/2] mm/frame-vec: use FOLL_LONGTERM
On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> be allowed to extract a struct page from a normal VMA. This could allow a
> serious use-after-free problem on any kernel memory.
>
> Restrict this to only work on VMA's with one of VM_IO | VM_PFNMAP
> set. This limits the use-after-free problem to only IO memory, which while
> still serious, is an improvement.
>
> Cc: sta...@vger.kernel.org
> Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
> Signed-off-by: Jason Gunthorpe
> ---
> mm/frame_vector.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 10f82d5643b6de..26cb20544b6c37 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -99,6 +99,10 @@ int get_vaddr_frames(unsigned long start, unsigned int
> nr_frames,
> if (ret >= nr_frames || start < vma->vm_end)
> break;
> vma = find_vma_intersection(mm, start, start + 1);
> + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> + ret = -EINVAL;
> + goto out;
> + }
> } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
Hum, I fail to see how this helps. If vma has no VM_IO or VM_PFNMAP flag,
we'd exit the loop (to out: label) anyway due to the loop termination
condition and why not return the frames we already have? Furthermore
find_vma_intersection() can return NULL which would oops in your check
then. What am I missing?
Honza
> out:
> if (locked)
> --
> 2.28.0
>
--
Jan Kara
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Mon, Oct 5, 2020 at 7:58 PM Jason Gunthorpe wrote:
>
> On Mon, Oct 05, 2020 at 07:53:08PM +0200, Jan Kara wrote:
> > On Mon 05-10-20 14:38:54, Jason Gunthorpe wrote:
> > > When get_vaddr_frames() does its hacky follow_pfn() loop it should never
> > > be allowed to extract a struct page from a normal VMA. This could allow a
> > > serious use-after-free problem on any kernel memory.
> > >
> > > Restrict this to only work on VMA's with one of VM_IO | VM_PFNMAP
> > > set. This limits the use-after-free problem to only IO memory, which while
> > > still serious, is an improvement.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Fixes: 8025e5ddf9c1 ("[media] mm: Provide new get_vaddr_frames() helper")
> > > Signed-off-by: Jason Gunthorpe
> > > mm/frame_vector.c | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> > > index 10f82d5643b6de..26cb20544b6c37 100644
> > > +++ b/mm/frame_vector.c
> > > @@ -99,6 +99,10 @@ int get_vaddr_frames(unsigned long start, unsigned int
> > > nr_frames,
> > > if (ret >= nr_frames || start < vma->vm_end)
> > > break;
> > > vma = find_vma_intersection(mm, start, start + 1);
> > > + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> > > } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
> >
> > Hum, I fail to see how this helps. If vma has no VM_IO or VM_PFNMAP flag,
> > we'd exit the loop (to out: label) anyway due to the loop termination
> > condition and why not return the frames we already have? Furthermore
> > find_vma_intersection() can return NULL which would oops in your check
> > then. What am I missing?
>
> Oh, nothing, you are right. It just didn't read naturally because
> hitting the wrong kind of VMA should be an error condition :\
Afaik these mmio maps should all be VM_DONTEXPAND (or at least the
ones in drivers/gpu are all), so not sure why we need the loop here.
But maybe there's some drivers that don't set that, or have other
funny things going on with userspace piecing the mmap together, and
I'm not going to audit them all :-)
-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 2/2] mm/frame-vec: use FOLL_LONGTERM
On Mon, Oct 5, 2020 at 7:28 PM Jason Gunthorpe wrote: > > On Sun, Oct 04, 2020 at 06:09:29PM +0200, Daniel Vetter wrote: > > On Sun, Oct 4, 2020 at 2:51 PM Jason Gunthorpe wrote: > > > > > > On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > > > > > > > That leaves the only interesting places as vb2_dc_get_userptr() and > > > > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > > > > REQUIRED behavior in the function's comment about checking PTEs. It > > > > > just DMA maps them. Badly broken. > > > > > > > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > > > > > > > Yeah, see also the follow_pfn trickery in > > > > videobuf_dma_contig_user_get(), I think this is fully intentional and > > > > userspace abi we can't break :-/ > > > > > > We don't need to break uABI, it just needs to work properly in the > > > kernel: > > > > > > vma = find_vma_intersection() > > > dma_buf = dma_buf_get_from_vma(vma) > > > sg = dma_buf_p2p_dma_map(dma_buf) > > > [.. do dma ..] > > > dma_buf_unmap(sg) > > > dma_buf_put(dma_buf) > > > > > > It is as we discussed before, dma buf needs to be discoverable from a > > > VMA, at least for users doing this kind of stuff. > > > > I'm not a big fan of magic behaviour like this, there's more to > > dma-buf buffer sharing than just "how do I get at the backing > > storage". Thus far we've done everything rather explicitly. Plus with > > exynos and habanalabs converted there's only v4l left over, and that > > has a proper dma-buf import path already. > > Well, any VA approach like this has to access some backing refcount > via the VMA. Not really any way to avoid something like that > > > > A VM flag doesn't help - we need to introduce some kind of lifetime, > > > and that has to be derived from the VMA. It needs data not just a flag > > > > I don't want to make it work, I just want to make it fail. Rough idea > > I have in mind is to add a follow_pfn_longterm, for all callers which > > aren't either synchronized through mmap_sem or an mmu_notifier. > > follow_pfn() doesn't work outside the pagetable locks or mmu notifier > protection. Can't be fixed. > > We only have a few users: > > arch/s390/pci/pci_mmio.c: ret = follow_pfn(vma, user_addr, pfn); > drivers/media/v4l2-core/videobuf-dma-contig.c: ret = follow_pfn(vma, > user_address, &this_pfn); > drivers/vfio/vfio_iommu_type1.c:ret = follow_pfn(vma, vaddr, pfn); > drivers/vfio/vfio_iommu_type1.c:ret = follow_pfn(vma, vaddr, > pfn); > mm/frame_vector.c: err = follow_pfn(vma, start, > &nums[ret]); > virt/kvm/kvm_main.c:r = follow_pfn(vma, addr, &pfn); > virt/kvm/kvm_main.c:r = follow_pfn(vma, addr, &pfn); > > VFIO is broken like media, but I saw patches fixing the vfio cases > using the VMA and a vfio specific refcount. > > media & frame_vector we are talking about here. > > kvm is some similar hack added for P2P DMA, see commit > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by notifiers.. Yeah my thinking is that kvm (and I think also vfio, also seems to have mmu notifier nearby) are ok because of the mmu notiifer. Assuming that one works correctly. > s390 looks broken too, needs to hold the page table locks. Hm yeah I guess that looks fairly reasonable to fix too. > So, the answer really is that s390 and media need fixing, and this API > should go away (or become kvm specific) I'm still not clear how you want fo fix this, since your vma->dma_buf idea is kinda a decade long plan and so just not going to happen: - v4l used this mostly (afaik the lore at least) for buffer sharing with v4l itself, and also a bit with fbdev. Neither even has any dma-buf exporter code as-is. - like I said, there's no central dma-buf instance, it was fairly intentionally create as an all-to-all abstraction. Which means you either have to roll out a vm_ops->gimme_the_dmabuf or, even more work, refactor all the dma-buf exporters to go through the same things - even where we have dma-buf, most mmaps of buffer objects aren't a dma-buf. Those are only set up when userspace explicitly asks for one, so we'd also need to change the mmap code of all drivers involved to make sure the dma-buf is always created when we do any kind of mmap. I don't see that as a realistic thing to ever happen, and meanwhile we can't leave the gap open for a few years. > > If this really breaks anyone's use-case we can add a tainting kernel > > option which re-enables this (we've done something similar for > > phys_addr_t based buffer sharing in fbdev, entirely unfixable since > > the other driver has to just blindly trust that what userspace > > passes around is legit). This here isn't unfixable, but if v4l > > people want to keep it without a big "security hole here" sticker, > > they should do the work, not me :-) > > This seems fairly reasonable.. > > So after frame_vec is purged and we have the one caller in m
Re: [PATCH 13/14] drm/msm: Drop struct_mutex in shrinker path
On Mon, Oct 5, 2020 at 6:49 PM Rob Clark wrote:
>
> On Mon, Oct 5, 2020 at 7:02 AM Daniel Vetter wrote:
> >
> > On Mon, Oct 05, 2020 at 05:24:19PM +0800, Hillf Danton wrote:
> > >
> > > On Sun, 4 Oct 2020 12:21:45
> > > > From: Rob Clark
> > > >
> > > > Now that the inactive_list is protected by mm_lock, and everything
> > > > else on per-obj basis is protected by obj->lock, we no longer depend
> > > > on struct_mutex.
> > > >
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > > drivers/gpu/drm/msm/msm_gem.c | 1 -
> > > > drivers/gpu/drm/msm/msm_gem_shrinker.c | 54 --
> > > > 2 files changed, 55 deletions(-)
> > > >
> > > [...]
> > >
> > > > @@ -71,13 +33,8 @@ msm_gem_shrinker_scan(struct shrinker *shrinker,
> > > > struct shrink_control *sc)
> > > > {
> > > > struct msm_drm_private *priv =
> > > > container_of(shrinker, struct msm_drm_private, shrinker);
> > > > - struct drm_device *dev = priv->dev;
> > > > struct msm_gem_object *msm_obj;
> > > > unsigned long freed = 0;
> > > > - bool unlock;
> > > > -
> > > > - if (!msm_gem_shrinker_lock(dev, &unlock))
> > > > - return SHRINK_STOP;
> > > >
> > > > mutex_lock(&priv->mm_lock);
> > >
> > > Better if the change in behavior is documented that SHRINK_STOP will
> > > no longer be needed.
> >
> > btw I read through this and noticed you have your own obj lock, plus
> > mutex_lock_nested. I strongly recommend to just cut over to dma_resv_lock
> > for all object lock needs (soc drivers have been terrible with this
> > unfortuntaly), and in the shrinker just use dma_resv_trylock instead of
> > trying to play clever games outsmarting lockdep.
> >
> > I recently wrote an entire blog length rant on why I think
> > mutex_lock_nested is too dangerous to be useful:
> >
> > https://blog.ffwll.ch/2020/08/lockdep-false-positives.html
> >
> > Not anything about this here, just general comment. The problem extends to
> > shmem helpers and all that also having their own locks for everything.
>
> the shrinker lock class has existed for a while.. and is based on the
> idea that anything in the get-pages/vmap path cannot happen on a
> WONTNEED bo.. although perhaps there should be a few more 'if
> (WARN_ON(obj->madv != WILLNEED)) return -EBUSY'..
Yeah it works, but it's the kind of really clever stuff that
eventually bites again. For pretty much no benefit, if the lock is
held then you can assume someone else is using the object and you
won't be able to shrink it anyway. So trylock is enough.
> replacing obj->lock with dma_resv lock, might be a nice cleanup.. but
> I think it will be a bit churny..
Oh fully agreed, I tried to push the helpers a bit in that direction
for shmem/cma and gave up. Just something I think we should have in
mind. And in case your gpu ever becomes discrete ... yes the churn is
terrible :-/
-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: [Freedreno] [PATCH 00/14] drm/msm: de-struct_mutex-ification
On Mon, Oct 5, 2020 at 6:24 PM Kristian Høgsberg wrote: > > On Sun, Oct 4, 2020 at 9:21 PM Rob Clark wrote: > > > > From: Rob Clark > > > > This doesn't remove *all* the struct_mutex, but it covers the worst > > of it, ie. shrinker/madvise/free/retire. The submit path still uses > > struct_mutex, but it still needs *something* serialize a portion of > > the submit path, and lock_stat mostly just shows the lock contention > > there being with other submits. And there are a few other bits of > > struct_mutex usage in less critical paths (debugfs, etc). But this > > seems like a reasonable step in the right direction. > > What a great patch set. Daniel has some good points and nothing that > requires big changes, but on the other hand, I'm not sure it's > something that needs to block this set either. Personally I'd throw the lockdep priming on top to make sure this stays correct (it's 3 lines), but yes imo this is all good to go. Just figured I'll sprinkle the latest in terms of gem locking over the series while it's here :-) -Daniel > Either way, for the series > > Reviewed-by: Kristian H. Kristensen > > > Rob Clark (14): > > drm/msm: Use correct drm_gem_object_put() in fail case > > drm/msm: Drop chatty trace > > drm/msm: Move update_fences() > > drm/msm: Add priv->mm_lock to protect active/inactive lists > > drm/msm: Document and rename preempt_lock > > drm/msm: Protect ring->submits with it's own lock > > drm/msm: Refcount submits > > drm/msm: Remove obj->gpu > > drm/msm: Drop struct_mutex from the retire path > > drm/msm: Drop struct_mutex in free_object() path > > drm/msm: remove msm_gem_free_work > > drm/msm: drop struct_mutex in madvise path > > drm/msm: Drop struct_mutex in shrinker path > > drm/msm: Don't implicit-sync if only a single ring > > > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- > > drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 +-- > > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- > > drivers/gpu/drm/msm/msm_debugfs.c | 7 ++ > > drivers/gpu/drm/msm/msm_drv.c | 15 +--- > > drivers/gpu/drm/msm/msm_drv.h | 19 +++-- > > drivers/gpu/drm/msm/msm_gem.c | 76 ++ > > drivers/gpu/drm/msm/msm_gem.h | 53 + > > drivers/gpu/drm/msm/msm_gem_shrinker.c| 58 ++ > > drivers/gpu/drm/msm/msm_gem_submit.c | 17 ++-- > > drivers/gpu/drm/msm/msm_gpu.c | 96 ++- > > drivers/gpu/drm/msm/msm_gpu.h | 5 +- > > drivers/gpu/drm/msm/msm_ringbuffer.c | 3 +- > > drivers/gpu/drm/msm/msm_ringbuffer.h | 13 ++- > > 14 files changed, 188 insertions(+), 194 deletions(-) > > > > -- > > 2.26.2 > > > > ___ > > Freedreno mailing list > > freedr...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/freedreno > ___ > 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 7/8] drm/ttm: use caching instead of placement for ttm_io_prot
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 7/8] drm/ttm: use caching instead of placement for
>ttm_io_prot
>
>Instead of the placement flags use the caching of the bus
>mapping or tt object for the page protection flags.
>
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/ttm/ttm_bo_util.c| 23 ++-
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
> include/drm/ttm/ttm_bo_driver.h | 6 --
> 4 files changed, 21 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>b/drivers/gpu/drm/ttm/ttm_bo_util.c
>index bdee4df1f3f2..0542097dc419 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>@@ -279,13 +279,11 @@ int ttm_bo_move_memcpy(struct
>ttm_buffer_object *bo,
> for (i = 0; i < new_mem->num_pages; ++i) {
> page = i * dir + add;
> if (old_iomap == NULL) {
>- pgprot_t prot = ttm_io_prot(old_mem->placement,
>- PAGE_KERNEL);
So will placement get removed from ttm_resource?
Reviewed-by: Michael J. Ruhl
M
>+ pgprot_t prot = ttm_io_prot(bo, old_mem,
>PAGE_KERNEL);
> ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
> prot);
> } else if (new_iomap == NULL) {
>- pgprot_t prot = ttm_io_prot(new_mem->placement,
>- PAGE_KERNEL);
>+ pgprot_t prot = ttm_io_prot(bo, new_mem,
>PAGE_KERNEL);
> ret = ttm_copy_io_ttm_page(ttm, old_iomap, page,
> prot);
> } else {
>@@ -384,21 +382,28 @@ static int ttm_buffer_object_transfer(struct
>ttm_buffer_object *bo,
> return 0;
> }
>
>-pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>+pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource
>*res,
>+ pgprot_t tmp)
> {
>+ struct ttm_resource_manager *man;
>+ enum ttm_caching caching;
>+
>+ man = ttm_manager_type(bo->bdev, res->mem_type);
>+ caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
>+
> /* Cached mappings need no adjustment */
>- if (caching_flags & TTM_PL_FLAG_CACHED)
>+ if (caching == ttm_cached)
> return tmp;
>
> #if defined(__i386__) || defined(__x86_64__)
>- if (caching_flags & TTM_PL_FLAG_WC)
>+ if (caching == ttm_write_combined)
> tmp = pgprot_writecombine(tmp);
> else if (boot_cpu_data.x86 > 3)
> tmp = pgprot_noncached(tmp);
> #endif
> #if defined(__ia64__) || defined(__arm__) || defined(__aarch64__) || \
> defined(__powerpc__) || defined(__mips__)
>- if (caching_flags & TTM_PL_FLAG_WC)
>+ if (caching == ttm_write_combined)
> tmp = pgprot_writecombine(tmp);
> else
> tmp = pgprot_noncached(tmp);
>@@ -466,7 +471,7 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object
>*bo,
>* We need to use vmap to get the desired page protection
>* or to make the buffer object look contiguous.
>*/
>- prot = ttm_io_prot(mem->placement, PAGE_KERNEL);
>+ prot = ttm_io_prot(bo, mem, PAGE_KERNEL);
> map->bo_kmap_type = ttm_bo_map_vmap;
> map->virtual = vmap(ttm->pages + start_page, num_pages,
> 0, prot);
>diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>index 87ee8f0ca08e..eeaca5d1efe3 100644
>--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>@@ -310,7 +310,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct
>vm_fault *vmf,
> if (unlikely(page_offset >= bo->num_pages))
> return VM_FAULT_SIGBUS;
>
>- prot = ttm_io_prot(bo->mem.placement, prot);
>+ prot = ttm_io_prot(bo, &bo->mem, prot);
> if (!bo->mem.bus.is_iomem) {
> struct ttm_operation_ctx ctx = {
> .interruptible = false,
>diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>index ea2f2f937eb3..f21881e087db 100644
>--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
>@@ -484,8 +484,8 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
> d.src_pages = src->ttm->pages;
> d.dst_num_pages = dst->num_pages;
> d.src_num_pages = src->num_pages;
>- d.dst_prot = ttm_io_prot(dst->mem.placement, PAGE_KERNEL);
>- d.src_prot = ttm_io_prot(src->mem.placement, PAGE_KERNEL);
>+ d.dst_prot = ttm_io_prot(dst, &dst->mem, PAGE_KERNEL);
>+
[PATCH 0/4] dt-bindings: additional/unevaluatedProperties clean-ups
The default behavior for json-schema is any unknown property is allowed. That is generally not the behavior we want for DT. In order to disallow extra properties, schemas need to define 'additionalProperties: false' typically. Ideally, we'd just add that automatically with the tools, but there are some exceptions so only making things explicit everywhere really works. Missing 'additionalProperties' or 'unevaluatedProperties' has been a constant source of review comments, so a meta-schema check is really needed here. Once this series is in place, the meta-schema can be updated with a check. The rule is if there's a $ref to another schema, then either 'additionalProperties' or 'unevaluatedProperties' is required. If not, then 'additionalProperties' is required. Rob Rob Herring (4): dt-bindings: Add missing 'unevaluatedProperties' dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties' dt-bindings: Explicitly allow additional properties in board/SoC schemas dt-bindings: Explicitly allow additional properties in common schemas Documentation/devicetree/bindings/arm/actions.yaml | 2 ++ Documentation/devicetree/bindings/arm/altera.yaml | 3 +++ Documentation/devicetree/bindings/arm/amazon,al.yaml | 2 ++ Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++ .../devicetree/bindings/arm/arm,integrator.yaml| 2 ++ .../devicetree/bindings/arm/arm,realview.yaml | 2 ++ .../devicetree/bindings/arm/arm,versatile.yaml | 2 ++ .../devicetree/bindings/arm/arm,vexpress-juno.yaml | 2 ++ Documentation/devicetree/bindings/arm/atmel-at91.yaml | 2 ++ Documentation/devicetree/bindings/arm/axxia.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,bcm11351.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,bcm21664.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,bcm23550.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,bcm4708.yaml | 3 +++ .../devicetree/bindings/arm/bcm/brcm,cygnus.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,hr2.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,ns2.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,nsp.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,stingray.yaml | 2 ++ .../devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml | 2 ++ Documentation/devicetree/bindings/arm/bitmain.yaml | 3 +++ Documentation/devicetree/bindings/arm/calxeda.yaml | 2 ++ .../devicetree/bindings/arm/coresight-cti.yaml | 2 ++ Documentation/devicetree/bindings/arm/cpus.yaml| 2 ++ Documentation/devicetree/bindings/arm/digicolor.yaml | 2 ++ Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ .../devicetree/bindings/arm/hisilicon/hisilicon.yaml | 3 +++ .../devicetree/bindings/arm/intel,keembay.yaml | 3 +++ .../devicetree/bindings/arm/intel-ixp4xx.yaml | 2 ++ .../bindings/arm/keystone/ti,k3-sci-common.yaml| 2 ++ .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 2 ++ Documentation/devicetree/bindings/arm/mediatek.yaml| 3 +++ .../devicetree/bindings/arm/microchip,sparx5.yaml | 2 ++ Documentation/devicetree/bindings/arm/moxart.yaml | 1 + Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 3 +++ Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 2 ++ .../bindings/arm/nvidia,tegra194-ccplex.yaml | 2 ++ Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml | 2 ++ Documentation/devicetree/bindings/arm/qcom.yaml| 2 ++ Documentation/devicetree/bindings/arm/rda.yaml | 2 ++ Documentation/devicetree/bindings/arm/realtek.yaml | 3 +++ Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++ Documentation/devicetree/bindings/arm/rockchip.yaml| 3 +++ .../bindings/arm/samsung/samsung-boards.yaml | 2 ++ Documentation/devicetree/bindings/arm/sirf.yaml| 3 +++ .../devicetree/bindings/arm/socionext/milbeaut.yaml| 3 +++ .../devicetree/bindings/arm/socionext/uniphier.yaml| 2 ++ Documentation/devicetree/bindings/arm/spear.yaml | 3 +++ Documentation/devicetree/bindings/arm/sprd/sprd.yaml | 2 ++ Documentation/devicetree/bindings/arm/sti.yaml | 3 +++ .../devicetree/bindings/arm/stm32/st,mlahb.yaml| 2 ++ Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 3 +++ Documentation/devicetree/bindings/arm/sunxi.yaml | 2 ++ Documentation/devicetree/bindings/arm/tegra.yaml | 2 ++ Documentation/devicetree/bindings/arm/ti/nspire.yaml | 3 +++ .../devicetree/bindings/arm/ti/ti,davinci.yaml | 3 +++ Documentation/devicetree/bindings/arm/ux500.yaml | 2 ++ Documentation/devicetree/bindings/arm/vt8500.yaml | 3 +++ Documentation/devicetree/bindings/arm/xilinx.yaml | 2 ++ Documentation/devicetree/bindings/arm/zte.yaml | 2 ++
[PATCH 3/4] dt-bindings: Explicitly allow additional properties in board/SoC schemas
In order to add meta-schema checks for additional/unevaluatedProperties being present, all schema need to make this explicit. As the top-level board/SoC schemas always have additional properties, add 'additionalProperties: true'. Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/actions.yaml | 2 ++ Documentation/devicetree/bindings/arm/altera.yaml | 3 +++ Documentation/devicetree/bindings/arm/amazon,al.yaml | 2 ++ Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++ Documentation/devicetree/bindings/arm/arm,integrator.yaml | 2 ++ Documentation/devicetree/bindings/arm/arm,realview.yaml| 2 ++ Documentation/devicetree/bindings/arm/arm,versatile.yaml | 2 ++ Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml | 2 ++ Documentation/devicetree/bindings/arm/atmel-at91.yaml | 2 ++ Documentation/devicetree/bindings/arm/axxia.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml| 3 +++ Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml| 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml| 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml| 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml | 2 ++ Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml | 2 ++ Documentation/devicetree/bindings/arm/bitmain.yaml | 3 +++ Documentation/devicetree/bindings/arm/calxeda.yaml | 2 ++ Documentation/devicetree/bindings/arm/digicolor.yaml | 2 ++ Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml | 3 +++ Documentation/devicetree/bindings/arm/intel,keembay.yaml | 3 +++ Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml| 2 ++ .../devicetree/bindings/arm/keystone/ti,k3-sci-common.yaml | 2 ++ .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 2 ++ Documentation/devicetree/bindings/arm/mediatek.yaml| 3 +++ Documentation/devicetree/bindings/arm/microchip,sparx5.yaml| 2 ++ Documentation/devicetree/bindings/arm/moxart.yaml | 1 + Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml | 3 +++ Documentation/devicetree/bindings/arm/mstar/mstar.yaml | 2 ++ Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml | 2 ++ Documentation/devicetree/bindings/arm/qcom.yaml| 2 ++ Documentation/devicetree/bindings/arm/rda.yaml | 2 ++ Documentation/devicetree/bindings/arm/realtek.yaml | 3 +++ Documentation/devicetree/bindings/arm/renesas.yaml | 2 ++ Documentation/devicetree/bindings/arm/rockchip.yaml| 3 +++ .../devicetree/bindings/arm/samsung/samsung-boards.yaml| 2 ++ Documentation/devicetree/bindings/arm/sirf.yaml| 3 +++ Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml | 3 +++ Documentation/devicetree/bindings/arm/socionext/uniphier.yaml | 2 ++ Documentation/devicetree/bindings/arm/spear.yaml | 3 +++ Documentation/devicetree/bindings/arm/sprd/sprd.yaml | 2 ++ Documentation/devicetree/bindings/arm/sti.yaml | 3 +++ Documentation/devicetree/bindings/arm/stm32/stm32.yaml | 3 +++ Documentation/devicetree/bindings/arm/sunxi.yaml | 2 ++ Documentation/devicetree/bindings/arm/tegra.yaml | 2 ++ Documentation/devicetree/bindings/arm/ti/nspire.yaml | 3 +++ Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml | 3 +++ Documentation/devicetree/bindings/arm/ux500.yaml | 2 ++ Documentation/devicetree/bindings/arm/vt8500.yaml | 3 +++ Documentation/devicetree/bindings/arm/xilinx.yaml | 2 ++ Documentation/devicetree/bindings/arm/zte.yaml | 2 ++ Documentation/devicetree/bindings/mips/ingenic/devices.yaml| 3 +++ Documentation/devicetree/bindings/mips/loongson/devices.yaml | 3 +++ Documentation/devicetree/bindings/riscv/sifive.yaml| 3 +++ 60 files changed, 140 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml index 14023f0a8552..9d12984691e4 100644 --- a/Documentation/devicetree/bindings/arm/actions.yaml +++ b/Documentation/devicetree/bindings/arm/actions.yaml @@ -38,3 +38,5 @@ properties: - enum: - ucrobotics,bubblegum-96 # uCRobotics Bubblegum-96 - const: actions,s9
[PATCH 2/4] dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties'
In cases where we don't reference another schema, 'additionalProperties' can be used instead. This is preferred for now as 'unevaluatedProperties' support isn't implemented yet. In a few cases, this means adding some missing property definitions of which most are for SPI bus properties. 'unevaluatedProperties' is not going to work for the SPI bus properties anyways as they are evaluated from the parent node, not the SPI child node. Signed-off-by: Rob Herring --- .../devicetree/bindings/clock/baikal,bt1-ccu-div.yaml | 6 +- .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml | 2 +- .../devicetree/bindings/clock/imx8m-clock.yaml | 2 +- .../devicetree/bindings/hwmon/baikal,bt1-pvt.yaml | 4 ++-- .../devicetree/bindings/iio/accel/adi,adis16240.yaml | 4 +++- .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 4 +++- .../devicetree/bindings/iio/accel/adi,adxl372.yaml | 4 +++- .../devicetree/bindings/iio/adc/adi,ad7124.yaml| 4 +++- .../devicetree/bindings/iio/adc/adi,ad7192.yaml| 4 +++- .../devicetree/bindings/iio/adc/adi,ad7292.yaml| 4 +++- .../devicetree/bindings/iio/adc/adi,ad7606.yaml| 6 +- .../devicetree/bindings/iio/adc/adi,ad7923.yaml| 4 +++- .../devicetree/bindings/iio/adc/maxim,max1241.yaml | 4 +++- .../devicetree/bindings/iio/dac/adi,ad5770r.yaml | 10 +- .../devicetree/bindings/iio/frequency/adf4371.yaml | 4 +++- .../devicetree/bindings/iio/imu/adi,adis16460.yaml | 4 +++- .../devicetree/bindings/iio/imu/adi,adis16475.yaml | 2 +- .../devicetree/bindings/iio/imu/bosch,bmi160.yaml | 4 +++- .../devicetree/bindings/iio/imu/nxp,fxos8700.yaml | 4 +++- .../bindings/interrupt-controller/mti,gic.yaml | 2 +- .../devicetree/bindings/mfd/cirrus,lochnagar.yaml | 10 +- .../bindings/mfd/ti,j721e-system-controller.yaml | 5 - .../devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 4 +++- .../opp/allwinner,sun50i-h6-operating-points.yaml | 4 +++- .../bindings/regulator/qcom-labibb-regulator.yaml | 2 +- .../devicetree/bindings/timer/snps,dw-apb-timer.yaml | 2 +- 26 files changed, 82 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml index 2821425ee445..bd4cefbb1244 100644 --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml @@ -134,7 +134,11 @@ properties: "#reset-cells": const: 1 -unevaluatedProperties: false + clocks: true + + clock-names: true + +additionalProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml index 97131bfa6f87..624984d51c10 100644 --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml @@ -101,7 +101,7 @@ properties: clock-names: const: ref_clk -unevaluatedProperties: false +additionalProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml index 31e7cc9693c3..625f573a7b90 100644 --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml @@ -96,7 +96,7 @@ allOf: - const: clk_ext3 - const: clk_ext4 -unevaluatedProperties: false +additionalProperties: false examples: # Clock Control Module node: diff --git a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml index 84ae4cdd08ed..00a6511354e6 100644 --- a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml +++ b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml @@ -79,7 +79,7 @@ properties: minimum: 0 maximum: 7130 -unevaluatedProperties: false +additionalProperties: false required: - compatible @@ -99,7 +99,7 @@ examples: interrupts = ; - baikal,pvt-temp-trim-millicelsius = <1000>; + baikal,pvt-temp-offset-millicelsius = <1000>; clocks = <&ccu_sys>, <&ccu_sys>; clock-names = "ref", "pclk"; diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml index 8589b722028d..4fcbfd93e218 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml @@ -25,12 +25,14 @@ properties: interrupts: maxItems: 1 + spi-max-frequency: true + required: - compatible - reg - interrupts -unevaluatedProperties: false +additionalProperties: false examples: - | diff --git
[PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
This doesn't yet do anything in the tools, but make it explicit so we can check either 'unevaluatedProperties' or 'additionalProperties' is present in schemas. 'unevaluatedProperties' is appropriate when including another schema (via '$ref') and all possible properties and/or child nodes are not explicitly listed in the schema with the '$ref'. This is in preparation to add a meta-schema to check for missing 'unevaluatedProperties' or 'additionalProperties'. This has been a constant source of review issues. Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/coresight-cti.yaml | 2 ++ Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml| 2 ++ Documentation/devicetree/bindings/ata/faraday,ftide010.yaml | 2 ++ Documentation/devicetree/bindings/bus/renesas,bsc.yaml | 2 ++ .../devicetree/bindings/display/panel/tpo,tpg110.yaml| 2 ++ Documentation/devicetree/bindings/dma/ingenic,dma.yaml | 2 ++ Documentation/devicetree/bindings/dma/st,stm32-dma.yaml | 2 ++ Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml | 2 ++ Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml | 2 ++ Documentation/devicetree/bindings/dma/ti/k3-udma.yaml| 2 ++ .../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 2 ++ Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml| 2 ++ Documentation/devicetree/bindings/i2c/i2c-gpio.yaml | 2 ++ Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml | 2 ++ .../devicetree/bindings/i2c/socionext,uniphier-fi2c.yaml | 2 ++ .../devicetree/bindings/i2c/socionext,uniphier-i2c.yaml | 2 ++ Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 2 ++ .../devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml | 2 ++ .../devicetree/bindings/iio/accel/adi,adis16240.yaml | 2 ++ Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml | 2 ++ Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml | 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml| 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml| 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7292.yaml| 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7606.yaml| 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml| 2 ++ Documentation/devicetree/bindings/iio/adc/maxim,max1241.yaml | 2 ++ Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml | 2 ++ Documentation/devicetree/bindings/iio/frequency/adf4371.yaml | 2 ++ Documentation/devicetree/bindings/iio/imu/adi,adis16460.yaml | 2 ++ Documentation/devicetree/bindings/iio/imu/adi,adis16475.yaml | 2 ++ Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml | 2 ++ Documentation/devicetree/bindings/iio/imu/nxp,fxos8700.yaml | 2 ++ .../devicetree/bindings/input/fsl,mpr121-touchkey.yaml | 2 ++ .../bindings/interrupt-controller/loongson,htpic.yaml| 2 ++ .../bindings/interrupt-controller/loongson,liointc.yaml | 2 ++ .../bindings/memory-controllers/renesas,rpc-if.yaml | 2 ++ .../devicetree/bindings/mmc/amlogic,meson-mx-sdhc.yaml | 2 ++ Documentation/devicetree/bindings/mmc/cdns,sdhci.yaml| 2 ++ Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml | 2 ++ Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 2 ++ Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml | 2 ++ Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml | 2 ++ .../devicetree/bindings/mmc/socionext,uniphier-sd.yaml | 2 ++ Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml | 2 ++ Documentation/devicetree/bindings/mtd/denali,nand.yaml | 2 ++ Documentation/devicetree/bindings/mtd/ingenic,nand.yaml | 2 ++ .../devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml | 2 ++ Documentation/devicetree/bindings/net/adi,adin.yaml | 2 ++ .../devicetree/bindings/net/amlogic,meson-dwmac.yaml | 2 ++ .../devicetree/bindings/net/aspeed,ast2600-mdio.yaml | 2 ++ Documentation/devicetree/bindings/net/marvell,mvusb.yaml | 2 ++ .../devicetree/bindings/net/mediatek,star-emac.yaml | 2 ++ Documentation/devicetree/bindings/net/nxp,tja11xx.yaml | 2 ++ Documentation/devicetree/bindings/net/qca,ar71xx.yaml| 2 ++ Documentation/devicetree/bindings/net/qca,ar803x.yaml| 2 ++ Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml | 2 ++ Documentation/devicetree/bindings/net/qcom,ipq8064-mdio.yaml | 2 ++ Documentation/devicetree/bindings/net/renesas,ether.yaml | 2 ++ Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 2 ++ Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml | 2 ++ Documentation/devicetree/bindings/net/ti,dp83867.yaml| 2 ++ Documentation/devicetree/bindings/net/ti,dp83869.yaml| 2 ++ Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 2 ++ Documentation/devicetree/bindings/n
[PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
In order to add meta-schema checks for additional/unevaluatedProperties being present, all schema need to make this explicit. As common/shared schema are included by other schemas, they should always allow for additionalProperties. Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/arm/cpus.yaml | 2 ++ .../devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml | 2 ++ Documentation/devicetree/bindings/ata/pata-common.yaml | 2 ++ Documentation/devicetree/bindings/ata/sata-common.yaml | 2 ++ Documentation/devicetree/bindings/bus/simple-pm-bus.yaml | 2 ++ .../devicetree/bindings/chrome/google,cros-ec-typec.yaml | 2 ++ .../devicetree/bindings/connector/usb-connector.yaml | 2 ++ .../devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml | 2 ++ .../devicetree/bindings/display/dsi-controller.yaml | 2 ++ Documentation/devicetree/bindings/display/panel/lvds.yaml| 2 ++ .../devicetree/bindings/display/panel/panel-common.yaml | 2 ++ Documentation/devicetree/bindings/dma/dma-common.yaml| 2 ++ Documentation/devicetree/bindings/dma/dma-controller.yaml| 2 ++ Documentation/devicetree/bindings/dma/dma-router.yaml| 2 ++ Documentation/devicetree/bindings/extcon/wlf,arizona.yaml| 2 ++ .../devicetree/bindings/iio/adc/samsung,exynos-adc.yaml | 5 - Documentation/devicetree/bindings/iio/common.yaml| 2 ++ Documentation/devicetree/bindings/input/input.yaml | 2 ++ Documentation/devicetree/bindings/input/matrix-keymap.yaml | 2 ++ .../devicetree/bindings/input/touchscreen/touchscreen.yaml | 2 ++ Documentation/devicetree/bindings/leds/common.yaml | 2 ++ .../devicetree/bindings/leds/leds-class-multicolor.yaml | 3 +++ Documentation/devicetree/bindings/leds/trigger-source.yaml | 2 ++ Documentation/devicetree/bindings/media/rc.yaml | 2 ++ Documentation/devicetree/bindings/mfd/syscon.yaml| 2 +- Documentation/devicetree/bindings/mmc/mmc-controller.yaml| 2 ++ .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml | 2 ++ Documentation/devicetree/bindings/mtd/nand-controller.yaml | 2 ++ .../devicetree/bindings/net/can/can-transceiver.yaml | 2 ++ Documentation/devicetree/bindings/net/dsa/dsa.yaml | 2 ++ .../devicetree/bindings/net/ethernet-controller.yaml | 2 ++ Documentation/devicetree/bindings/net/ethernet-phy.yaml | 2 ++ Documentation/devicetree/bindings/net/mdio.yaml | 2 ++ Documentation/devicetree/bindings/net/snps,dwmac.yaml| 2 ++ Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml | 2 ++ Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 ++ Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml | 2 ++ Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml| 2 ++ Documentation/devicetree/bindings/pci/cdns-pcie.yaml | 2 ++ Documentation/devicetree/bindings/pci/pci-ep.yaml| 2 ++ Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml | 2 ++ Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml | 2 ++ Documentation/devicetree/bindings/pinctrl/pinmux-node.yaml | 2 ++ Documentation/devicetree/bindings/power/power-domain.yaml| 2 ++ .../devicetree/bindings/power/supply/power-supply.yaml | 2 ++ Documentation/devicetree/bindings/pwm/pwm.yaml | 2 ++ Documentation/devicetree/bindings/regulator/regulator.yaml | 2 ++ Documentation/devicetree/bindings/regulator/wlf,arizona.yaml | 2 ++ Documentation/devicetree/bindings/riscv/cpus.yaml| 2 ++ Documentation/devicetree/bindings/rtc/rtc.yaml | 2 ++ Documentation/devicetree/bindings/serial/rs485.yaml | 3 +++ Documentation/devicetree/bindings/serial/serial.yaml | 2 ++ Documentation/devicetree/bindings/soc/imx/fsl,aips-bus.yaml | 2 ++ Documentation/devicetree/bindings/sound/amlogic,aiu.yaml | 2 ++ Documentation/devicetree/bindings/sound/cirrus,madera.yaml | 2 ++ .../devicetree/bindings/sound/nvidia,tegra210-ahub.yaml | 3 +++ Documentation/devicetree/bindings/sound/wlf,arizona.yaml | 2 ++ .../devicetree/bindings/soundwire/soundwire-controller.yaml | 2 ++ Documentation/devicetree/bindings/spi/spi-controller.yaml| 2 ++ Documentation/devicetree/bindings/spmi/spmi.yaml | 2 ++ .../devicetree/bindings/thermal/thermal-cooling-devices.yaml | 2 ++ .../devicetree/bindings/thermal/thermal-sensor.yaml | 2 ++ Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 2 ++ Documentation/devicetree/bindings/usb/usb-hcd.yaml | 2 ++ Documentation/devicetree/bindings/watchdog/watchdog.yaml | 2 ++ 65 files changed, 134 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 1222bf1831fa..14cd727d3c4b 100644 --- a/Documentation/devicetree/bindin
RE: [PATCH 8/8] drm/ttm: nuke caching placement flags
>-Original Message- >From: dri-devel On Behalf Of >Christian König >Sent: Thursday, October 1, 2020 7:28 AM >To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com; >airl...@gmail.com; dan...@ffwll.ch >Subject: [PATCH 8/8] drm/ttm: nuke caching placement flags > >Changing the caching on the fly never really worked >flawlessly. > >So stop this completely and just let drivers specific the >desired caching in the tt or bus object. > >Signed-off-by: Christian König >--- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 ++ > drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--- > drivers/gpu/drm/nouveau/nouveau_bo.c | 36 + > drivers/gpu/drm/qxl/qxl_object.c | 10 ++--- > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_object.c | 46 +- > drivers/gpu/drm/radeon/radeon_ttm.c| 18 ++--- > drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +- > drivers/gpu/drm/ttm/ttm_bo.c | 44 ++--- > drivers/gpu/drm/ttm/ttm_bo_util.c | 10 ++--- > drivers/gpu/drm/ttm/ttm_tt.c | 29 -- > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 30 +++--- > include/drm/ttm/ttm_placement.h| 14 --- > include/drm/ttm/ttm_tt.h | 15 --- > 15 files changed, 61 insertions(+), 234 deletions(-) > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >index 80bc7177cd45..964f9512dd6e 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >@@ -137,7 +137,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_VRAM; >- places[c].flags = TTM_PL_FLAG_WC | >TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > > if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) > places[c].lpfn = visible_pfn; >@@ -154,11 +154,6 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_TT; > places[c].flags = 0; >- if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) >- places[c].flags |= TTM_PL_FLAG_WC | >- TTM_PL_FLAG_UNCACHED; >- else >- places[c].flags |= TTM_PL_FLAG_CACHED; > c++; > } > >@@ -167,11 +162,6 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_SYSTEM; > places[c].flags = 0; >- if (flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC) >- places[c].flags |= TTM_PL_FLAG_WC | >- TTM_PL_FLAG_UNCACHED; >- else >- places[c].flags |= TTM_PL_FLAG_CACHED; > c++; > } > >@@ -179,7 +169,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_GDS; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -187,7 +177,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_GWS; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -195,7 +185,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = AMDGPU_PL_OA; >- places[c].flags = TTM_PL_FLAG_UNCACHED; >+ places[c].flags = 0; > c++; > } > >@@ -203,7 +193,7 @@ void amdgpu_bo_placement_from_domain(struct >amdgpu_bo *abo, u32 domain) > places[c].fpfn = 0; > places[c].lpfn = 0; > places[c].mem_type = TTM_PL_SYSTEM; >- places[c].flags = TTM_PL_MASK_CACHING; >+ places[c].flags = 0; > c++; > } > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >index 5b56a66063fd..8cdec58b9106 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >@@ -92,7 +92,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object >*bo, > .fpfn = 0, > .lpfn = 0, > .mem_type = TTM_PL_SYSTEM, >- .flags = TTM_PL_MASK_CACHING >+
[PATCH v4 0/2] drm/i915/jsl: Update JSL Voltage swing table
Patch series covers following thigns: 1. Split and differentiate between EHL and JSL platfrom 2. Update voltage swing table for eDP on JSL platform Changes since V3 : - Changed IS_EHL_JSL to IS_JSL_EHL - Renamed IS_EHL_REVID to IS_JSL_EHL_REVID - Reverted removal of IS_ELKHARTLAKE and also added IS_JASPERLAKE - Corrected mistake of using IS_ELKHARTLAKE twice and missing IS_JASPERLAKE in intel_ddi Changes since V2 : - Added IS_EHL_JSL to replace IS_ELKHARTLAKE - EHL/JSL PCI ids split added - Rebased to drm master commit Changes since V1 : - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively - Reverted EHL/JSL PCI ids split change Tejas Upadhyay (2): drm/i915/jsl: Split EHL/JSL platform info and PCI ids drm/i915/edp/jsl: Update vswing table for HBR and HBR2 drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 4 +- .../gpu/drm/i915/display/intel_combo_phy.c| 6 +- drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++- drivers/gpu/drm/i915/display/intel_display.c | 8 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 9 +- drivers/gpu/drm/i915/i915_pci.c | 9 ++ drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_pch.c | 2 +- include/drm/i915_pciids.h | 9 +- 15 files changed, 135 insertions(+), 35 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 9 ++---
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 2 +-
include/drm/i915_pciids.h | 9 ++---
14 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index fe946a2e2082..f7c3731f5a4b 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..c6e87569b3d6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_JSL_EHL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 157d8c8c605a..d59ceaa2916a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_JSL_EHL(i915) ||
IS_ROCKETLAKE(i915))
return phy < PHY_C;
@@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (ehl_vbt_ddi_d_present(dev_priv))
expected_val = ICL_PHY_MISC_MUX_DDID;
@@
[PATCH v4 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EH
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
- Corrected mistake of using IS_ELKHARTLAKE twice and
missing IS_JASPERLAKE
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
- Changes rebased as per new drm top commit
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++--
1 file changed, 88 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b4c520348b3b..7589508ff7e2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans jsl_combo_phy_ddi_translations_edp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[] = {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1167,6 +1195,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
}
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (crtc_state->port_clock > 27) {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
+ return jsl_combo_phy_ddi_translations_edp_hbr;
+ }
+ }
+
+ return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans(struct intel_encoder *encoder,
+
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe wrote: > > On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote: > > > > kvm is some similar hack added for P2P DMA, see commit > > > add6a0cd1c5ba51b201e1361b05a5df817083618. It might be protected by > > > notifiers.. > > > > Yeah my thinking is that kvm (and I think also vfio, also seems to > > have mmu notifier nearby) are ok because of the mmu notiifer. Assuming > > that one works correctly. > > vfio doesn't have a notifier, Alex was looking to add a vfio private > scheme in the vma->private_data: > > https://lore.kernel.org/kvm/159017449210.18853.15037950701494323009.st...@gimli.home/ > > Guess it never happened. I was mislead by the mmu notifier in drivers/vfio/vfio.c. But looking closer, that's only used by some drivers, I guess to make sure their device pagetables are kept in sync with reality. And not to make sure the vfio pfn view is kept in sync with reality. This could get real nasty I think. > > > So, the answer really is that s390 and media need fixing, and this API > > > should go away (or become kvm specific) > > > > I'm still not clear how you want fo fix this, since your vma->dma_buf > > idea is kinda a decade long plan and so just not going to happen: > > Well, it doesn't mean we have to change every part of dma_buf to > participate in this. Just the bits media cares about. Or maybe it is > some higher level varient on top of dma_buf. > > Or don't use dma_buf for this, add a new object that just provides > refcounts and P2P DMA connection for IO pfn ranges.. So good news is, I dug some layers deeper in v4l, and there's only 2 users which do actually handle pfn and don't immediately convert to a pages array: - videbuf-dma-contig.c. Luckily videobuf 1 is deprecated since forever, so I think we might get away with either just breaking this, or at least tainting kernels and hiding it behind a nasty Kconfig. This only uses follow_pfn, which we need to keep anyway for vfio in the unsafe variant :-/ - videbuf2-vmalloc.c Digging through history this was added to support import of v4l buffers from drivers that needed contig memory. And way back before CMA, that meant carveout memory not backed by struct page *. That should now all have struct pages and be managed by CMA (since videbuf2-dma-contig.c just uses dma_alloc_coherent underneath), so I think we can just switch to pin_user_pages(FOLL_LONGTERM here too). iow I think I can outright delete the frame vector stuff. -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
[PATCH v4 1/2] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
Split the basic platform definition, macros, and PCI IDs to
differentiate between EHL and JSL platforms.
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EHL
- Renamed IS_EHL_REVID to IS_JSL_EHL_REVID
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
drivers/gpu/drm/i915/display/intel_display.c | 8
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h| 9 ++---
drivers/gpu/drm/i915/i915_pci.c| 9 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
drivers/gpu/drm/i915/intel_pch.c | 2 +-
include/drm/i915_pciids.h | 9 ++---
14 files changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index fe946a2e2082..f7c3731f5a4b 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
/* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
- if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
+ if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
tmp = intel_de_read(dev_priv,
ICL_PORT_PCS_DW1_AUX(phy));
tmp &= ~LATENCY_OPTIM_MASK;
@@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder,
}
}
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
for_each_dsi_phy(phy, intel_dsi->phys) {
tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..c6e87569b3d6 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
drm_i915_private *dev_priv)
*/
void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
{
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (dev_priv->cdclk.hw.ref == 24000)
dev_priv->max_cdclk_freq = 552000;
else
@@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
*dev_priv)
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
dev_priv->cdclk.table = icl_cdclk_table;
- } else if (IS_ELKHARTLAKE(dev_priv)) {
+ } else if (IS_JSL_EHL(dev_priv)) {
dev_priv->display.set_cdclk = bxt_set_cdclk;
dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 157d8c8c605a..d59ceaa2916a 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
enum phy phy)
* PHY-B and may not even have instances of the register for the
* other combo PHY's.
*/
- if (IS_ELKHARTLAKE(i915) ||
+ if (IS_JSL_EHL(i915) ||
IS_ROCKETLAKE(i915))
return phy < PHY_C;
@@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct
drm_i915_private *dev_priv,
ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
IREFGEN, IREFGEN);
- if (IS_ELKHARTLAKE(dev_priv)) {
+ if (IS_JSL_EHL(dev_priv)) {
if (ehl_vbt_ddi_d_present(dev_priv))
expected_val = ICL_PHY_MISC_MUX_DDID;
@@
[PATCH v4 0/2] drm/i915/jsl: Update JSL Voltage swing table
Patch series covers following thigns: 1. Split and differentiate between EHL and JSL platfrom 2. Update voltage swing table for eDP on JSL platform Changes since V3 : - Changed IS_EHL_JSL to IS_JSL_EHL - Renamed IS_EHL_REVID to IS_JSL_EHL_REVID - Reverted removal of IS_ELKHARTLAKE and also added IS_JASPERLAKE - Corrected mistake of using IS_ELKHARTLAKE twice and missing IS_JASPERLAKE in intel_ddi Changes since V2 : - Added IS_EHL_JSL to replace IS_ELKHARTLAKE - EHL/JSL PCI ids split added - Rebased to drm master commit Changes since V1 : - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively - Reverted EHL/JSL PCI ids split change Tejas Upadhyay (2): drm/i915/jsl: Split EHL/JSL platform info and PCI ids drm/i915/edp/jsl: Update vswing table for HBR and HBR2 drivers/gpu/drm/i915/display/icl_dsi.c| 4 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 4 +- .../gpu/drm/i915/display/intel_combo_phy.c| 6 +- drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++- drivers/gpu/drm/i915/display/intel_display.c | 8 +- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 9 +- drivers/gpu/drm/i915/i915_pci.c | 9 ++ drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_pch.c | 2 +- include/drm/i915_pciids.h | 9 +- 15 files changed, 135 insertions(+), 35 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
JSL has update in vswing table for eDP.
BSpec: 21257
Changes since V3 :
- Changed IS_EHL_JSL to IS_JSL_EH
- Reverted removal of IS_ELKHARTLAKE and also
added IS_JASPERLAKE
- Corrected mistake of using IS_ELKHARTLAKE twice and
missing IS_JASPERLAKE
Changes since V2 :
- Added IS_EHL_JSL to replace IS_ELKHARTLAKE
- EHL/JSL PCI ids split added
- Changes rebased as per new drm top commit
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/intel_ddi.c | 93 ++--
1 file changed, 88 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index b4c520348b3b..7589508ff7e2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans jsl_combo_phy_ddi_translations_edp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[] = {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1167,6 +1195,57 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
}
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (crtc_state->port_clock > 27) {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
+ return jsl_combo_phy_ddi_translations_edp_hbr;
+ }
+ }
+
+ return jsl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans(struct intel_encoder *encoder,
+
RE: [PATCH 4/8] drm/ttm: rename TTM caching enum
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 4/8] drm/ttm: rename TTM caching enum
>
>Cleanup the enum name and its values and give it a separate header file.
This clean up looks straight forward.
I am not really clear on why you are giving it a separate header. If you could
detail that a little more in the commit?
Otherwise:
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 +-
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 +++---
> drivers/gpu/drm/ttm/ttm_tt.c | 17 ++--
> include/drm/ttm/ttm_caching.h| 34
> include/drm/ttm/ttm_tt.h | 9 ++-
> 8 files changed, 70 insertions(+), 42 deletions(-)
> create mode 100644 include/drm/ttm/ttm_caching.h
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>index 213ef090bb0e..3c5ad69eff19 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
>@@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct
>ttm_buffer_object *bo)
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
> struct ttm_dma_tt *ttm;
>
>- if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
>+ if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> return AMDGPU_BO_INVALID_OFFSET;
>
> ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 399961035ae6..2af24cf39e94 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -1525,7 +1525,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt
>*ttm, struct ttm_resource *mem)
> if (mem && mem->mem_type == TTM_PL_TT) {
> flags |= AMDGPU_PTE_SYSTEM;
>
>- if (ttm->caching_state == tt_cached)
>+ if (ttm->caching == ttm_cached)
> flags |= AMDGPU_PTE_SNOOPED;
> }
>
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>b/drivers/gpu/drm/radeon/radeon_ttm.c
>index 63e38b05a5bc..f01e74113f40 100644
>--- a/drivers/gpu/drm/radeon/radeon_ttm.c
>+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>@@ -546,7 +546,7 @@ static int radeon_ttm_backend_bind(struct
>ttm_bo_device *bdev,
> WARN(1, "nothing to bind %lu pages for mreg %p back
>%p!\n",
>ttm->num_pages, bo_mem, ttm);
> }
>- if (ttm->caching_state == tt_cached)
>+ if (ttm->caching == ttm_cached)
> flags |= RADEON_GART_PAGE_SNOOP;
> r = radeon_gart_bind(rdev, gtt->offset, ttm->num_pages,
>ttm->pages, gtt->ttm.dma_address, flags);
>diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>index 111031cbb6df..c8f6790962b9 100644
>--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
>+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
>@@ -220,14 +220,14 @@ static struct ttm_pool_manager *_manager;
> /**
> * Select the right pool or requested caching state and ttm flags. */
> static struct ttm_page_pool *ttm_get_pool(int flags, bool huge,
>-enum ttm_caching_state cstate)
>+enum ttm_caching cstate)
> {
> int pool_index;
>
>- if (cstate == tt_cached)
>+ if (cstate == ttm_cached)
> return NULL;
>
>- if (cstate == tt_wc)
>+ if (cstate == ttm_write_combined)
> pool_index = 0x0;
> else
> pool_index = 0x1;
>@@ -441,17 +441,17 @@ static void ttm_pool_mm_shrink_fini(struct
>ttm_pool_manager *manager)
> }
>
> static int ttm_set_pages_caching(struct page **pages,
>- enum ttm_caching_state cstate, unsigned cpages)
>+ enum ttm_caching cstate, unsigned cpages)
> {
> int r = 0;
> /* Set page caching */
> switch (cstate) {
>- case tt_uncached:
>+ case ttm_uncached:
> r = ttm_set_pages_array_uc(pages, cpages);
> if (r)
> pr_err("Failed to set %d pages to uc!\n", cpages);
> break;
>- case tt_wc:
>+ case ttm_write_combined:
> r = ttm_set_pages_array_wc(pages, cpages);
> if (r)
> pr_err("Failed to set %d pages to wc!\n", cpages);
>@@ -486,7 +486,7 @@ static void ttm_handle_caching_failure(struct page
>**failed_pages,
> * pages returned in pages array.
> */
> static int ttm_alloc_new_pages(struct list_head *pages, gfp_t gfp_flags,
>-
Re: [PATCH] drm/amdgpu: remove unintended executable mode
On Mon, Oct 5, 2020 at 3:22 AM Lukas Bulwahn wrote:
>
> Besides the intended change, commit 3437f5f6c979 ("drm/amdgpu: add gfx
> support for van gogh (v2)") also set the source files gfx_v10_0.c to be
> executable, i.e., changed from old mode 644 to new mode 755.
>
> Set to the usual mode for source and headers files. No functional change.
>
> Signed-off-by: Lukas Bulwahn
Luben already sent out a similar patch. Fixed up and will be pushed out soon.
Alex
> ---
> applies cleanly on next-20201002
>
> Alex, please pick this minor non-urgent cleanup patch on your -next tree.
>
> Huang Rui, please ack. You might want to check your development environment
> introducing those executable modes on files.
>
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 0
> 1 file changed, 0 insertions(+), 0 deletions(-)
> mode change 100755 => 100644 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> old mode 100755
> new mode 100644
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 5/8] drm/ttm: set the tt caching state at creation time
>-Original Message-
>From: dri-devel On Behalf Of
>Christian König
>Sent: Thursday, October 1, 2020 7:28 AM
>To: dri-devel@lists.freedesktop.org; ray.hu...@amd.com;
>airl...@gmail.com; dan...@ffwll.ch
>Subject: [PATCH 5/8] drm/ttm: set the tt caching state at creation time
>
>All drivers can determine the tt caching state at creation time,
>no need to do this on the fly during every validation.
Reviewed-by: Michael J. Ruhl
m
>Signed-off-by: Christian König
>---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 9 -
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 14 +-
> drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
> drivers/gpu/drm/ttm/ttm_tt.c | 16 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
> include/drm/ttm/ttm_tt.h | 7 ---
> 9 files changed, 53 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>index 2af24cf39e94..7f41a47e7353 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>@@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
>ttm_bo_device *bdev,
> static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
> uint32_t page_flags)
> {
>+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
> struct amdgpu_ttm_tt *gtt;
>+ enum ttm_caching caching;
>
> gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
> if (gtt == NULL) {
>@@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
>ttm_buffer_object *bo,
> }
> gtt->gobj = &bo->base;
>
>+ if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
>+ caching = ttm_write_combined;
>+ else
>+ caching = ttm_cached;
>+
> /* allocate space for the uninitialized page entries */
>- if (ttm_sg_tt_init(>t->ttm, bo, page_flags)) {
>+ if (ttm_sg_tt_init(>t->ttm, bo, page_flags, caching)) {
> kfree(gtt);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>b/drivers/gpu/drm/drm_gem_vram_helper.c
>index 3fe4b326e18e..62235926e077 100644
>--- a/drivers/gpu/drm/drm_gem_vram_helper.c
>+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>@@ -910,7 +910,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
>ttm_buffer_object *bo,
> if (!tt)
> return NULL;
>
>- ret = ttm_tt_init(tt, bo, page_flags);
>+ ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
> if (ret < 0)
> goto err_ttm_tt_init;
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>index 806d9ec310f5..cd6fdebae795 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
>@@ -5,6 +5,7 @@
> #include "nouveau_drv.h"
> #include "nouveau_mem.h"
> #include "nouveau_ttm.h"
>+#include "nouveau_bo.h"
>
> struct nouveau_sgdma_be {
> /* this has to be the first field so populate/unpopulated in
>@@ -67,13 +68,23 @@ nouveau_sgdma_unbind(struct ttm_bo_device
>*bdev, struct ttm_tt *ttm)
> struct ttm_tt *
> nouveau_sgdma_create_ttm(struct ttm_buffer_object *bo, uint32_t
>page_flags)
> {
>+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
>+ struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_sgdma_be *nvbe;
>+ enum ttm_caching caching;
>+
>+ if (nvbo->force_coherent)
>+ caching = ttm_uncached;
>+ else if (drm->agp.bridge)
>+ caching = ttm_write_combined;
>+ else
>+ caching = ttm_cached;
>
> nvbe = kzalloc(sizeof(*nvbe), GFP_KERNEL);
> if (!nvbe)
> return NULL;
>
>- if (ttm_dma_tt_init(&nvbe->ttm, bo, page_flags)) {
>+ if (ttm_dma_tt_init(&nvbe->ttm, bo, page_flags, caching)) {
> kfree(nvbe);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
>index 2c35ca4270c6..dcf4ac1480c7 100644
>--- a/drivers/gpu/drm/qxl/qxl_ttm.c
>+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
>@@ -146,7 +146,7 @@ static struct ttm_tt *qxl_ttm_tt_create(struct
>ttm_buffer_object *bo,
> if (gtt == NULL)
> return NULL;
> gtt->qdev = qdev;
>- if (ttm_tt_init(>t->ttm, bo, page_flags)) {
>+ if (ttm_tt_init(>t->ttm, bo, page_flags, ttm_cached)) {
> kfree(gtt);
> return NULL;
> }
>diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
>b/drivers/gpu/drm/radeon/radeon_ttm.c
>index f01e74113f40..130a7cea35c3 100644
>--- a/drivers/gpu/drm/radeon/radeon_ttm.c
>+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
>@@ -590,6 +590,10 @@ static struct ttm_tt *radeon_ttm_tt_create(struc
RE: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message- > From: Christian König > Sent: Monday, October 05, 2020 3:55 AM > To: Xiong, Jianxin ; linux-r...@vger.kernel.org; > dri-devel@lists.freedesktop.org > Cc: Doug Ledford ; Jason Gunthorpe ; Leon > Romanovsky ; Sumit Semwal > ; Vetter, Daniel > Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user > memory region > > Hi Jianxin, > > Am 04.10.20 um 21:12 schrieb Jianxin Xiong: > > Dma-buf is a standard cross-driver buffer sharing mechanism that can > > be used to support peer-to-peer access from RDMA devices. > > > > Device memory exported via dma-buf is associated with a file descriptor. > > This is passed to the user space as a property associated with the > > buffer allocation. When the buffer is registered as a memory region, > > the file descriptor is passed to the RDMA driver along with other > > parameters. > > > > Implement the common code for importing dma-buf object and mapping > > dma-buf pages. > > > > Signed-off-by: Jianxin Xiong > > Reviewed-by: Sean Hefty > > Acked-by: Michael J. Ruhl > > well first of all really nice work you have done here. > > Since I'm not an expert on RDMA or its drivers I can't really review any of > that part. > > But at least from the DMA-buf side it looks like you are using the interface > correctly as intended. > > So feel free to add an Acked-by: Christian König > if it helps. > > Thanks, > Christian. Thanks, will do. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote: > This doesn't yet do anything in the tools, but make it explicit so we can > check either 'unevaluatedProperties' or 'additionalProperties' is present > in schemas. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:28PM -0500, Rob Herring wrote: > In cases where we don't reference another schema, 'additionalProperties' > can be used instead. This is preferred for now as 'unevaluatedProperties' > support isn't implemented yet. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
On Mon, Oct 05, 2020 at 01:38:30PM -0500, Rob Herring wrote: > In order to add meta-schema checks for additional/unevaluatedProperties > being present, all schema need to make this explicit. As common/shared > schema are included by other schemas, they should always allow for > additionalProperties. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Jason Gunthorpe
> Sent: Monday, October 05, 2020 9:33 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [RFC PATCH v3 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Mon, Oct 05, 2020 at 04:18:11PM +, Xiong, Jianxin wrote:
>
> > > The implementation in mlx5 will be much more understandable, it
> > > would just do dma_buf_dynamic_attach() and program the XLT exactly the
> > > same as a normal umem.
> > >
> > > The move_notify() simply zap's the XLT and triggers a work to reload
> > > it after the move. Locking is provided by the dma_resv_lock. Only a small
> > > disruption to the page fault handler is needed.
> >
> > We considered such scheme but didn't go that way due to the lack of
> > notification when the move is done and thus the work wouldn't know
> > when it can reload.
>
> Well, the work would block on the reservation lock and that indicates the
> move is done
Got it. Will work on that.
>
> It would be nicer if the dma_buf could provide an op that things are ready to
> go though
>
> > Now I think it again, we could probably signal the reload in the page fault
> > handler.
>
> This also works, with a performance cost
>
> > > > + dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> > > > + sgt = dma_buf_map_attachment(umem_dmabuf->attach,
> > > > +DMA_BIDIRECTIONAL);
> > > > + dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> > >
> > > This doesn't look right, this lock has to be held up until the HW is
> > > programmed
> >
> > The mapping remains valid until being invalidated again. There is a
> > sequence number checking before programming the HW.
>
> It races, we could immediately trigger invalidation and then re-program the
> HW with this stale data.
>
> > > The use of atomic looks probably wrong as well.
> >
> > Do you mean umem_dmabuf->notifier_seq? Could you elaborate the concern?
>
> It only increments once per invalidation, that usually is racy.
I will rework these parts.
>
> > > > + total_pages = ib_umem_odp_num_pages(umem_odp);
> > > > + for_each_sg(umem->sg_head.sgl, sg, umem->sg_head.nents, j) {
> > > > + addr = sg_dma_address(sg);
> > > > + pages = sg_dma_len(sg) >> page_shift;
> > > > + while (pages > 0 && k < total_pages) {
> > > > + umem_odp->dma_list[k++] = addr | access_mask;
> > > > + umem_odp->npages++;
> > > > + addr += page_size;
> > > > + pages--;
> > >
> > > This isn't fragmenting the sg into a page list properly, won't work
> > > for unaligned things
> >
> > I thought the addresses are aligned, but will add explicit alignment here.
>
> I have no idea what comes out of dma_buf, I wouldn't make too many
> assumptions since it does have to pass through the IOMMU layer too
>
> > > And really we don't need the dma_list for this case, with a fixed
> > > whole mapping DMA SGL a normal umem sgl is OK and the normal umem
> > > XLT programming in mlx5 is fine.
> >
> > The dma_list is used by both "polulate_mtt()" and
> > "mlx5_ib_invalidate_range", which are used for XLT programming and
> > invalidating (zapping), respectively.
>
> Don't use those functions for the dma_buf flow.
Ok. I think we can use mlx5_ib_update_xlt() directly for dma-buf case.
>
> Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote: > This doesn't yet do anything in the tools, but make it explicit so we can > check either 'unevaluatedProperties' or 'additionalProperties' is present > in schemas. > > 'unevaluatedProperties' is appropriate when including another schema (via > '$ref') and all possible properties and/or child nodes are not > explicitly listed in the schema with the '$ref'. > > This is in preparation to add a meta-schema to check for missing > 'unevaluatedProperties' or 'additionalProperties'. This has been a > constant source of review issues. > > Signed-off-by: Rob Herring I trust you, so for I2C: Acked-by: Wolfram Sang signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote: > This doesn't yet do anything in the tools, but make it explicit so we can > check either 'unevaluatedProperties' or 'additionalProperties' is present > in schemas. > > 'unevaluatedProperties' is appropriate when including another schema (via > '$ref') and all possible properties and/or child nodes are not > explicitly listed in the schema with the '$ref'. > > This is in preparation to add a meta-schema to check for missing > 'unevaluatedProperties' or 'additionalProperties'. This has been a > constant source of review issues. > > Signed-off-by: Rob Herring Acked-by: Krzysztof Kozlowski Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:28PM -0500, Rob Herring wrote: > In cases where we don't reference another schema, 'additionalProperties' > can be used instead. This is preferred for now as 'unevaluatedProperties' > support isn't implemented yet. > > In a few cases, this means adding some missing property definitions of > which most are for SPI bus properties. 'unevaluatedProperties' is not going > to work for the SPI bus properties anyways as they are evaluated from the > parent node, not the SPI child node. > > Signed-off-by: Rob Herring Acked-by: Krzysztof Kozlowski Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
