Re: [PATCH 1/4] soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h
On 06/10/2020 21:33, Enric Balletbo i Serra wrote:
From: Yongqiang Niu
MMSYS is the driver which controls the routing of these DDP components,
so the definition of the mtk_ddp_comp_id enum should be placed in mtk-mmsys.h
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Enric Balletbo i Serra
---
This patch was previously part of another series, but has no
dependencies and can be applied independently. As the latest version
sent is from two months ago, I resent this patch because the next patches
of this series depends on it to apply cleanly.
Applied to v5.10-next/soc
Thanks
[1] https://patchwork.kernel.org/patch/11706243
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34 +
drivers/soc/mediatek/mtk-mmsys.c| 4 +--
include/linux/soc/mediatek/mtk-mmsys.h | 33
3 files changed, 35 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index debe36395fe7..161201fe5179 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,7 @@
#define MTK_DRM_DDP_COMP_H
#include
+#include
struct device;
struct device_node;
@@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
MTK_DDP_COMP_TYPE_MAX,
};
-enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL0,
- DDP_COMPONENT_AAL1,
- DDP_COMPONENT_BLS,
- DDP_COMPONENT_CCORR,
- DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_COLOR1,
- DDP_COMPONENT_DITHER,
- DDP_COMPONENT_DPI0,
- DDP_COMPONENT_DPI1,
- DDP_COMPONENT_DSI0,
- DDP_COMPONENT_DSI1,
- DDP_COMPONENT_DSI2,
- DDP_COMPONENT_DSI3,
- DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD0,
- DDP_COMPONENT_OD1,
- DDP_COMPONENT_OVL0,
- DDP_COMPONENT_OVL_2L0,
- DDP_COMPONENT_OVL_2L1,
- DDP_COMPONENT_OVL1,
- DDP_COMPONENT_PWM0,
- DDP_COMPONENT_PWM1,
- DDP_COMPONENT_PWM2,
- DDP_COMPONENT_RDMA0,
- DDP_COMPONENT_RDMA1,
- DDP_COMPONENT_RDMA2,
- DDP_COMPONENT_UFOE,
- DDP_COMPONENT_WDMA0,
- DDP_COMPONENT_WDMA1,
- DDP_COMPONENT_ID_MAX,
-};
-
struct mtk_ddp_comp;
struct cmdq_pkt;
struct mtk_ddp_comp_funcs {
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index a55f25511173..36ad66bb221b 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -5,13 +5,11 @@
*/
#include
+#include
#include
#include
#include
-#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
-#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
-
#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
#define DISP_REG_CONFIG_DISP_OD_MOUT_EN 0x048
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 7bab5d9a3d31..2228bf6133da 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,39 @@
enum mtk_ddp_comp_id;
struct device;
+enum mtk_ddp_comp_id {
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_BLS,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_DSI0,
+ DDP_COMPONENT_DSI1,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_DSI3,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_OVL_2L1,
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_PWM0,
+ DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_UFOE,
+ DDP_COMPONENT_WDMA0,
+ DDP_COMPONENT_WDMA1,
+ DDP_COMPONENT_ID_MAX,
+};
+
void mtk_mmsys_ddp_connect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 05/28] video: fbdev: aty: Fix W=1 warnings in atyfb_base
Hi Sam,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20201127]
[also build test ERROR on v5.10-rc5]
[cannot apply to tegra-drm/drm/tegra/for-next soc/for-next linus/master
drm/drm-next v5.10-rc5 v5.10-rc4 v5.10-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Sam-Ravnborg/drivers-video-W-1-warning-fixes/20201128-040131
base:6174f05255e65622ff3340257879a4c0f858b0df
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/5a1d55cc719a775ae6c8e96aab317cff47068071
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sam-Ravnborg/drivers-video-W-1-warning-fixes/20201128-040131
git checkout 5a1d55cc719a775ae6c8e96aab317cff47068071
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/timex.h:61,
from include/linux/time32.h:13,
from include/linux/time.h:60,
from include/linux/compat.h:10,
from drivers/video/fbdev/aty/atyfb_base.c:51:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
137 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:137:10: note: in expansion of macro
'virt_addr_valid'
137 | BUG_ON(!virt_addr_valid(buf));
| ^~~
drivers/video/fbdev/aty/atyfb_base.c: In function 'aty_init':
>> drivers/video/fbdev/aty/atyfb_base.c:2375:61: error: 'dac_type' undeclared
>> (first use in this function)
2375 |dac_subtype = (aty_ld_8(SCRATCH_REG1 + 1, par) & 0xF0) | dac_type;
| ^~~~
drivers/video/fbdev/aty/atyfb_base.c:2375:61: note: each undeclared
identifier is reported only once for each function it appears in
vim +/dac_type +2375 drivers/video/fbdev/aty/atyfb_base.c
1013d26663199f8 drivers/video/aty/atyfb_base.c Antonino A. Daplas
2005-11-07 2348
48c68c4f1b54244 drivers/video/aty/atyfb_base.c Greg Kroah-Hartman
2012-12-21 2349 static int aty_init(struct fb_info *info)
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2350 {
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2351struct atyfb_par *par = (struct atyfb_par *) info->par;
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2352const char *ramname = NULL, *xtal;
1013d26663199f8 drivers/video/aty/atyfb_base.c Antonino A. Daplas
2005-11-07 2353int gtb_memsize, has_var = 0;
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2354struct fb_var_screeninfo var;
89c69d2b8eb3ee2 drivers/video/aty/atyfb_base.c Ville Syrjala
2008-07-23 2355int ret;
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2356
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2357init_waitqueue_head(>vblank.wait);
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2358spin_lock_init(>int_lock);
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2359
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2360 #ifdef CONFIG_FB_ATY_GX
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2361if (!M64_HAS(INTEGRATED)) {
^1da177e4c3f415 drivers/video/aty/atyfb_base.c Linus Torvalds
2005-04-16 2362u32 stat0;
5a1d55cc719a775 drivers/video/fbdev/aty/atyfb_base.c Sam Ravnborg
2020-11-27
Re: [PATCH] drm/komeda: Handle NULL pointer access code path in error case
On Fri, Nov 27, 2020 at 11:00:54AM +, carsten.haitz...@foss.arm.com wrote: > From: Carsten Haitzler > > komeda_component_get_old_state() technically can return a NULL > pointer. komeda_compiz_set_input() even warns when this happens, but > then proceeeds to use that NULL pointer tocompare memory content there > agains the new sate to see if it changed. In this case, it's better to s/sate/state/ > assume that the input changed as there is no old state to compare > against and thus assume the changes happen anyway. > > Signed-off-by: Carsten Haitzler Acked-by: Liviu Dudau I can make the small fix when pulling the patch for merge into drm-misc-next-fixes. Best regards, Liviu > --- > drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c > index 8f32ae7c25d0..e8b1e15312d8 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c > @@ -707,7 +707,8 @@ komeda_compiz_set_input(struct komeda_compiz *compiz, > WARN_ON(!old_st); > > /* compare with old to check if this input has been changed */ > - if (memcmp(&(to_compiz_st(old_st)->cins[idx]), cin, sizeof(*cin))) > + if (!old_st || > + memcmp(&(to_compiz_st(old_st)->cins[idx]), cin, sizeof(*cin))) > c_st->changed_active_inputs |= BIT(idx); > > komeda_component_add_input(c_st, >input, idx); > -- > 2.29.2 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Remove useless variable assignment
On Fri, Nov 27, 2020 at 11:00:27AM +, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler
>
> ret is not actually read after this (only written in one case then
> returned), so this assign line is useless. This removes that assignment.
>
> Signed-off-by: Carsten Haitzler
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> index 1d767473ba8a..eea76f51f662 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> @@ -163,7 +163,6 @@ static int komeda_parse_dt(struct device *dev, struct
> komeda_dev *mdev)
> ret = of_reserved_mem_device_init(dev);
> if (ret && ret != -ENODEV)
> return ret;
> - ret = 0;
>
> for_each_available_child_of_node(np, child) {
> if (of_node_name_eq(child, "pipeline")) {
> --
> 2.29.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] soc / drm: mediatek: cmdq: Remove timeout handler in helper function
On 27/11/2020 15:42, Chun-Kuang Hu wrote:
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
Hi Chun-Kuang,
On 20/11/2020 00:46, Chun-Kuang Hu wrote:
Hi, Matthias:
I've provided the example for why of this patch. How do you think
about this patch?
Patch looks good to me. If you want to take it through your tree you can add my
Acked-by: Matthias Brugger
Beware that you might need a stable tag for it, so that I can merge it into my
soc branch, in case there are more changes to cmdq-helper.
I would like this patch to go into your tree because this patch mainly
modify cmdq helper. Even though this patch is one of the series
"Mediatek DRM driver detect CMDQ execution timeout by vblank IRQ" [1],
I would wait for this patch get into mainline then send the next
patch.
Applied to v5.10-next/soc
Thanks!
Regards,
Chun-Kuang.
Regards,
Matthias
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2020年11月2日 週一 上午8:04寫道：
For each client driver, its timeout handler need to dump hardware register
or its state machine information, and their way to detect timeout are
also different, so remove timeout handler in helper function and
let client driver implement its own timeout handler.
Signed-off-by: Chun-Kuang Hu
---
v1 is one patch in series "Mediatek DRM driver detect CMDQ execution
timeout by vblank IRQ", but according to Jassi's suggestion [1], send
each patch in different series.
[2] is an example that different client has different way to calculate
timeout. Some client driver care about each packet's execution time, but
some client driver care about the total execution time for all packets.
[1]
https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
[2]
https://patchwork.kernel.org/project/linux-mediatek/patch/20201022094152.17662-1-houlong@mediatek.com/
Changes in v2:
1. Rebase onto Linux 5.10-rc1
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 41 +
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
3 files changed, 3 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ac038572164d..4be5d1fccf2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -824,8 +824,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
mtk_crtc->cmdq_client =
cmdq_mbox_create(mtk_crtc->mmsys_dev,
-drm_crtc_index(_crtc->base),
-2000);
+drm_crtc_index(_crtc->base));
if (IS_ERR(mtk_crtc->cmdq_client)) {
dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, writing
register by CPU now\n",
drm_crtc_index(_crtc->base));
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 505651b0d715..280d3bd9f675 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -70,14 +70,7 @@ int cmdq_dev_get_client_reg(struct device *dev,
}
EXPORT_SYMBOL(cmdq_dev_get_client_reg);
-static void cmdq_client_timeout(struct timer_list *t)
-{
- struct cmdq_client *client = from_timer(client, t, timer);
-
- dev_err(client->client.dev, "cmdq timeout!\n");
-}
-
-struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32
timeout)
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
{
struct cmdq_client *client;
@@ -85,12 +78,6 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev, int
index, u32 timeout)
if (!client)
return (struct cmdq_client *)-ENOMEM;
- client->timeout_ms = timeout;
- if (timeout != CMDQ_NO_TIMEOUT) {
- spin_lock_init(>lock);
- timer_setup(>timer, cmdq_client_timeout, 0);
- }
- client->pkt_cnt = 0;
client->client.dev = dev;
client->client.tx_block = false;
client->client.knows_txdone = true;
@@ -112,11 +99,6 @@ EXPORT_SYMBOL(cmdq_mbox_create);
void cmdq_mbox_destroy(struct cmdq_client *client)
{
- if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
- spin_lock(>lock);
- del_timer_sync(>timer);
- spin_unlock(>lock);
- }
mbox_free_channel(client->chan);
kfree(client);
}
@@ -449,18 +431,6 @@ static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data
data)
struct cmdq_task_cb *cb = >cb;
struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
- if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
- unsigned long flags = 0;
-
- spin_lock_irqsave(>lock, flags);
- if (--client->pkt_cnt == 0)
-
Re: [PATCH v1 02/28] video: fbcon: Use pr_debug() in fbcon
Hi Joe.
On Fri, Nov 27, 2020 at 01:16:41PM -0800, Joe Perches wrote:
> On Fri, 2020-11-27 at 20:57 +0100, Sam Ravnborg wrote:
> > Replacing DPRINTK() statements with pr_debug fixes
> > W=1 warnings.
> > And moves to a more standard logging setup at the same time.
> []
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> []
> > @@ -1015,9 +1007,9 @@ static const char *fbcon_startup(void)
> > rows /= vc->vc_font.height;
> > vc_resize(vc, cols, rows);
> >
> >
> > - DPRINTK("mode: %s\n", info->fix.id);
> > - DPRINTK("visual: %d\n", info->fix.visual);
> > - DPRINTK("res:%dx%d-%d\n", info->var.xres,
> > + pr_debug("mode: %s\n", info->fix.id);
> > + pr_debug("visual: %d\n", info->fix.visual);
> > + pr_debug("res:%dx%d-%d\n", info->var.xres,
> > info->var.yres,
> > info->var.bits_per_pixel);
>
> It'd be nicer to reindent the subsequent lines too.
>
> > @@ -3299,7 +3291,7 @@ static void fbcon_exit(void)
> >
> >
> > if (info->queue.func)
> > pending = cancel_work_sync(>queue);
> > - DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
> > + pr_debug("fbcon: %s pending work\n", (pending ? "canceled" :
> > "no"));
>
> perhaps:
>
> pr_debug("fbcon: %s pending work\n", pending ? "canceled" :
> "no");
>
Good suggestions, I will update accordingly in v2 or when applying in
case someone acks/r-b's the patches.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
On 27/11/2020 17:37, Ivaylo Dimitrov wrote: > With 5.9.11 and the patch on top, n900 boots fine, albeit display remains > blank, could be related to > brightness, we're still investigating. Ok. A DSS regdump for a working version and the latest one would be good too. There's a omapdss debugfs dir, with dss, dispc and clk files which are of interest here. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 02/28] video: fbcon: Use pr_debug() in fbcon
On Fri, 2020-11-27 at 20:57 +0100, Sam Ravnborg wrote:
> Replacing DPRINTK() statements with pr_debug fixes
> W=1 warnings.
> And moves to a more standard logging setup at the same time.
[]
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
[]
> @@ -1015,9 +1007,9 @@ static const char *fbcon_startup(void)
> rows /= vc->vc_font.height;
> vc_resize(vc, cols, rows);
>
>
> - DPRINTK("mode: %s\n", info->fix.id);
> - DPRINTK("visual: %d\n", info->fix.visual);
> - DPRINTK("res:%dx%d-%d\n", info->var.xres,
> + pr_debug("mode: %s\n", info->fix.id);
> + pr_debug("visual: %d\n", info->fix.visual);
> + pr_debug("res:%dx%d-%d\n", info->var.xres,
> info->var.yres,
> info->var.bits_per_pixel);
It'd be nicer to reindent the subsequent lines too.
> @@ -3299,7 +3291,7 @@ static void fbcon_exit(void)
>
>
> if (info->queue.func)
> pending = cancel_work_sync(>queue);
> - DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
> + pr_debug("fbcon: %s pending work\n", (pending ? "canceled" :
> "no"));
perhaps:
pr_debug("fbcon: %s pending work\n", pending ? "canceled" :
"no");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v3 6/6] tests: Bug fix for get_access_flags()
The filter definition is wrong and causes get_access_flags() always returning empty list. As the result the MR tests using this function are effectively skipped (but report success). Signed-off-by: Jianxin Xiong --- tests/utils.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/utils.py b/tests/utils.py index d3d5c16..8bd0c16 100644 --- a/tests/utils.py +++ b/tests/utils.py @@ -56,8 +56,8 @@ def filter_illegal_access_flags(element): :param element: A list of access flags to check :return: True if this list is legal, else False """ -if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE: -if e.IBV_ACCESS_LOCAL_WRITE: +if e.IBV_ACCESS_REMOTE_ATOMIC in element or e.IBV_ACCESS_REMOTE_WRITE in element: +if not e.IBV_ACCESS_LOCAL_WRITE in element: return False return True -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v3 5/6] tests: Add tests for dma-buf based memory regions
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/test_mr.py | 239 ++-
tests/utils.py | 26 ++
2 files changed, 264 insertions(+), 1 deletion(-)
diff --git a/tests/test_mr.py b/tests/test_mr.py
index adc649c..52cf20a 100644
--- a/tests/test_mr.py
+++ b/tests/test_mr.py
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019 Mellanox Technologies, Inc. All rights reserved. See
COPYING file
+# Copyright (c) 2020 Intel Corporation. All rights reserved. See COPYING file
"""
Test module for pyverbs' mr module.
"""
@@ -9,9 +10,10 @@ import errno
from tests.base import PyverbsAPITestCase, RCResources, RDMATestCase
from pyverbs.pyverbs_error import PyverbsRDMAError, PyverbsError
-from pyverbs.mr import MR, MW, DMMR, MWBindInfo, MWBind
+from pyverbs.mr import MR, MW, DMMR, DmaBufMR, MWBindInfo, MWBind
from pyverbs.qp import QPCap, QPInitAttr, QPAttr, QP
from pyverbs.wr import SendWR
+from pyverbs.dmabuf import DmaBuf
import pyverbs.device as d
from pyverbs.pd import PD
import pyverbs.enums as e
@@ -366,3 +368,238 @@ class DMMRTest(PyverbsAPITestCase):
dm_mr = DMMR(pd, dm_mr_len, e.IBV_ACCESS_ZERO_BASED,
dm=dm, offset=dm_mr_offset)
dm_mr.close()
+
+
+def check_dmabuf_support():
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+try:
+DmaBuf(1)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.ENOENT:
+raise unittest.SkipTest('Device /dev/dri/renderD* is not present')
+if ex.error_code == errno.EACCES:
+raise unittest.SkipTest('Lack of permission to access
/dev/dri/renderD*')
+
+
+def check_dmabuf_mr_support(pd):
+"""
+Check if dma-buf MR registration is supported by the driver.
+Skip the test on failure
+"""
+try:
+DmaBufMR(pd, 1, 0)
+except PyverbsRDMAError as ex:
+if ex.error_code == errno.EOPNOTSUPP:
+raise unittest.SkipTest('Reg dma-buf MR is not supported')
+
+
+class DmaBufMRTest(PyverbsAPITestCase):
+"""
+Test various functionalities of the DmaBufMR class.
+"""
+def test_dmabuf_reg_mr(self):
+"""
+Test ibv_reg_dmabuf_mr()
+"""
+check_dmabuf_support()
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off) as mr:
+pass
+
+def test_dmabuf_dereg_mr(self):
+"""
+Test ibv_dereg_mr() with DmaBufMR
+"""
+check_dmabuf_support()
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off) as mr:
+mr.close()
+
+def test_dmabuf_dereg_mr_twice(self):
+"""
+Verify that explicit call to DmaBufMR's close() doesn't fail
+"""
+check_dmabuf_support()
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd)
+flags = u.get_dmabuf_access_flags(ctx)
+for f in flags:
+len = u.get_mr_length()
+for off in [0, len//2]:
+with DmaBufMR(pd, len, f, offset=off) as mr:
+# Pyverbs supports multiple destruction of objects,
+# we are not expecting an exception here.
+mr.close()
+mr.close()
+
+def test_dmabuf_reg_mr_bad_flags(self):
+"""
+Verify that illegal flags combination fails as expected
+"""
+check_dmabuf_support()
+for ctx, attr, attr_ex in self.devices:
+with PD(ctx) as pd:
+check_dmabuf_mr_support(pd)
+for i in range(5):
+flags = random.sample([e.IBV_ACCESS_REMOTE_WRITE,
+ e.IBV_ACCESS_REMOTE_ATOMIC],
+ random.randint(1, 2))
+mr_flags = 0
+for i in flags:
[PATCH rdma-core v3 4/6] pyverbs: Add dma-buf based MR support
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Add a method to buildlib for building modules with mixed Cython and C
source.
Signed-off-by: Jianxin Xiong
---
buildlib/pyverbs_functions.cmake | 52 +++
pyverbs/CMakeLists.txt | 7 +
pyverbs/dmabuf.pxd | 15 ++
pyverbs/dmabuf.pyx | 72 ++
pyverbs/dmabuf_alloc.c | 296 +++
pyverbs/dmabuf_alloc.h | 19 +++
pyverbs/libibverbs.pxd | 2 +
pyverbs/mr.pxd | 6 +
pyverbs/mr.pyx | 103 +-
9 files changed, 570 insertions(+), 2 deletions(-)
create mode 100644 pyverbs/dmabuf.pxd
create mode 100644 pyverbs/dmabuf.pyx
create mode 100644 pyverbs/dmabuf_alloc.c
create mode 100644 pyverbs/dmabuf_alloc.h
diff --git a/buildlib/pyverbs_functions.cmake b/buildlib/pyverbs_functions.cmake
index 953cec2..2f6788e 100644
--- a/buildlib/pyverbs_functions.cmake
+++ b/buildlib/pyverbs_functions.cmake
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2018, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved. See COPYING file
function(rdma_cython_module PY_MODULE LINKER_FLAGS)
foreach(PYX_FILE ${ARGN})
@@ -32,6 +33,57 @@ function(rdma_cython_module PY_MODULE LINKER_FLAGS)
endforeach()
endfunction()
+function(rdma_multifile_module PY_MODULE MODULE_NAME LINKER_FLAGS)
+ set(ALL_CFILES "")
+ foreach(SRC_FILE ${ARGN})
+get_filename_component(FILENAME ${SRC_FILE} NAME_WE)
+get_filename_component(DIR ${SRC_FILE} DIRECTORY)
+get_filename_component(EXT ${SRC_FILE} EXT)
+if (DIR)
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}/${DIR}")
+else()
+ set(SRC_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+endif()
+if (${EXT} STREQUAL ".pyx")
+ set(PYX "${SRC_PATH}/${FILENAME}.pyx")
+ set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+ include_directories(${PYTHON_INCLUDE_DIRS})
+ add_custom_command(
+OUTPUT "${CFILE}"
+MAIN_DEPENDENCY "${PYX}"
+COMMAND ${CYTHON_EXECUTABLE} "${PYX}" -o "${CFILE}"
+"-I${PYTHON_INCLUDE_DIRS}"
+COMMENT "Cythonizing ${PYX}"
+ )
+ set(ALL_CFILES "${ALL_CFILES};${CFILE}")
+elseif(${EXT} STREQUAL ".c")
+ set(CFILE_ORIG "${SRC_PATH}/${FILENAME}.c")
+ set(CFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.c")
+ if (NOT ${CFILE_ORIG} STREQUAL ${CFILE})
+rdma_create_symlink("${CFILE_ORIG}" "${CFILE}")
+ endif()
+ set(ALL_CFILES "${ALL_CFILES};${CFILE}")
+elseif(${EXT} STREQUAL ".h")
+ set(HFILE_ORIG "${SRC_PATH}/${FILENAME}.h")
+ set(HFILE "${CMAKE_CURRENT_BINARY_DIR}/${FILENAME}.h")
+ if (NOT ${HFILE_ORIG} STREQUAL ${HFILE})
+rdma_create_symlink("${HFILE_ORIG}" "${HFILE}")
+ endif()
+else()
+ continue()
+endif()
+ endforeach()
+ string(REGEX REPLACE "\\.so$" "" SONAME
"${MODULE_NAME}${CMAKE_PYTHON_SO_SUFFIX}")
+ add_library(${SONAME} SHARED ${ALL_CFILES})
+ set_target_properties(${SONAME} PROPERTIES
+COMPILE_FLAGS "${CMAKE_C_FLAGS} -fPIC -fno-strict-aliasing
-Wno-unused-function -Wno-redundant-decls -Wno-shadow -Wno-cast-function-type
-Wno-implicit-fallthrough -Wno-unknown-warning -Wno-unknown-warning-option
-Wno-deprecated-declarations ${NO_VAR_TRACKING_FLAGS}"
+LIBRARY_OUTPUT_DIRECTORY "${BUILD_PYTHON}/${PY_MODULE}"
+PREFIX "")
+ target_link_libraries(${SONAME} LINK_PRIVATE ${PYTHON_LIBRARIES} ibverbs
rdmacm ${LINKER_FLAGS})
+ install(TARGETS ${SONAME}
+DESTINATION ${CMAKE_INSTALL_PYTHON_ARCH_LIB}/${PY_MODULE})
+endfunction()
+
function(rdma_python_module PY_MODULE)
foreach(PY_FILE ${ARGN})
get_filename_component(LINK "${CMAKE_CURRENT_SOURCE_DIR}/${PY_FILE}"
ABSOLUTE)
diff --git a/pyverbs/CMakeLists.txt b/pyverbs/CMakeLists.txt
index 9542c4b..1b21e7b 100644
--- a/pyverbs/CMakeLists.txt
+++ b/pyverbs/CMakeLists.txt
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
# Copyright (c) 2019, Mellanox Technologies. All rights reserved. See COPYING
file
+# Copyright (c) 2020, Intel Corporation. All rights reserved. See COPYING file
rdma_cython_module(pyverbs ""
addr.pyx
@@ -24,6 +25,12 @@ rdma_python_module(pyverbs
utils.py
)
+rdma_multifile_module(pyverbs dmabuf ""
+ dmabuf.pyx
+ dmabuf_alloc.c
+ dmabuf_alloc.h
+ )
+
# mlx5 and efa providers are not built without coherent DMA, e.g. ARM32 build.
if (HAVE_COHERENT_DMA)
add_subdirectory(providers/mlx5)
diff --git a/pyverbs/dmabuf.pxd b/pyverbs/dmabuf.pxd
new file mode 100644
index 000..3ef5dfb
--- /dev/null
+++ b/pyverbs/dmabuf.pxd
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: (GPL-2.0 OR Linux-OpenIB)
+# Copyright (c) 2020, Intel Corporation. All rights
[PATCH rdma-core v3 0/6] Add user space dma-buf support
This is the third version of the patch series. Change log: v3: * Add parameter 'iova' to the new ibv_reg_dmabuf_mr() API * Change the way of allocating dma-buf object - use /dev/dri/renderD* instead of /dev/dri/card* and use GEM object instead of dumb buffer * Add cmake function to allow building modules with mixed cython and C source files * Add new tests that use dma-buf MRs for send/recv and rdma traffic * Skip dma-buf tests on unsupported systems * Remove some use of random values in the new tests * Add dealloc() and close() methods to the new classes * Replace string.format with f-string in python code * Fix some coding style issues: spacing, indentation, typo, comments v2: https://www.spinics.net/lists/linux-rdma/msg97936.html * Put the kernel header updates into a separate commit * Add comments for the data structure used in python ioctl calls * Fix issues related to symbol versioning * Fix styling issues: extra spaces, unncecessary variable, typo * Fix an inproper error code usage * Put the new op into ibv_context_ops instead if verbs_context v1: https://www.spinics.net/lists/linux-rdma/msg97865.html * Add user space API for registering dma-buf based memory regions * Update pyverbs with the new API * Add new tests This is the user space counter-part of the kernel patch set to add dma-buf support to the RDMA subsystem. This series consists of six patches. The first patch updates the kernel headers for dma-buf support. Patch 2 adds the new API function and updates the man pages. Patch 3 implements the new API in the mlx5 provider. Patch 4 adds new class definitions to pyverbs for the new API. Patch 5 adds a set of new tests for the new API. Patch 6 fixes bug in the utility code of the tests. Pull request at github: https://github.com/linux-rdma/rdma-core/pull/895 Jianxin Xiong (6): Update kernel headers verbs: Support dma-buf based memory region mlx5: Support dma-buf based memory region pyverbs: Add dma-buf based MR support tests: Add tests for dma-buf based memory regions tests: Bug fix for get_access_flags() buildlib/pyverbs_functions.cmake | 52 ++ debian/libibverbs1.symbols | 2 + kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++ kernel-headers/rdma/ib_user_verbs.h | 14 -- libibverbs/CMakeLists.txt| 2 +- libibverbs/cmd_mr.c | 38 libibverbs/driver.h | 7 + libibverbs/dummy_ops.c | 11 ++ libibverbs/libibverbs.map.in | 6 + libibverbs/man/ibv_reg_mr.3 | 27 ++- libibverbs/verbs.c | 18 ++ libibverbs/verbs.h | 11 ++ providers/mlx5/mlx5.c| 2 + providers/mlx5/mlx5.h| 3 + providers/mlx5/verbs.c | 22 +++ pyverbs/CMakeLists.txt | 7 + pyverbs/dmabuf.pxd | 15 ++ pyverbs/dmabuf.pyx | 72 pyverbs/dmabuf_alloc.c | 296 +++ pyverbs/dmabuf_alloc.h | 19 ++ pyverbs/libibverbs.pxd | 2 + pyverbs/mr.pxd | 6 + pyverbs/mr.pyx | 103 ++- tests/test_mr.py | 239 - tests/utils.py | 30 +++- 25 files changed, 996 insertions(+), 22 deletions(-) create mode 100644 pyverbs/dmabuf.pxd create mode 100644 pyverbs/dmabuf.pyx create mode 100644 pyverbs/dmabuf_alloc.c create mode 100644 pyverbs/dmabuf_alloc.h -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v3 3/6] mlx5: Support dma-buf based memory region
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git a/providers/mlx5/mlx5.c b/providers/mlx5/mlx5.c
index 1378acf..b3e2d57 100644
--- a/providers/mlx5/mlx5.c
+++ b/providers/mlx5/mlx5.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. 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
@@ -96,6 +97,7 @@ static const struct verbs_context_ops mlx5_ctx_common_ops = {
.async_event = mlx5_async_event,
.dealloc_pd= mlx5_free_pd,
.reg_mr= mlx5_reg_mr,
+ .reg_dmabuf_mr = mlx5_reg_dmabuf_mr,
.rereg_mr = mlx5_rereg_mr,
.dereg_mr = mlx5_dereg_mr,
.alloc_mw = mlx5_alloc_mw,
diff --git a/providers/mlx5/mlx5.h b/providers/mlx5/mlx5.h
index 8c94f72..17a2470 100644
--- a/providers/mlx5/mlx5.h
+++ b/providers/mlx5/mlx5.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. 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
@@ -903,6 +904,8 @@ void mlx5_async_event(struct ibv_context *context,
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd);
struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
uint64_t hca_va, int access);
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int access);
int mlx5_rereg_mr(struct verbs_mr *mr, int flags, struct ibv_pd *pd, void
*addr,
size_t length, int access);
int mlx5_dereg_mr(struct verbs_mr *mr);
diff --git a/providers/mlx5/verbs.c b/providers/mlx5/verbs.c
index b956156..a7fc3b0 100644
--- a/providers/mlx5/verbs.c
+++ b/providers/mlx5/verbs.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2012 Mellanox Technologies, Inc. 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
@@ -647,6 +648,27 @@ struct ibv_mr *mlx5_reg_mr(struct ibv_pd *pd, void *addr,
size_t length,
return >vmr.ibv_mr;
}
+struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t
length,
+ uint64_t iova, int fd, int acc)
+{
+ struct mlx5_mr *mr;
+ int ret;
+
+ mr = calloc(1, sizeof(*mr));
+ if (!mr)
+ return NULL;
+
+ ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, acc,
+ >vmr);
+ if (ret) {
+ free(mr);
+ return NULL;
+ }
+ mr->alloc_flags = acc;
+
+ return >vmr.ibv_mr;
+}
+
struct ibv_mr *mlx5_alloc_null_mr(struct ibv_pd *pd)
{
struct mlx5_mr *mr;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH rdma-core v3 2/6] verbs: Support dma-buf based memory region
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38 ++
libibverbs/driver.h | 7 +++
libibverbs/dummy_ops.c | 11 +++
libibverbs/libibverbs.map.in | 6 ++
libibverbs/man/ibv_reg_mr.3 | 27 +--
libibverbs/verbs.c | 18 ++
libibverbs/verbs.h | 11 +++
9 files changed, 119 insertions(+), 3 deletions(-)
diff --git a/debian/libibverbs1.symbols b/debian/libibverbs1.symbols
index 9130f41..fcf4d87 100644
--- a/debian/libibverbs1.symbols
+++ b/debian/libibverbs1.symbols
@@ -9,6 +9,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
IBVERBS_1.9@IBVERBS_1.9 30
IBVERBS_1.10@IBVERBS_1.10 31
IBVERBS_1.11@IBVERBS_1.11 32
+ IBVERBS_1.12@IBVERBS_1.12 33
(symver)IBVERBS_PRIVATE_33 33
_ibv_query_gid_ex@IBVERBS_1.11 32
_ibv_query_gid_table@IBVERBS_1.11 32
@@ -99,6 +100,7 @@ libibverbs.so.1 libibverbs1 #MINVER#
ibv_rate_to_mbps@IBVERBS_1.1 1.1.8
ibv_rate_to_mult@IBVERBS_1.0 1.1.6
ibv_read_sysfs_file@IBVERBS_1.0 1.1.6
+ ibv_reg_dmabuf_mr@IBVERBS_1.12 33
ibv_reg_mr@IBVERBS_1.0 1.1.6
ibv_reg_mr@IBVERBS_1.1 1.1.6
ibv_reg_mr_iova@IBVERBS_1.7 25
diff --git a/libibverbs/CMakeLists.txt b/libibverbs/CMakeLists.txt
index 0fe4256..d075225 100644
--- a/libibverbs/CMakeLists.txt
+++ b/libibverbs/CMakeLists.txt
@@ -21,7 +21,7 @@ configure_file("libibverbs.map.in"
rdma_library(ibverbs "${CMAKE_CURRENT_BINARY_DIR}/libibverbs.map"
# See Documentation/versioning.md
- 1 1.11.${PACKAGE_VERSION}
+ 1 1.12.${PACKAGE_VERSION}
all_providers.c
cmd.c
cmd_ah.c
diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
index 42dbe42..95ed2d1 100644
--- a/libibverbs/cmd_mr.c
+++ b/libibverbs/cmd_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018 Mellanox Technologies, Ltd. 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
@@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr
*vmr,
return 0;
}
+int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
+ uint64_t iova, int fd, int access,
+ struct verbs_mr *vmr)
+{
+ DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
+ 9);
+ struct ib_uverbs_attr *handle;
+ uint32_t lkey, rkey;
+ int ret;
+
+ handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, );
+ fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, );
+
+ fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
+ fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
+ fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
access);
+
+ ret = execute_ioctl(pd->context, cmdb);
+ if (ret)
+ return errno;
+
+ vmr->ibv_mr.handle = read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ handle);
+ vmr->ibv_mr.context = pd->context;
+ vmr->ibv_mr.lkey = lkey;
+ vmr->ibv_mr.rkey = rkey;
+ vmr->ibv_mr.pd = pd;
+ vmr->ibv_mr.addr = (void *)offset;
+ vmr->ibv_mr.length = length;
+ vmr->mr_type = IBV_MR_TYPE_MR;
+ return 0;
+}
diff --git a/libibverbs/driver.h b/libibverbs/driver.h
index ab80f4b..d6a9d0a 100644
--- a/libibverbs/driver.h
+++ b/libibverbs/driver.h
@@ -2,6 +2,7 @@
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005, 2006 Cisco Systems, Inc. All rights reserved.
* Copyright (c) 2005 PathScale, Inc. 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
@@ -373,6 +374,9 @@ struct verbs_context_ops {
struct ibv_mr *(*reg_dm_mr)(struct ibv_pd *pd, struct ibv_dm *dm,
uint64_t dm_offset, size_t length,
unsigned int access);
+ struct ibv_mr *(*reg_dmabuf_mr)(struct ibv_pd *pd, uint64_t offset,
+ size_t length, uint64_t iova,
+
[PATCH rdma-core v3 1/6] Update kernel headers
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
kernel-headers/rdma/ib_user_verbs.h | 14 --
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
b/kernel-headers/rdma/ib_user_ioctl_cmds.h
index 7968a18..dafc7eb 100644
--- a/kernel-headers/rdma/ib_user_ioctl_cmds.h
+++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. 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
@@ -251,6 +252,7 @@ enum uverbs_methods_mr {
UVERBS_METHOD_MR_DESTROY,
UVERBS_METHOD_ADVISE_MR,
UVERBS_METHOD_QUERY_MR,
+ UVERBS_METHOD_REG_DMABUF_MR,
};
enum uverbs_attrs_mr_destroy_ids {
@@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
UVERBS_ATTR_QUERY_MR_RESP_IOVA,
};
+enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
+ UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_REG_DMABUF_MR_FD,
+ UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+ UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+};
+
enum uverbs_attrs_create_counters_cmd_attr_ids {
UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
};
diff --git a/kernel-headers/rdma/ib_user_verbs.h
b/kernel-headers/rdma/ib_user_verbs.h
index 456438c..7ee73a0 100644
--- a/kernel-headers/rdma/ib_user_verbs.h
+++ b/kernel-headers/rdma/ib_user_verbs.h
@@ -596,20 +596,6 @@ enum {
IB_UVERBS_CREATE_QP_SUP_COMP_MASK = IB_UVERBS_CREATE_QP_MASK_IND_TABLE,
};
-enum {
- /*
-* This value is equal to IB_QP_DEST_QPN.
-*/
- IB_USER_LEGACY_LAST_QP_ATTR_MASK = 1ULL << 20,
-};
-
-enum {
- /*
-* This value is equal to IB_QP_RATE_LIMIT.
-*/
- IB_USER_LAST_QP_ATTR_MASK = 1ULL << 25,
-};
-
struct ib_uverbs_ex_create_qp {
__aligned_u64 user_handle;
__u32 pd_handle;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
Quoting Pandey, Hariom (2020-10-28 11:55:04) > Ok, I have initiated the steps to upgrade the CI machine's silicon & BIOS. The single ehl we have in CI is still failing to enter rc6, both in the selftest and runtime testing. And I note that RAPL doesn't recognise it, so it doesn't report the power consumption. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.10-rc6
The pull request you sent on Fri, 27 Nov 2020 18:37:15 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-27-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6910b676898934c2abe9f3ff3d60f4d4bc8afda8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 21/28] video: fbdev: tmiofb: Fix W=1 warnings
Fix W=1 warnings by avoiding local variables and use direct references.
Signed-off-by: Sam Ravnborg
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Jani Nikula
---
drivers/video/fbdev/tmiofb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/tmiofb.c b/drivers/video/fbdev/tmiofb.c
index 50111966c981..b70faa3850f2 100644
--- a/drivers/video/fbdev/tmiofb.c
+++ b/drivers/video/fbdev/tmiofb.c
@@ -802,10 +802,8 @@ static int tmiofb_remove(struct platform_device *dev)
const struct mfd_cell *cell = mfd_get_cell(dev);
struct fb_info *info = platform_get_drvdata(dev);
int irq = platform_get_irq(dev, 0);
- struct tmiofb_par *par;
if (info) {
- par = info->par;
unregister_framebuffer(info);
tmiofb_hw_stop(dev);
@@ -816,8 +814,8 @@ static int tmiofb_remove(struct platform_device *dev)
free_irq(irq, info);
iounmap(info->screen_base);
- iounmap(par->lcr);
- iounmap(par->ccr);
+ iounmap(((struct tmiofb_par *)info->par)->lcr);
+ iounmap(((struct tmiofb_par *)info->par)->ccr);
framebuffer_release(info);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 22/28] video: fbdev: omapfb: Fix W=1 warnings in dsi
Fix several W=1 warnings.
This removes a little unused code and avoids an assignment by moving
the use inside the conditional block.
Signed-off-by: Sam Ravnborg
Cc: Aditya Pakki
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index 6f9c25fec994..72d45a02c3ac 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -1178,13 +1178,12 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
static void _dsi_print_reset_status(struct platform_device *dsidev)
{
- u32 l;
int b0, b1, b2;
/* A dummy read using the SCP interface to any DSIPHY register is
* required after DSIPHY reset to complete the reset of the DSI complex
* I/O. */
- l = dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
+ dsi_read_reg(dsidev, DSI_DSIPHY_CFG5);
if (dss_has_feature(FEAT_DSI_REVERSE_TXCLKESC)) {
b0 = 28;
@@ -3627,7 +3626,7 @@ static int dsi_proto_config(struct platform_device
*dsidev)
static void dsi_proto_timings(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- unsigned tlpx, tclk_zero, tclk_prepare, tclk_trail;
+ unsigned tlpx, tclk_zero, tclk_prepare;
unsigned tclk_pre, tclk_post;
unsigned ths_prepare, ths_prepare_ths_zero, ths_zero;
unsigned ths_trail, ths_exit;
@@ -3646,7 +3645,6 @@ static void dsi_proto_timings(struct platform_device
*dsidev)
r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG1);
tlpx = FLD_GET(r, 20, 16) * 2;
- tclk_trail = FLD_GET(r, 15, 8);
tclk_zero = FLD_GET(r, 7, 0);
r = dsi_read_reg(dsidev, DSI_DSIPHY_CFG2);
@@ -4040,7 +4038,6 @@ static int dsi_update(struct omap_dss_device *dssdev, int
channel,
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
- u16 dw, dh;
dsi_perf_mark_setup(dsidev);
@@ -4049,11 +4046,8 @@ static int dsi_update(struct omap_dss_device *dssdev,
int channel,
dsi->framedone_callback = callback;
dsi->framedone_data = data;
- dw = dsi->timings.x_res;
- dh = dsi->timings.y_res;
-
#ifdef DSI_PERF_MEASURE
- dsi->update_bytes = dw * dh *
+ dsi->update_bytes = dsi->timings.x_res * dsi->timings.y_res *
dsi_get_pixel_size(dsi->pix_fmt) / 8;
#endif
dsi_update_screen_dispc(dsidev);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 28/28] video: fbdev: s1d13xxxfb: Fix W=1 warnings
Fix following W=1 warnings:
- Fix unused variables for variables used only for logging.
Fixed by introducing no_printk() to trick compiler to think variables
are used
- Fix kernel-doc warning by deleting an empty comment line
Signed-off-by: Sam Ravnborg
Cc: Kristoffer Ericson
---
drivers/video/fbdev/s1d13xxxfb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 4541afcf9386..d1b5f965bc96 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -45,7 +45,7 @@
#if 0
#define dbg(fmt, args...) do { printk(KERN_INFO fmt, ## args); } while(0)
#else
-#define dbg(fmt, args...) do { } while (0)
+#define dbg(fmt, args...) do { no_printk(KERN_INFO fmt, ## args); } while (0)
#endif
/*
@@ -512,7 +512,6 @@ s1d13xxxfb_bitblt_copyarea(struct fb_info *info, const
struct fb_copyarea *area)
}
/**
- *
* s1d13xxxfb_bitblt_solidfill - accelerated solidfill function
* @info : framebuffer structure
* @rect : fb_fillrect structure
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 27/28] video: fbdev: cirrusfb: Fix W=1 warnings
Fix warnings:
- fix kernel-doc
- delete unused code
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimemrmann
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Daniel Vetter
Cc: Saeed Mirzamohammadi
Cc: Jani Nikula
Cc: Mike Rapoport
---
drivers/video/fbdev/cirrusfb.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
index e9027172c0f5..93802abbbc72 100644
--- a/drivers/video/fbdev/cirrusfb.c
+++ b/drivers/video/fbdev/cirrusfb.c
@@ -2463,8 +2463,6 @@ static void AttrOn(const struct cirrusfb_info *cinfo)
*/
static void WHDR(const struct cirrusfb_info *cinfo, unsigned char val)
{
- unsigned char dummy;
-
if (is_laguna(cinfo))
return;
if (cinfo->btype == BT_PICASSO) {
@@ -2473,18 +2471,18 @@ static void WHDR(const struct cirrusfb_info *cinfo,
unsigned char val)
WGen(cinfo, VGA_PEL_MSK, 0x00);
udelay(200);
/* next read dummy from pixel address (3c8) */
- dummy = RGen(cinfo, VGA_PEL_IW);
+ RGen(cinfo, VGA_PEL_IW);
udelay(200);
}
/* now do the usual stuff to access the HDR */
- dummy = RGen(cinfo, VGA_PEL_MSK);
+ RGen(cinfo, VGA_PEL_MSK);
udelay(200);
- dummy = RGen(cinfo, VGA_PEL_MSK);
+ RGen(cinfo, VGA_PEL_MSK);
udelay(200);
- dummy = RGen(cinfo, VGA_PEL_MSK);
+ RGen(cinfo, VGA_PEL_MSK);
udelay(200);
- dummy = RGen(cinfo, VGA_PEL_MSK);
+ RGen(cinfo, VGA_PEL_MSK);
udelay(200);
WGen(cinfo, VGA_PEL_MSK, val);
@@ -2492,7 +2490,7 @@ static void WHDR(const struct cirrusfb_info *cinfo,
unsigned char val)
if (cinfo->btype == BT_PICASSO) {
/* now first reset HDR access counter */
- dummy = RGen(cinfo, VGA_PEL_IW);
+ RGen(cinfo, VGA_PEL_IW);
udelay(200);
/* and at the end, restore the mask value */
@@ -2800,9 +2798,9 @@ static void bestclock(long freq, int *nom, int *den, int
*div)
#ifdef CIRRUSFB_DEBUG
-/**
+/*
* cirrusfb_dbg_print_regs
- * @base: If using newmmio, the newmmio base address, otherwise %NULL
+ * @regbase: If using newmmio, the newmmio base address, otherwise %NULL
* @reg_class: type of registers to read: %CRT, or %SEQ
*
* DESCRIPTION:
@@ -2847,7 +2845,7 @@ static void cirrusfb_dbg_print_regs(struct fb_info *info,
va_end(list);
}
-/**
+/*
* cirrusfb_dbg_reg_dump
* @base: If using newmmio, the newmmio base address, otherwise %NULL
*
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 24/28] video: fbdev: s3c-fb: Fix W=1 warnings
Fix several W=1 warnings
- Updated kernel-doc as needed
- Deleted unused local variable, it was assigned but never used
Signed-off-by: Sam Ravnborg
Cc: Jingoo Han
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/s3c-fb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index ba316bd56efd..3b134e1bbc38 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -75,6 +75,7 @@ struct s3c_fb;
* @buf_size: Offset of buffer size registers.
* @buf_end: Offset of buffer end registers.
* @osd: The base for the OSD registers.
+ * @osd_stride: stride of osd
* @palette: Address of palette memory, or 0 if none.
* @has_prtcon: Set if has PRTCON register.
* @has_shadowcon: Set if has SHADOWCON register.
@@ -155,7 +156,7 @@ struct s3c_fb_palette {
* @windata: The platform data supplied for the window configuration.
* @parent: The hardware that this window is part of.
* @fbinfo: Pointer pack to the framebuffer info for this window.
- * @varint: The variant information for this window.
+ * @variant: The variant information for this window.
* @palette_buffer: Buffer/cache to hold palette entries.
* @pseudo_palette: For use in TRUECOLOUR modes for entries 0..15/
* @index: The window number of this window.
@@ -336,7 +337,7 @@ static int s3c_fb_check_var(struct fb_var_screeninfo *var,
/**
* s3c_fb_calc_pixclk() - calculate the divider to create the pixel clock.
* @sfb: The hardware state.
- * @pixclock: The pixel clock wanted, in picoseconds.
+ * @pixclk: The pixel clock wanted, in picoseconds.
*
* Given the specified pixel clock, work out the necessary divider to get
* close to the output frequency.
@@ -733,7 +734,7 @@ static inline unsigned int chan_to_field(unsigned int chan,
* @red: The red field for the palette data.
* @green: The green field for the palette data.
* @blue: The blue field for the palette data.
- * @trans: The transparency (alpha) field for the palette data.
+ * @transp: The transparency (alpha) field for the palette data.
* @info: The framebuffer being changed.
*/
static int s3c_fb_setcolreg(unsigned regno,
@@ -1133,6 +1134,7 @@ static void s3c_fb_free_memory(struct s3c_fb *sfb, struct
s3c_fb_win *win)
/**
* s3c_fb_release_win() - release resources for a framebuffer window.
+ * @sfb: The base resources for the hardware.
* @win: The window to cleanup the resources for.
*
* Release the resources that where claimed for the hardware window,
@@ -1160,6 +1162,7 @@ static void s3c_fb_release_win(struct s3c_fb *sfb, struct
s3c_fb_win *win)
/**
* s3c_fb_probe_win() - register an hardware window
* @sfb: The base resources for the hardware
+ * @win_no: The window number
* @variant: The variant information for this window.
* @res: Pointer to where to place the resultant window.
*
@@ -1170,7 +1173,6 @@ static int s3c_fb_probe_win(struct s3c_fb *sfb, unsigned
int win_no,
struct s3c_fb_win_variant *variant,
struct s3c_fb_win **res)
{
- struct fb_var_screeninfo *var;
struct fb_videomode initmode;
struct s3c_fb_pd_win *windata;
struct s3c_fb_win *win;
@@ -1198,7 +1200,6 @@ static int s3c_fb_probe_win(struct s3c_fb *sfb, unsigned
int win_no,
win = fbinfo->par;
*res = win;
- var = >var;
win->variant = *variant;
win->fbinfo = fbinfo;
win->parent = sfb;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 25/28] video: fbdev: uvesafb: Fix W=1 warning
Fix W=1 warning by deleting unused local variable.
Signed-off-by: Sam Ravnborg
Cc: Michal Januszewski
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/uvesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index def14ac0ebe1..8ee0fc9c63cf 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -554,12 +554,12 @@ static int uvesafb_vbe_getmodes(struct uvesafb_ktask
*task,
static int uvesafb_vbe_getpmi(struct uvesafb_ktask *task,
struct uvesafb_par *par)
{
- int i, err;
+ int i;
uvesafb_reset(task);
task->t.regs.eax = 0x4f0a;
task->t.regs.ebx = 0x0;
- err = uvesafb_exec(task);
+ uvesafb_exec(task);
if ((task->t.regs.eax & 0x) != 0x4f || task->t.regs.es < 0xc000) {
par->pmi_setpal = par->ypan = 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 23/28] video: fbdev: omapfb: Fix W=1 warnings in hdmi*_core
Fix a few W=1 warnings about unused assignments. Drop the unused error code. Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Qilong Zhang Cc: "Alexander A. Klimov" Cc: Daniel Vetter --- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 4 ++-- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c index 726c190862d4..e6363a420933 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c @@ -679,7 +679,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config acore; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -741,7 +741,7 @@ int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, , ); + hdmi_compute_acr(pclk, fs_nr, , ); /* Audio clock regeneration settings */ acore.n = n; diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c index eda29d3032e1..cb63bc0e92ca 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c @@ -790,7 +790,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, struct hdmi_audio_format audio_format; struct hdmi_audio_dma audio_dma; struct hdmi_core_audio_config core_cfg; - int err, n, cts, channel_count; + int n, cts, channel_count; unsigned int fs_nr; bool word_length_16b = false; @@ -833,7 +833,7 @@ int hdmi5_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp, return -EINVAL; } - err = hdmi_compute_acr(pclk, fs_nr, , ); + hdmi_compute_acr(pclk, fs_nr, , ); core_cfg.n = n; core_cfg.cts = cts; -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 14/28] video: fbdev: pm2fb: Fix W=1 warnings
Fixed a few kernel-doc issues to fix the warnings.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Randy Dunlap
Cc: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz
Cc: Jani Nikula
---
drivers/video/fbdev/pm2fb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..c68725eebee3 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -1508,8 +1508,8 @@ static const struct fb_ops pm2fb_ops = {
*
* Initialise and allocate resource for PCI device.
*
- * @param pdevPCI device.
- * @param id PCI device ID.
+ * @pdev: PCI device.
+ * @id:PCI device ID.
*/
static int pm2fb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
@@ -1715,7 +1715,7 @@ static int pm2fb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
*
* Release all device resources.
*
- * @param pdevPCI device to clean up.
+ * @pdev: PCI device to clean up.
*/
static void pm2fb_remove(struct pci_dev *pdev)
{
@@ -1756,7 +1756,7 @@ MODULE_DEVICE_TABLE(pci, pm2fb_id_table);
#ifndef MODULE
-/**
+/*
* Parse user specified options.
*
* This is, comma-separated options following `video=pm2fb:'.
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 26/28] video: fbdev: uvesafb: Fix W=1 string related warnings
Two W=1 string related warnings.
- Using strncpy to copy string wihtout null-termination is not good.
Use memcpy to copy only the relevant chars
- Fix a potential bug with a very long string, subtract one from the
length to make room for the termination null.
Signed-off-by: Sam Ravnborg
Cc: Michal Januszewski
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/uvesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 8ee0fc9c63cf..45dc8da191e4 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -423,7 +423,7 @@ static int uvesafb_vbe_getinfo(struct uvesafb_ktask *task,
task->t.flags = TF_VBEIB;
task->t.buf_len = sizeof(struct vbe_ib);
task->buf = >vbe_ib;
- strncpy(par->vbe_ib.vbe_signature, "VBE2", 4);
+ memcpy(par->vbe_ib.vbe_signature, "VBE2", 4);
err = uvesafb_exec(task);
if (err || (task->t.regs.eax & 0x) != 0x004f) {
@@ -1871,7 +1871,7 @@ static ssize_t v86d_show(struct device_driver *dev, char
*buf)
static ssize_t v86d_store(struct device_driver *dev, const char *buf,
size_t count)
{
- strncpy(v86d_path, buf, PATH_MAX);
+ strncpy(v86d_path, buf, PATH_MAX - 1);
return count;
}
static DRIVER_ATTR_RW(v86d);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 17/28] video: fbdev: tgafb: Fix W=1 warnings
Fix W=1 warnings: - Fix kernel-doc - Drop unused code Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Jani Nikula Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Arnd Bergmann Cc: Joe Perches --- drivers/video/fbdev/tgafb.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/fbdev/tgafb.c b/drivers/video/fbdev/tgafb.c index 666fbe2f671c..ae0cf5540636 100644 --- a/drivers/video/fbdev/tgafb.c +++ b/drivers/video/fbdev/tgafb.c @@ -555,7 +555,7 @@ tgafb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned blue, /** * tgafb_blank - Optional function. Blanks the display. - * @blank_mode: the blank mode we want. + * @blank: the blank mode we want. * @info: frame buffer structure that represents a single frame buffer */ static int @@ -837,7 +837,7 @@ tgafb_clut_imageblit(struct fb_info *info, const struct fb_image *image) u32 *palette = ((u32 *)info->pseudo_palette); unsigned long pos, line_length, i, j; const unsigned char *data; - void __iomem *regs_base, *fb_base; + void __iomem *fb_base; dx = image->dx; dy = image->dy; @@ -855,7 +855,6 @@ tgafb_clut_imageblit(struct fb_info *info, const struct fb_image *image) if (dy + height > vyres) height = vyres - dy; - regs_base = par->tga_regs_base; fb_base = par->tga_fb_base; pos = dy * line_length + (dx * 4); @@ -1034,7 +1033,7 @@ tgafb_fillrect(struct fb_info *info, const struct fb_fillrect *rect) regs_base + TGA_MODE_REG); } -/** +/* * tgafb_copyarea - REQUIRED function. Can use generic routines if * non acclerated hardware and packed pixel based. * Copies on area of the screen to another area. -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 19/28] video: fbdev: sstfb: Fix W=1 warnings
Fix W=1 warnings by introducing no_printk variants for the
internal logging system for this driver.
Fix a new warning that popped up now that logging was checked for
correct printf format strings.
A more invasive fix had been to replace all the internal logging with
standard logging primitives - thats for another day.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Arnd Bergmann
Cc: Bartlomiej Zolnierkiewicz
Cc: Alex Dewar
Cc: Jani Nikula
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/sstfb.c | 2 +-
include/video/sstfb.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
index c05cdabeb11c..27d4b0ace2d6 100644
--- a/drivers/video/fbdev/sstfb.c
+++ b/drivers/video/fbdev/sstfb.c
@@ -1390,7 +1390,7 @@ static int sstfb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
fix->smem_start, info->screen_base,
fix->smem_len >> 20);
- f_ddprintk("regbase_virt: %#lx\n", par->mmio_vbase);
+ f_ddprintk("regbase_virt: %p\n", par->mmio_vbase);
f_ddprintk("membase_phys: %#lx\n", fix->smem_start);
f_ddprintk("fbbase_virt: %p\n", info->screen_base);
diff --git a/include/video/sstfb.h b/include/video/sstfb.h
index 28384f354773..d4a5e41d1173 100644
--- a/include/video/sstfb.h
+++ b/include/video/sstfb.h
@@ -23,7 +23,7 @@
# define SST_DEBUG_FUNC 1
# define SST_DEBUG_VAR 1
#else
-# define dprintk(X...)
+# define dprintk(X...)no_printk(X)
# define SST_DEBUG_REG 0
# define SST_DEBUG_FUNC 0
# define SST_DEBUG_VAR 0
@@ -48,7 +48,7 @@
#if (SST_DEBUG_FUNC > 1)
# define f_ddprintk(X...) dprintk(" " X)
#else
-# define f_ddprintk(X...)
+# define f_ddprintk(X...) no_printk(X)
#endif
#if (SST_DEBUG_FUNC > 2)
# define f_dddprintk(X...)dprintk(" " X)
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 20/28] video: fbdev: nvidia: Fix W=1 warnings
Fix warnings by deleting unused code
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/nvidia/nv_setup.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c
b/drivers/video/fbdev/nvidia/nv_setup.c
index 2fa68669613a..5404017e6957 100644
--- a/drivers/video/fbdev/nvidia/nv_setup.c
+++ b/drivers/video/fbdev/nvidia/nv_setup.c
@@ -89,9 +89,8 @@ u8 NVReadSeq(struct nvidia_par *par, u8 index)
}
void NVWriteAttr(struct nvidia_par *par, u8 index, u8 value)
{
- volatile u8 tmp;
- tmp = VGA_RD08(par->PCIO, par->IOBase + 0x0a);
+ VGA_RD08(par->PCIO, par->IOBase + 0x0a);
if (par->paletteEnabled)
index &= ~0x20;
else
@@ -101,9 +100,7 @@ void NVWriteAttr(struct nvidia_par *par, u8 index, u8 value)
}
u8 NVReadAttr(struct nvidia_par *par, u8 index)
{
- volatile u8 tmp;
-
- tmp = VGA_RD08(par->PCIO, par->IOBase + 0x0a);
+ VGA_RD08(par->PCIO, par->IOBase + 0x0a);
if (par->paletteEnabled)
index &= ~0x20;
else
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 15/28] video: fbdev: neofb: Fix W=1 warnings
Fix W=1 warnigns by removing unused code
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Andrew Morton
Cc: Evgeny Novikov
Cc: Jani Nikula
Cc: Mike Rapoport
---
drivers/video/fbdev/neofb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/fbdev/neofb.c b/drivers/video/fbdev/neofb.c
index 09a20d4ab35f..c0f4f402da3f 100644
--- a/drivers/video/fbdev/neofb.c
+++ b/drivers/video/fbdev/neofb.c
@@ -1843,7 +1843,6 @@ static int neo_init_hw(struct fb_info *info)
struct neofb_par *par = info->par;
int videoRam = 896;
int maxClock = 65000;
- int CursorMem = 1024;
int CursorOff = 0x100;
DBG("neo_init_hw");
@@ -1895,19 +1894,16 @@ static int neo_init_hw(struct fb_info *info)
case FB_ACCEL_NEOMAGIC_NM2070:
case FB_ACCEL_NEOMAGIC_NM2090:
case FB_ACCEL_NEOMAGIC_NM2093:
- CursorMem = 2048;
CursorOff = 0x100;
break;
case FB_ACCEL_NEOMAGIC_NM2097:
case FB_ACCEL_NEOMAGIC_NM2160:
- CursorMem = 1024;
CursorOff = 0x100;
break;
case FB_ACCEL_NEOMAGIC_NM2200:
case FB_ACCEL_NEOMAGIC_NM2230:
case FB_ACCEL_NEOMAGIC_NM2360:
case FB_ACCEL_NEOMAGIC_NM2380:
- CursorMem = 1024;
CursorOff = 0x1000;
par->neo2200 = (Neo2200 __iomem *) par->mmio_vbase;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 18/28] video: fbdev: mx3fb: Fix W=1 warnings
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused code/variables
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Xiaofei Tan
Cc: Arnd Bergmann
---
drivers/video/fbdev/mx3fb.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index 894617ddabcb..fabb271337ed 100644
--- a/drivers/video/fbdev/mx3fb.c
+++ b/drivers/video/fbdev/mx3fb.c
@@ -445,7 +445,6 @@ static void sdc_enable_channel(struct mx3fb_info *mx3_fbi)
static void sdc_disable_channel(struct mx3fb_info *mx3_fbi)
{
struct mx3fb_data *mx3fb = mx3_fbi->mx3fb;
- uint32_t enabled;
unsigned long flags;
if (mx3_fbi->txd == NULL)
@@ -453,7 +452,7 @@ static void sdc_disable_channel(struct mx3fb_info *mx3_fbi)
spin_lock_irqsave(>lock, flags);
- enabled = sdc_fb_uninit(mx3_fbi);
+ sdc_fb_uninit(mx3_fbi);
spin_unlock_irqrestore(>lock, flags);
@@ -732,7 +731,7 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi);
/**
* mx3fb_set_fix() - set fixed framebuffer parameters from variable settings.
- * @info: framebuffer information pointer
+ * @fbi: framebuffer information pointer
* @return:0 on success or negative error code on failure.
*/
static int mx3fb_set_fix(struct fb_info *fbi)
@@ -740,7 +739,7 @@ static int mx3fb_set_fix(struct fb_info *fbi)
struct fb_fix_screeninfo *fix = >fix;
struct fb_var_screeninfo *var = >var;
- strncpy(fix->id, "DISP3 BG", 8);
+ memcpy(fix->id, "DISP3 BG", 8);
fix->line_length = var->xres_virtual * var->bits_per_pixel / 8;
@@ -1105,6 +1104,8 @@ static void __blank(int blank, struct fb_info *fbi)
/**
* mx3fb_blank() - blank the display.
+ * @blank: blank value for the panel
+ * @fbi: framebuffer information pointer
*/
static int mx3fb_blank(int blank, struct fb_info *fbi)
{
@@ -1126,7 +1127,7 @@ static int mx3fb_blank(int blank, struct fb_info *fbi)
/**
* mx3fb_pan_display() - pan or wrap the display
* @var: variable screen buffer information.
- * @info: framebuffer information pointer.
+ * @fbi: framebuffer information pointer.
*
* We look only at xoffset, yoffset and the FB_VMODE_YWRAP flag
*/
@@ -1387,6 +1388,8 @@ static int mx3fb_unmap_video_memory(struct fb_info *fbi)
/**
* mx3fb_init_fbinfo() - initialize framebuffer information object.
+ * @dev: the device
+ * @ops: framebuffer device operations
* @return:initialized framebuffer structure.
*/
static struct fb_info *mx3fb_init_fbinfo(struct device *dev,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 13/28] video: fbdev: riva: Fix W=1 warnings
Fix W=1 warnings:
- Fix kernel-doc
- Drop unused variables/code
Signed-off-by: Sam Ravnborg
Cc: Antonino Daplas
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/riva/fbdev.c | 9 -
drivers/video/fbdev/riva/riva_hw.c | 28
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index ce55b9d2e862..4b0433cb 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -464,7 +464,7 @@ static inline void reverse_order(u32 *l)
/**
* rivafb_load_cursor_image - load cursor image to hardware
- * @data: address to monochrome bitmap (1 = foreground color, 0 = background)
+ * @data8: address to monochrome bitmap (1 = foreground color, 0 = background)
* @par: pointer to private data
* @w:width of cursor image in pixels
* @h:height of cursor image in scanlines
@@ -843,9 +843,9 @@ static void riva_update_var(struct fb_var_screeninfo *var,
/**
* rivafb_do_maximize -
* @info: pointer to fb_info object containing info for current riva board
- * @var:
- * @nom:
- * @den:
+ * @var: standard kernel fb changeable data
+ * @nom: nom
+ * @den: den
*
* DESCRIPTION:
* .
@@ -1214,7 +1214,6 @@ static int rivafb_set_par(struct fb_info *info)
/**
* rivafb_pan_display
* @var: standard kernel fb changeable data
- * @con: TODO
* @info: pointer to fb_info object containing info for current riva board
*
* DESCRIPTION:
diff --git a/drivers/video/fbdev/riva/riva_hw.c
b/drivers/video/fbdev/riva/riva_hw.c
index bcf9c4b4de31..8b829b720064 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -836,17 +836,17 @@ static void nv10CalcArbitration
nv10_sim_state *arb
)
{
-int data, pagemiss, cas,width, video_enable, bpp;
-int nvclks, mclks, pclks, vpagemiss, crtpagemiss, vbs;
-int nvclk_fill, us_extra;
+int data, pagemiss, width, video_enable, bpp;
+int nvclks, mclks, pclks, vpagemiss, crtpagemiss;
+int nvclk_fill;
int found, mclk_extra, mclk_loop, cbs, m1;
int mclk_freq, pclk_freq, nvclk_freq, mp_enable;
-int us_m, us_m_min, us_n, us_p, video_drain_rate, crtc_drain_rate;
-int vus_m, vus_n, vus_p;
-int vpm_us, us_video, vlwm, cpm_us, us_crt,clwm;
+int us_m, us_m_min, us_n, us_p, crtc_drain_rate;
+int vus_m;
+int vpm_us, us_video, cpm_us, us_crt,clwm;
int clwm_rnd_down;
-int craw, m2us, us_pipe, us_pipe_min, vus_pipe, p1clk, p2;
-int pclks_2_top_fifo, min_mclk_extra;
+int m2us, us_pipe_min, p1clk, p2;
+int min_mclk_extra;
int us_min_mclk_extra;
fifo->valid = 1;
@@ -854,16 +854,13 @@ static void nv10CalcArbitration
mclk_freq = arb->mclk_khz;
nvclk_freq = arb->nvclk_khz;
pagemiss = arb->mem_page_miss;
-cas = arb->mem_latency;
width = arb->memory_width/64;
video_enable = arb->enable_video;
bpp = arb->pix_bpp;
mp_enable = arb->enable_mp;
clwm = 0;
-vlwm = 1024;
cbs = 512;
-vbs = 512;
pclks = 4; /* lwm detect. */
@@ -924,17 +921,11 @@ static void nv10CalcArbitration
us_min_mclk_extra = min_mclk_extra *1000*1000 / mclk_freq;
us_n = nvclks*1000*1000 / nvclk_freq;/* nvclk latency in us */
us_p = pclks*1000*1000 / pclk_freq;/* nvclk latency in us */
- us_pipe = us_m + us_n + us_p;
us_pipe_min = us_m_min + us_n + us_p;
- us_extra = 0;
vus_m = mclk_loop *1000*1000 / mclk_freq; /* Mclk latency in us */
- vus_n = (4)*1000*1000 / nvclk_freq;/* nvclk latency in us */
- vus_p = 0*1000*1000 / pclk_freq;/* pclk latency in us */
- vus_pipe = vus_m + vus_n + vus_p;
if(video_enable) {
-video_drain_rate = pclk_freq * 4; /* MB/s */
crtc_drain_rate = pclk_freq * bpp/8; /* MB/s */
vpagemiss = 1; /* self generating page miss */
@@ -993,7 +984,6 @@ static void nv10CalcArbitration
else if(crtc_drain_rate * 100 >= nvclk_fill * 98) {
clwm = 1024;
cbs = 512;
- us_extra = (cbs * 1000 * 1000)/ (8*width)/mclk_freq ;
}
}
}
@@ -1010,7 +1000,6 @@ static void nv10CalcArbitration
m1 = clwm + cbs - 1024; /* Amount of overfill */
m2us = us_pipe_min + us_min_mclk_extra;
- pclks_2_top_fifo = (1024-clwm)/(8*width);
/* pclk cycles to drain */
p1clk = m2us * pclk_freq/(1000*1000);
@@ -1038,7 +1027,6 @@ static void nv10CalcArbitration
min_mclk_extra--;
}
}
- craw = clwm;
if(clwm < (1024-cbs+8)) clwm = 1024-cbs+8;
data = (int)(clwm);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 16/28] video: fbdev: hgafb: Fix W=1 warnings
Fix kernel-doc comments. Signed-off-by: Sam Ravnborg Cc: Ferenc Bakonyi Cc: linux-nvi...@lists.surfsouth.com --- drivers/video/fbdev/hgafb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c index a45fcff1461f..69af72937844 100644 --- a/drivers/video/fbdev/hgafb.c +++ b/drivers/video/fbdev/hgafb.c @@ -358,7 +358,7 @@ static int hga_card_detect(void) /** * hgafb_open - open the framebuffer device * @info:pointer to fb_info object containing info for current hga board - * @int:open by console system or userland. + * @init:open by console system or userland. */ static int hgafb_open(struct fb_info *info, int init) @@ -372,7 +372,7 @@ static int hgafb_open(struct fb_info *info, int init) /** * hgafb_open - open the framebuffer device * @info:pointer to fb_info object containing info for current hga board - * @int:open by console system or userland. + * @init:open by console system or userland. */ static int hgafb_release(struct fb_info *info, int init) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 08/28] video: fbdev: sis: Fix W=1 warning about SiS_TVDelay
Fix W=1 warning by commenting unused SiS_TVDelay* variables.
The SiS_TVDelay* variables seem to contain some magic numbers
so looks like data worth keeping around but not as code we build.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/oem310.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/sis/oem310.h b/drivers/video/fbdev/sis/oem310.h
index 8fce56e4482c..ed28755715ce 100644
--- a/drivers/video/fbdev/sis/oem310.h
+++ b/drivers/video/fbdev/sis/oem310.h
@@ -200,6 +200,7 @@ static const unsigned char
SiS310_TVDelayCompensation_651302LV[] = /* M650, 651,
0x33,0x33
};
+#if 0 /* Not used */
static const unsigned char SiS_TVDelay661_301[] = /* 661,
301 */
{
0x44,0x44,
@@ -219,6 +220,7 @@ static const unsigned char SiS_TVDelay661_301B[] =
/* 661, 301B et al */
0x44,0x44,
0x44,0x44
};
+#endif
static const unsigned char SiS310_TVDelayCompensation_LVDS[] = /* LVDS
*/
{
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 11/28] video: fbdev: via: Fix W=1 warnings
Fix W=1 warnings about unused assignment. Fixed by dropping the assignment and deleting the local variable. Signed-off-by: Sam Ravnborg Cc: Florian Tobias Schandinat Cc: linux-fb...@vger.kernel.org --- drivers/video/fbdev/via/lcd.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/via/lcd.c b/drivers/video/fbdev/via/lcd.c index 4a869402d120..088b962076b5 100644 --- a/drivers/video/fbdev/via/lcd.c +++ b/drivers/video/fbdev/via/lcd.c @@ -537,11 +537,9 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo *var, u16 cxres, u32 clock; struct via_display_timing timing; struct fb_var_screeninfo panel_var; - const struct fb_videomode *mode_crt_table, *panel_crt_table; + const struct fb_videomode *panel_crt_table; DEBUG_MSG(KERN_INFO "viafb_lcd_set_mode!!\n"); - /* Get mode table */ - mode_crt_table = viafb_get_best_mode(set_hres, set_vres, 60); /* Get panel table Pointer */ panel_crt_table = viafb_get_best_mode(panel_hres, panel_vres, 60); viafb_fill_var_timing_info(_var, panel_crt_table); -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 12/28] video: fbdev: tdfx: Fix W=1 warnings
Fix W=1 warning about unused assignment.
Fix by dropping the local variable.
Signed-off-by: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Sam Ravnborg
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Arnd Bergmann
---
drivers/video/fbdev/tdfxfb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/tdfxfb.c b/drivers/video/fbdev/tdfxfb.c
index f056d80f6359..67e37a62b07c 100644
--- a/drivers/video/fbdev/tdfxfb.c
+++ b/drivers/video/fbdev/tdfxfb.c
@@ -206,9 +206,7 @@ static inline u8 crt_inb(struct tdfx_par *par, u32 idx)
static inline void att_outb(struct tdfx_par *par, u32 idx, u8 val)
{
- unsigned char tmp;
-
- tmp = vga_inb(par, IS1_R);
+ vga_inb(par, IS1_R);
vga_outb(par, ATT_IW, idx);
vga_outb(par, ATT_IW, val);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 07/28] video: fbdev: sis: Fix W=1 warnings about static symbols
init.h define static symbols, so should only be included once. Drop the include from sis.h as it is not needed. This fixes a lot of warnings seen with a W=1 build. Signed-off-by: Sam Ravnborg Cc: Thomas Winischhofer --- drivers/video/fbdev/sis/sis.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/sis/sis.h b/drivers/video/fbdev/sis/sis.h index 9f4c3093ccb3..d632f096083b 100644 --- a/drivers/video/fbdev/sis/sis.h +++ b/drivers/video/fbdev/sis/sis.h @@ -15,7 +15,6 @@ #include "vgatypes.h" #include "vstruct.h" -#include "init.h" #define VER_MAJOR 1 #define VER_MINOR 8 -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 09/28] video: fbdev: sis: Fix W=1 warnings in init.c
Fix several W=1 warnings.
This removes a lot of unused code - which is always a good thing to do.
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/init.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index fde27feae5d0..b77ea1a8825a 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -2648,7 +2648,7 @@ static void
SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned short ModeNo,
unsigned short ModeIdIndex, unsigned short RRTI)
{
- unsigned short data, infoflag = 0, modeflag, resindex;
+ unsigned short data, infoflag = 0, modeflag;
#ifdef CONFIG_FB_SIS_315
unsigned char *ROMAddr = SiS_Pr->VirtualRomBase;
unsigned short data2, data3;
@@ -2659,7 +2659,7 @@ SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned
short ModeNo,
if(SiS_Pr->UseCustomMode) {
infoflag = SiS_Pr->CInfoFlag;
} else {
- resindex = SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
+ SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
if(ModeNo > 0x13) {
infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag;
}
@@ -3538,17 +3538,13 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
struct fb_var_screeninfo *var, bool writeres
)
{
- unsigned short HRE, HBE, HRS, HBS, HDE, HT;
- unsigned short VRE, VBE, VRS, VBS, VDE, VT;
- unsigned char sr_data, cr_data, cr_data2;
- intA, B, C, D, E, F, temp;
+ unsigned short HRE, HBE, HRS, HDE;
+ unsigned short VRE, VBE, VRS, VDE;
+ unsigned char sr_data, cr_data;
+ intB, C, D, E, F, temp;
sr_data = crdata[14];
- /* Horizontal total */
- HT = crdata[0] | ((unsigned short)(sr_data & 0x03) << 8);
- A = HT + 5;
-
/* Horizontal display enable end */
HDE = crdata[1] | ((unsigned short)(sr_data & 0x0C) << 6);
E = HDE + 1;
@@ -3557,9 +3553,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
HRS = crdata[4] | ((unsigned short)(sr_data & 0xC0) << 2);
F = HRS - E - 3;
- /* Horizontal blank start */
- HBS = crdata[2] | ((unsigned short)(sr_data & 0x30) << 4);
-
sr_data = crdata[15];
cr_data = crdata[5];
@@ -3588,13 +3581,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
sr_data = crdata[13];
cr_data = crdata[7];
- /* Vertical total */
- VT = crdata[6] |
-((unsigned short)(cr_data & 0x01) << 8) |
-((unsigned short)(cr_data & 0x20) << 4) |
-((unsigned short)(sr_data & 0x01) << 10);
- A = VT + 2;
-
/* Vertical display enable end */
VDE = crdata[10] |
((unsigned short)(cr_data & 0x02) << 7) |
@@ -3609,14 +3595,6 @@ SiS_Generic_ConvertCRData(struct SiS_Private *SiS_Pr,
unsigned char *crdata,
((unsigned short)(sr_data & 0x08) << 7);
F = VRS + 1 - E;
- cr_data2 = (crdata[16] & 0x01) << 5;
-
- /* Vertical blank start */
- VBS = crdata[11] |
-((unsigned short)(cr_data & 0x08) << 5) |
-((unsigned short)(cr_data2 & 0x20) << 4) |
-((unsigned short)(sr_data & 0x04) << 8);
-
/* Vertical blank end */
VBE = crdata[12] | ((unsigned short)(sr_data & 0x10) << 4);
temp = VBE - ((E - 1) & 511);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 10/28] video: fbdev: sis: Fix W=1 warnings in sis_main
Fix W=1 warning by dropping unused variable
Signed-off-by: Sam Ravnborg
Cc: Thomas Winischhofer
---
drivers/video/fbdev/sis/sis_main.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c
b/drivers/video/fbdev/sis/sis_main.c
index 03c736f6f3d0..266a5582f94d 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -5029,7 +5029,6 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
static const u8 cs168[8] = {
0x48, 0x78, 0x88, 0x00, 0x00, 0x00, 0x00, 0x00
};
- u8 reg;
u8 v1;
u8 v2;
u8 v3;
@@ -5037,9 +5036,9 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
SiS_SetReg(SISCR, 0xb0, 0x80); /* DDR2 dual frequency mode */
SiS_SetReg(SISCR, 0x82, 0x77);
SiS_SetReg(SISCR, 0x86, 0x00);
- reg = SiS_GetReg(SISCR, 0x86);
+ SiS_GetReg(SISCR, 0x86);
SiS_SetReg(SISCR, 0x86, 0x88);
- reg = SiS_GetReg(SISCR, 0x86);
+ SiS_GetReg(SISCR, 0x86);
v1 = cs168[regb]; v2 = cs160[regb]; v3 = cs158[regb];
if (ivideo->haveXGIROM) {
v1 = bios[regb + 0x168];
@@ -5049,9 +5048,9 @@ static void sisfb_post_xgi_ddr2(struct sis_video_info
*ivideo, u8 regb)
SiS_SetReg(SISCR, 0x86, v1);
SiS_SetReg(SISCR, 0x82, 0x77);
SiS_SetReg(SISCR, 0x85, 0x00);
- reg = SiS_GetReg(SISCR, 0x85);
+ SiS_GetReg(SISCR, 0x85);
SiS_SetReg(SISCR, 0x85, 0x88);
- reg = SiS_GetReg(SISCR, 0x85);
+ SiS_GetReg(SISCR, 0x85);
SiS_SetReg(SISCR, 0x85, v2);
SiS_SetReg(SISCR, 0x82, v3);
SiS_SetReg(SISCR, 0x98, 0x01);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 06/28] video: fbdev: aty: Fix W=1 warnings in mach64_ct
Fix W=1 about variables assigned but never used.
- One variable is only used when CONFIG_FB_ATY_GENERIC_LCD is defined
Fix so variable is only defined with CONFIG_FB_ATY_GENERIC_LCD
- Several variables was only assigned by a call to aty_ld_le32().
Drop the variables but keep the call to aty_ld_le32() as it may
have unexpected side-effects.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
---
drivers/video/fbdev/aty/mach64_ct.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/aty/mach64_ct.c
b/drivers/video/fbdev/aty/mach64_ct.c
index f87cc81f4fa2..011b07e44e0d 100644
--- a/drivers/video/fbdev/aty/mach64_ct.c
+++ b/drivers/video/fbdev/aty/mach64_ct.c
@@ -281,10 +281,13 @@ static u32 aty_pll_to_var_ct(const struct fb_info *info,
const union aty_pll *pl
void aty_set_pll_ct(const struct fb_info *info, const union aty_pll *pll)
{
struct atyfb_par *par = (struct atyfb_par *) info->par;
- u32 crtc_gen_cntl, lcd_gen_cntrl;
+ u32 crtc_gen_cntl;
u8 tmp, tmp2;
- lcd_gen_cntrl = 0;
+#ifdef CONFIG_FB_ATY_GENERIC_LCD
+ u32 lcd_gen_cntrl = 0;
+#endif
+
#ifdef DEBUG
printk("atyfb(%s): about to program:\n"
"pll_ext_cntl=0x%02x pll_gen_cntl=0x%02x
pll_vclk_cntl=0x%02x\n",
@@ -402,7 +405,7 @@ static int aty_init_pll_ct(const struct fb_info *info,
union aty_pll *pll)
struct atyfb_par *par = (struct atyfb_par *) info->par;
u8 mpost_div, xpost_div, sclk_post_div_real;
u32 q, memcntl, trp;
- u32 dsp_config, dsp_on_off, vga_dsp_config, vga_dsp_on_off;
+ u32 dsp_config;
#ifdef DEBUG
int pllmclk, pllsclk;
#endif
@@ -488,9 +491,9 @@ static int aty_init_pll_ct(const struct fb_info *info,
union aty_pll *pll)
/* Allow BIOS to override */
dsp_config = aty_ld_le32(DSP_CONFIG, par);
- dsp_on_off = aty_ld_le32(DSP_ON_OFF, par);
- vga_dsp_config = aty_ld_le32(VGA_DSP_CONFIG, par);
- vga_dsp_on_off = aty_ld_le32(VGA_DSP_ON_OFF, par);
+ aty_ld_le32(DSP_ON_OFF, par);
+ aty_ld_le32(VGA_DSP_CONFIG, par);
+ aty_ld_le32(VGA_DSP_ON_OFF, par);
if (dsp_config)
pll->ct.dsp_loop_latency = (dsp_config & DSP_LOOP_LATENCY) >>
16;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 006/162] drm/i915: split gen8+ flush and bb_start emission functions to their own file
Quoting Matthew Auld (2020-11-27 12:04:42) > From: Daniele Ceraolo Spurio > > These functions are independent from the backend used and can therefore > be split out of the exelists submission file, so they can be re-used by > the upcoming GuC submission backend. > > Based on a patch by Chris Wilson. > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Chris P Wilson > Cc: Tvrtko Ursulin > Reviewed-by: John Harrison > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 393 ++ > drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 26 ++ > .../drm/i915/gt/intel_execlists_submission.c | 385 + > 4 files changed, 421 insertions(+), 384 deletions(-) > create mode 100644 drivers/gpu/drm/i915/gt/gen8_engine_cs.c > create mode 100644 drivers/gpu/drm/i915/gt/gen8_engine_cs.h > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index aedbd8f52be8..f9ef5199b124 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -82,6 +82,7 @@ gt-y += \ > gt/gen6_engine_cs.o \ > gt/gen6_ppgtt.o \ > gt/gen7_renderclear.o \ > + gt/gen8_engine_cs.o \ > gt/gen8_ppgtt.o \ > gt/intel_breadcrumbs.o \ > gt/intel_context.o \ > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > new file mode 100644 > index ..a96fe108685e > --- /dev/null > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c > @@ -0,0 +1,393 @@ > +// SPDX-License-Identifier: MIT > +/* > + * Copyright © 2014 Intel Corporation > + */ > + > +#include "i915_drv.h" > +#include "intel_execlists_submission.h" /* XXX */ > +#include "intel_gpu_commands.h" > +#include "intel_ring.h" > + > +int gen8_emit_flush_render(struct i915_request *request, u32 mode) Refresh the names to make the recent schemes. (rcs when specific, xcs when not) -Chris - Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 05/28] video: fbdev: aty: Fix W=1 warnings in atyfb_base
Fix W=1 warnings about variables assigned but never used.
- Drop variables that was never used
- Avoid using a local variable by moving the expression to an if
condition
Signed-off-by: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Joe Perches
Cc: Vaibhav Gupta
Cc: Jason Yan
Cc: Randy Dunlap
Cc: Jani Nikula
---
drivers/video/fbdev/aty/atyfb_base.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/aty/atyfb_base.c
b/drivers/video/fbdev/aty/atyfb_base.c
index c8feff0ee8da..d1eb9218debb 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -2360,22 +2360,20 @@ static int aty_init(struct fb_info *info)
#ifdef CONFIG_FB_ATY_GX
if (!M64_HAS(INTEGRATED)) {
u32 stat0;
- u8 dac_type, dac_subtype, clk_type;
+ u8 dac_subtype, clk_type;
stat0 = aty_ld_le32(CNFG_STAT0, par);
par->bus_type = (stat0 >> 0) & 0x07;
par->ram_type = (stat0 >> 3) & 0x07;
ramname = aty_gx_ram[par->ram_type];
/* FIXME: clockchip/RAMDAC probing? */
- dac_type = (aty_ld_le32(DAC_CNTL, par) >> 16) & 0x07;
+ aty_ld_le32(DAC_CNTL, par);
#ifdef CONFIG_ATARI
clk_type = CLK_ATI18818_1;
- dac_type = (stat0 >> 9) & 0x07;
- if (dac_type == 0x07)
+ if (((stat0 >> 9) & 0x07) == 0x07)
dac_subtype = DAC_ATT20C408;
else
dac_subtype = (aty_ld_8(SCRATCH_REG1 + 1, par) & 0xF0)
| dac_type;
#else
- dac_type = DAC_IBMRGB514;
dac_subtype = DAC_IBMRGB514;
clk_type = CLK_IBMRGB514;
#endif
@@ -3062,7 +3060,6 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct
fb_info *info,
if (dp == of_console_device) {
struct fb_var_screeninfo *var = _var;
unsigned int N, P, Q, M, T, R;
- u32 v_total, h_total;
struct crtc crtc;
u8 pll_regs[16];
u8 clock_cntl;
@@ -3078,9 +3075,6 @@ static int atyfb_setup_sparc(struct pci_dev *pdev, struct
fb_info *info,
crtc.gen_cntl = aty_ld_le32(CRTC_GEN_CNTL, par);
aty_crtc_to_var(, var);
- h_total = var->xres + var->right_margin + var->hsync_len +
var->left_margin;
- v_total = var->yres + var->lower_margin + var->vsync_len +
var->upper_margin;
-
/*
* Read the PLL to figure actual Refresh Rate.
*/
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 04/28] video: fbdev: aty: Delete unused variable in radeon_monitor
Fix W=1 about variable that is asssigned a value but never used.
The variable was indeed never used so delete it.
Keep the call to radeon_probe_i2c_connector() as it may have
side-effects. It is unlikely but I could not verify that is was safe to
drop the call.
Signed-off-by: Sam Ravnborg
Cc: Benjamin Herrenschmidt
Cc: linux-fb...@vger.kernel.org
---
drivers/video/fbdev/aty/radeon_monitor.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_monitor.c
b/drivers/video/fbdev/aty/radeon_monitor.c
index 9966c58aa26c..df55e23b7a5a 100644
--- a/drivers/video/fbdev/aty/radeon_monitor.c
+++ b/drivers/video/fbdev/aty/radeon_monitor.c
@@ -488,12 +488,10 @@ void radeon_probe_screens(struct radeonfb_info *rinfo,
#if defined(DEBUG) && defined(CONFIG_FB_RADEON_I2C)
{
u8 *EDIDs[4] = { NULL, NULL, NULL, NULL };
- int mon_types[4] = {MT_NONE, MT_NONE, MT_NONE, MT_NONE};
int i;
for (i = 0; i < 4; i++)
- mon_types[i] = radeon_probe_i2c_connector(rinfo,
- i+1,
[i]);
+ radeon_probe_i2c_connector(rinfo, i + 1,
[i]);
}
#endif /* DEBUG */
/*
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 03/28] video: fbdev: core: Fix W=1 warnings in fbmon + fb_notify
Fix W=1 warnings by updating kernel-doc to follow the correct syntax.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Randy Dunlap
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Alexander A. Klimov"
---
drivers/video/fbdev/core/fb_notify.c | 3 ++-
drivers/video/fbdev/core/fbmon.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fb_notify.c
b/drivers/video/fbdev/core/fb_notify.c
index 74c2da528884..d85717b6e14a 100644
--- a/drivers/video/fbdev/core/fb_notify.c
+++ b/drivers/video/fbdev/core/fb_notify.c
@@ -38,7 +38,8 @@ EXPORT_SYMBOL(fb_unregister_client);
/**
* fb_notifier_call_chain - notify clients of fb_events
- *
+ * @val: value passed to callback
+ * @v: pointer passed to callback
*/
int fb_notifier_call_chain(unsigned long val, void *v)
{
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 1bf82dbc9e3c..b0e690f41025 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -605,6 +605,7 @@ static void get_detailed_timing(unsigned char *block,
* fb_create_modedb - create video mode database
* @edid: EDID data
* @dbsize: database size
+ * @specs: monitor specifications, may be NULL
*
* RETURNS: struct fb_videomode, @dbsize contains length of database
*
@@ -1100,7 +1101,6 @@ static u32 fb_get_hblank_by_hfreq(u32 hfreq, u32 xres)
*2 * M
*M = 300;
*C = 30;
-
*/
static u32 fb_get_hblank_by_dclk(u32 dclk, u32 xres)
{
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 02/28] video: fbcon: Use pr_debug() in fbcon
Replacing DPRINTK() statements with pr_debug fixes
W=1 warnings.
And moves to a more standard logging setup at the same time.
Signed-off-by: Sam Ravnborg
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Cc: Jiri Slaby
Cc: Peilin Ye
Cc: Tetsuo Handa
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
---
drivers/video/fbdev/core/fbcon.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bf61598bf1c3..2edf90f638f3 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -56,8 +56,6 @@
* more details.
*/
-#undef FBCONDEBUG
-
#include
#include
#include
@@ -82,12 +80,6 @@
#include "fbcon.h"
-#ifdef FBCONDEBUG
-# define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __func__ , ##
args)
-#else
-# define DPRINTK(fmt, args...)
-#endif
-
/*
* FIXME: Locking
*
@@ -1015,9 +1007,9 @@ static const char *fbcon_startup(void)
rows /= vc->vc_font.height;
vc_resize(vc, cols, rows);
- DPRINTK("mode: %s\n", info->fix.id);
- DPRINTK("visual: %d\n", info->fix.visual);
- DPRINTK("res:%dx%d-%d\n", info->var.xres,
+ pr_debug("mode: %s\n", info->fix.id);
+ pr_debug("visual: %d\n", info->fix.visual);
+ pr_debug("res:%dx%d-%d\n", info->var.xres,
info->var.yres,
info->var.bits_per_pixel);
@@ -2013,7 +2005,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int
width,
y_diff < 0 || y_diff > virt_fh) {
const struct fb_videomode *mode;
- DPRINTK("attempting resize %ix%i\n", var.xres, var.yres);
+ pr_debug("attempting resize %ix%i\n", var.xres, var.yres);
mode = fb_find_best_mode(, >modelist);
if (mode == NULL)
return -EINVAL;
@@ -2023,7 +2015,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int
width,
if (virt_w > var.xres/virt_fw || virt_h > var.yres/virt_fh)
return -EINVAL;
- DPRINTK("resize now %ix%i\n", var.xres, var.yres);
+ pr_debug("resize now %ix%i\n", var.xres, var.yres);
if (con_is_visible(vc)) {
var.activate = FB_ACTIVATE_NOW |
FB_ACTIVATE_FORCE;
@@ -3299,7 +3291,7 @@ static void fbcon_exit(void)
if (info->queue.func)
pending = cancel_work_sync(>queue);
- DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
+ pr_debug("fbcon: %s pending work\n", (pending ? "canceled" :
"no"));
for (j = first_fb_vc; j <= last_fb_vc; j++) {
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 01/28] video: Fix W=1 warnings in of_videomode + of_display_timing
Fix trivial W=1 warnings. Update kernel-doc to avoid the warnings. Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: linux-fb...@vger.kernel.org --- drivers/video/of_display_timing.c | 1 + drivers/video/of_videomode.c | 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c index abc9ada798ee..f93b6abbe258 100644 --- a/drivers/video/of_display_timing.c +++ b/drivers/video/of_display_timing.c @@ -52,6 +52,7 @@ static int parse_timing_property(const struct device_node *np, const char *name, /** * of_parse_display_timing - parse display_timing entry from device_node * @np: device_node with the properties + * @dt: display_timing that contains the result. I may be partially written in case of errors **/ static int of_parse_display_timing(const struct device_node *np, struct display_timing *dt) diff --git a/drivers/video/of_videomode.c b/drivers/video/of_videomode.c index 67aff2421c29..a5bb02f02b44 100644 --- a/drivers/video/of_videomode.c +++ b/drivers/video/of_videomode.c @@ -13,10 +13,10 @@ #include /** - * of_get_videomode - get the videomode # from devicetree - * @np - devicenode with the display_timings - * @vm - set to return value - * @index - index into list of display_timings + * of_get_videomode: get the videomode # from devicetree + * @np: devicenode with the display_timings + * @vm: set to return value + * @index: index into list of display_timings * (Set this to OF_USE_NATIVE_MODE to use whatever mode is * specified as native mode in the DT.) * -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/28] drivers/video: W=1 warning fixes
Following the great work of Lee Jones in other subsystems here is a set of patches that address all remaining W=1 warnings in drivers/video/. Lee Jones already fixed all warnings in video/backlight/ so this is mostly fbdev related fixes. The general approach used were: - Fix kernel-doc, this is often very trivial - Drop unused local variables - Use no_printk for local logging support Build tested on a set of architectures with various configs. The patches do not depends on each other and in most cases all fixes for one driver is kept in a single patch. The individual changes are trivial so this is a great starter task to try to review these patches. A timely Reviewed-by: or Acked-by: would be very nice so we can get the warnings fixes before we cut for the merge window. Sam Sam Ravnborg (28): video: Fix W=1 warnings in of_videomode + of_display_timing video: fbcon: Use pr_debug() in fbcon video: fbdev: core: Fix W=1 warnings in fbmon + fb_notify video: fbdev: aty: Delete unused variable in radeon_monitor video: fbdev: aty: Fix W=1 warnings in atyfb_base video: fbdev: aty: Fix W=1 warnings in mach64_ct video: fbdev: sis: Fix W=1 warnings about static symbols video: fbdev: sis: Fix W=1 warning about SiS_TVDelay video: fbdev: sis: Fix W=1 warnings in init.c video: fbdev: sis: Fix W=1 warnings in sis_main video: fbdev: via: Fix W=1 warnings video: fbdev: tdfx: Fix W=1 warnings video: fbdev: riva: Fix W=1 warnings video: fbdev: pm2fb: Fix W=1 warnings video: fbdev: neofb: Fix W=1 warnings video: fbdev: hgafb: Fix W=1 warnings video: fbdev: tgafb: Fix W=1 warnings video: fbdev: mx3fb: Fix W=1 warnings video: fbdev: sstfb: Fix W=1 warnings video: fbdev: nvidia: Fix W=1 warnings video: fbdev: tmiofb: Fix W=1 warnings video: fbdev: omapfb: Fix W=1 warnings in dsi video: fbdev: omapfb: Fix W=1 warnings in hdmi*_core video: fbdev: s3c-fb: Fix W=1 warnings video: fbdev: uvesafb: Fix W=1 warning video: fbdev: uvesafb: Fix W=1 string related warnings video: fbdev: cirrusfb: Fix W=1 warnings video: fbdev: s1d13xxxfb: Fix W=1 warnings drivers/video/fbdev/aty/atyfb_base.c | 12 ++-- drivers/video/fbdev/aty/mach64_ct.c | 15 ++ drivers/video/fbdev/aty/radeon_monitor.c | 4 +-- drivers/video/fbdev/cirrusfb.c| 20 ++--- drivers/video/fbdev/core/fb_notify.c | 3 +- drivers/video/fbdev/core/fbcon.c | 20 - drivers/video/fbdev/core/fbmon.c | 2 +- drivers/video/fbdev/hgafb.c | 4 +-- drivers/video/fbdev/mx3fb.c | 13 + drivers/video/fbdev/neofb.c | 4 --- drivers/video/fbdev/nvidia/nv_setup.c | 7 ++--- drivers/video/fbdev/omap2/omapfb/dss/dsi.c| 12 ++-- drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 4 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 4 +-- drivers/video/fbdev/pm2fb.c | 8 +++--- drivers/video/fbdev/riva/fbdev.c | 9 +++--- drivers/video/fbdev/riva/riva_hw.c| 28 ++- drivers/video/fbdev/s1d13xxxfb.c | 3 +- drivers/video/fbdev/s3c-fb.c | 11 drivers/video/fbdev/sis/init.c| 34 --- drivers/video/fbdev/sis/oem310.h | 2 ++ drivers/video/fbdev/sis/sis.h | 1 - drivers/video/fbdev/sis/sis_main.c| 9 +++--- drivers/video/fbdev/sstfb.c | 2 +- drivers/video/fbdev/tdfxfb.c | 4 +-- drivers/video/fbdev/tgafb.c | 7 ++--- drivers/video/fbdev/tmiofb.c | 6 ++-- drivers/video/fbdev/uvesafb.c | 8 +++--- drivers/video/fbdev/via/lcd.c | 4 +-- drivers/video/of_display_timing.c | 1 + drivers/video/of_videomode.c | 8 +++--- include/video/sstfb.h | 4 +-- 32 files changed, 104 insertions(+), 169 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 005/162] drm/i915/gt: Rename lrc.c to execlists_submission.c
Quoting Matthew Auld (2020-11-27 12:04:41) > From: Chris Wilson > > We want to separate the utility functions for controlling the logical > ring context from the execlists submission mechanism (which is an > overgrown scheduler). > > This is similar to Daniele's work to split up the files, but being > selfish I wanted to base it after my own changes to intel_lrc.c petered > out. Note in accordance with recent intel_ring_submission.c vs intel_ring_scheduler.c, this would be intel_execlists_scheduler.c -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 004/162] drm/i915/gt: Move move context layout registers and offsets to lrc_reg.h
Quoting Matthew Auld (2020-11-27 12:04:40)
> From: Chris Wilson
>
> Cleanup intel_lrc.h by moving some of the residual common register
> definitions into intel_lrc_reg.h, prior to rebranding and splitting off
> the submission backends.
>
> v2: keep the SCHEDULE enum in the old file, since it is specific to the
> gvt usage of the execlists submission backend (John)
>
> Signed-off-by: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio #v2
> Cc: John Harrison
> Reviewed-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_irq.c| 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.h | 39 ---
> drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 39 +++
> drivers/gpu/drm/i915/gvt/mmio_context.h | 2 ++
> 5 files changed, 43 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index d4e988b2816a..02ea16b29c9f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -36,7 +36,7 @@
> #include "intel_gt.h"
> #include "intel_gt_requests.h"
> #include "intel_gt_pm.h"
> -#include "intel_lrc.h"
> +#include "intel_lrc_reg.h"
> #include "intel_reset.h"
> #include "intel_ring.h"
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index 257063a57101..9830342aa6f4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -11,6 +11,7 @@
> #include "intel_breadcrumbs.h"
> #include "intel_gt.h"
> #include "intel_gt_irq.h"
> +#include "intel_lrc_reg.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
> b/drivers/gpu/drm/i915/gt/intel_lrc.h
> index 802585a308e9..9116b46844a2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.h
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
> @@ -34,45 +34,6 @@ struct i915_request;
> struct intel_context;
> struct intel_engine_cs;
>
> -/* Execlists regs */
> -#define RING_ELSP(base)_MMIO((base) + 0x230)
> -#define RING_EXECLIST_STATUS_LO(base) _MMIO((base) + 0x234)
> -#define RING_EXECLIST_STATUS_HI(base) _MMIO((base) + 0x234 + 4)
> -#define RING_CONTEXT_CONTROL(base) _MMIO((base) + 0x244)
> -#define CTX_CTRL_INHIBIT_SYN_CTX_SWITCH (1 << 3)
> -#define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0)
> -#define CTX_CTRL_RS_CTX_ENABLE (1 << 1)
> -#define CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT (1 << 2)
> -#define GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE (1 << 8)
> -#define RING_CONTEXT_STATUS_PTR(base) _MMIO((base) + 0x3a0)
> -#define RING_EXECLIST_SQ_CONTENTS(base)_MMIO((base) + 0x510)
> -#define RING_EXECLIST_CONTROL(base)_MMIO((base) + 0x550)
> -
> -#define EL_CTRL_LOAD (1 << 0)
> -
> -/* The docs specify that the write pointer wraps around after 5h, "After
> status
> - * is written out to the last available status QW at offset 5h, this pointer
> - * wraps to 0."
> - *
> - * Therefore, one must infer than even though there are 3 bits available, 6
> and
> - * 7 appear to be * reserved.
> - */
> -#define GEN8_CSB_ENTRIES 6
> -#define GEN8_CSB_PTR_MASK 0x7
> -#define GEN8_CSB_READ_PTR_MASK (GEN8_CSB_PTR_MASK << 8)
> -#define GEN8_CSB_WRITE_PTR_MASK (GEN8_CSB_PTR_MASK << 0)
> -
> -#define GEN11_CSB_ENTRIES 12
> -#define GEN11_CSB_PTR_MASK 0xf
> -#define GEN11_CSB_READ_PTR_MASK (GEN11_CSB_PTR_MASK << 8)
> -#define GEN11_CSB_WRITE_PTR_MASK (GEN11_CSB_PTR_MASK << 0)
> -
> -#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
> -#define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
> -#define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
> -/* in Gen12 ID 0x7FF is reserved to indicate idle */
> -#define GEN12_MAX_CONTEXT_HW_ID(GEN11_MAX_CONTEXT_HW_ID - 1)
> -
> enum {
> INTEL_CONTEXT_SCHEDULE_IN = 0,
> INTEL_CONTEXT_SCHEDULE_OUT,
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> index 1b51f7b9a5c3..b2e03ce35599 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
> @@ -52,4 +52,43 @@
> #define GEN8_EXECLISTS_STATUS_BUF 0x370
> #define GEN11_EXECLISTS_STATUS_BUF2 0x3c0
>
> +/* Execlists regs */
> +#define RING_ELSP(base)_MMIO((base) + 0x230)
> +#define RING_EXECLIST_STATUS_LO(base) _MMIO((base) + 0x234)
> +#define RING_EXECLIST_STATUS_HI(base) _MMIO((base) + 0x234 + 4)
> +#define RING_CONTEXT_CONTROL(base) _MMIO((base) + 0x244)
> +#define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT REG_BIT(0)
> +#define CTX_CTRL_RS_CTX_ENABLE REG_BIT(1)
> +#define CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT
Re: [RFC PATCH 001/162] drm/i915/selftest: also consider non-contiguous objects
Quoting Matthew Auld (2020-11-27 12:04:37) > In igt_ppgtt_sanity_check we should also exercise the non-contiguous > option for LMEM, since this will give us slightly different sg layouts > and alignment. > > Signed-off-by: Matthew Auld Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: remove trailing semicolon in macro definition
Quoting t...@redhat.com (2020-11-27 16:28:28) > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix > --- > drivers/gpu/drm/i915/intel_device_info.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c > b/drivers/gpu/drm/i915/intel_device_info.c > index e67cec8fa2aa..ef767f04c37c 100644 > --- a/drivers/gpu/drm/i915/intel_device_info.c > +++ b/drivers/gpu/drm/i915/intel_device_info.c > @@ -104,7 +104,7 @@ void intel_device_info_print_static(const struct > intel_device_info *info, > drm_printf(p, "ppgtt-type: %d\n", info->ppgtt_type); > drm_printf(p, "dma_mask_size: %u\n", info->dma_mask_size); > > -#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name)); > +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name)) > DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG); I thought that this was a macro that avoided adding the ';' to each invocation. Perhaps another time. Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 092/162] drm/i915/uapi: introduce drm_i915_gem_create_ext
Quoting Matthew Auld (2020-11-27 12:06:08)
> +int
> +i915_gem_create_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct create_ext ext_data = { .i915 = i915 };
> + struct drm_i915_gem_create_ext *args = data;
> + int ret;
> +
> + i915_gem_flush_free_objects(i915);
> +
> + ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
> + create_extensions,
> + ARRAY_SIZE(create_extensions),
> + _data);
> + if (ret)
> + goto err_free;
> +
> + if (!ext_data.placements) {
> + struct intel_memory_region **placements;
> + enum intel_memory_type mem_type = INTEL_MEMORY_SYSTEM;
> +
> + placements = kmalloc(sizeof(struct intel_memory_region *),
> +GFP_KERNEL);
> + if (!placements)
> + return -ENOMEM;
> +
> + placements[0] = intel_memory_region_by_type(i915, mem_type);
> +
> + ext_data.placements = placements;
> + ext_data.n_placements = 1;
> + }
> +
> + ret = i915_gem_create(file,
> + ext_data.placements,
> + ext_data.n_placements,
> + >size, >handle);
> + if (!ret)
> + return 0;
Applying the extensions has to happen after creating the vanilla object.
It literally is the equivalent of applying the setparam ioctl to a fresh
object.
Look at the PXP series for how badly wrong this goes if you try it this
way around.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn
Hi Daniel, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on char-misc/char-misc-testing v5.10-rc5] [cannot apply to hnaz-linux-mm/master next-20201127] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 base: git://linuxtv.org/media_tree.git master config: s390-randconfig-r032-20201127 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project f095ac11a9550530a4a54298debb8b04b36422be) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://github.com/0day-ci/linux/commit/d76a3489433ce67d45da86aa12953385427f0ac9 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Daniel-Vetter/follow_pfn-and-other-iomap-races/20201128-004421 git checkout d76a3489433ce67d45da86aa12953385427f0ac9 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:10: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:80: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:21:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0x00ffUL) >> 8) |\ ^ In file included from arch/s390/kvm/../../../virt/kvm/kvm_main.c:18: In file included from include/linux/kvm_host.h:32: In file included from include/linux/kvm_para.h:5: In file included from include/uapi/linux/kvm_para.h:36: In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:10: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/include/asm/io.h:80: include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); ~~ ^ include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro '__le32_to_cpu' #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) ^ include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32' ___constant_swab32(x) : \ ^ include/uapi/linux/swab.h:22:12: note: expanded from macro '___constant_swab32' (((__u32)(x) & (__u32)0xff00UL) >> 24))) ^ In file included from arch/s390/kvm/../../../virt/kvm/kvm_main.c:18: In file included from include/linux/kvm_host.h:32: In file included from include/linux/kvm_para.h:5: In file included from include/uapi/linux/kvm_para.h:36: In file included from arch/s390/include/asm/kvm_para.h:25: In file included from arch/s390/include/asm/diag.h:12: In file included from include/linux/if_ether.h:19: In file included from include/linux/skbuff.h:31: In file included from include/linux/dma-mapping.h:10: In file included from include/linux/scatterlist.h:9: In file included from arch/s390/inclu
[PATCH] omapfb: fbcon: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c index 3417618310ff..cc2ad787d493 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc-compat.c @@ -75,7 +75,7 @@ static void dispc_dump_irqs(struct seq_file *s) seq_printf(s, "irqs %d\n", stats.irq_count); #define PIS(x) \ - seq_printf(s, "%-20s %10d\n", #x, stats.irqs[ffs(DISPC_IRQ_##x)-1]); + seq_printf(s, "%-20s %10d\n", #x, stats.irqs[ffs(DISPC_IRQ_##x)-1]) PIS(FRAMEDONE); PIS(VSYNC); diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c index 6f9c25fec994..101fa66f9b58 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c @@ -1554,7 +1554,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device *dsidev, seq_printf(s, "irqs %d\n", stats.irq_count); #define PIS(x) \ - seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]); + seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]) seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1); PIS(VC0); -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/kms: handle mDP connectors
In some cases we have the handle those explicitly as the fallback
connector type detection fails and marks those as eDP connectors.
Attempting to use such a connector with mutter leads to a crash of mutter
as it ends up with two eDP displays.
Information is taken from the official DCB documentation.
Cc: sta...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
Reported-by: Mark Pearson
Tested-by: Mark Pearson
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
index f5f59261ea81..d1beaad0c82b 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/bios/conn.h
@@ -14,6 +14,7 @@ enum dcb_connector_type {
DCB_CONNECTOR_LVDS_SPWG = 0x41,
DCB_CONNECTOR_DP = 0x46,
DCB_CONNECTOR_eDP = 0x47,
+ DCB_CONNECTOR_mDP = 0x48,
DCB_CONNECTOR_HDMI_0 = 0x60,
DCB_CONNECTOR_HDMI_1 = 0x61,
DCB_CONNECTOR_HDMI_C = 0x63,
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8b4b3688c7ae..4c992fd5bd68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1210,6 +1210,7 @@ drm_conntype_from_dcb(enum dcb_connector_type dcb)
case DCB_CONNECTOR_DMS59_DP0:
case DCB_CONNECTOR_DMS59_DP1:
case DCB_CONNECTOR_DP :
+ case DCB_CONNECTOR_mDP :
case DCB_CONNECTOR_USB_C: return DRM_MODE_CONNECTOR_DisplayPort;
case DCB_CONNECTOR_eDP : return DRM_MODE_CONNECTOR_eDP;
case DCB_CONNECTOR_HDMI_0 :
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
On Fri, Nov 27, 2020 at 04:19:20PM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> > Hi Daniel, Jani,
> >
> > is it ok to merge this patch along with 2/2 via the i915 tree?
>
> Ack from mesa (userspace in general, but mesa is kinda mandatory) is
> missing I think. With that
> Acked-by: Daniel Vetter
Thanks.
Nanley, could you ACK the patchset if they look ok from Mesa's POV? It
works as expected at least with the igt/kms_ccs RC-CC subtest.
--Imre
> > On Mon, Nov 23, 2020 at 08:26:30PM +0200, Imre Deak wrote:
> > > From: Radhakrishna Sripada
> > >
> > > Gen12 display can decompress surfaces compressed by render engine with
> > > Clear Color, add a new modifier as the driver needs to know the surface
> > > was compressed by render engine.
> > >
> > > V2: Description changes as suggested by Rafael.
> > > V3: Mention the Clear Color size of 64 bits in the comments(DK)
> > > v4: Fix trailing whitespaces
> > > v5: Explain Clear Color in the documentation.
> > > v6: Documentation Nitpicks(Nanley)
> > >
> > > Cc: Ville Syrjala
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Kalyan Kondapally
> > > Cc: Rafael Antognolli
> > > Cc: Nanley Chery
> > > Signed-off-by: Radhakrishna Sripada
> > > Signed-off-by: Imre Deak
> > > ---
> > > include/uapi/drm/drm_fourcc.h | 19 +++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index ca48ed0e6bc1..0a1b2c4c4bee 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -527,6 +527,25 @@ extern "C" {
> > > */
> > > #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
> > >
> > > +/*
> > > + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> > > + * compression.
> > > + *
> > > + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
> > > linear
> > > + * and at index 1. The clear color is stored at index 2, and the pitch
> > > should
> > > + * be ignored. The clear color structure is 256 bits. The first 128 bits
> > > + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> > > represented
> > > + * by 32 bits. The raw clear color is consumed by the 3d engine and
> > > generates
> > > + * the converted clear color of size 64 bits. The first 32 bits store
> > > the Lower
> > > + * Converted Clear Color value and the next 32 bits store the Higher
> > > Converted
> > > + * Clear Color value when applicable. The Converted Clear Color values
> > > are
> > > + * consumed by the DE. The last 64 bits are used to store Color Discard
> > > Enable
> > > + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache
> > > line
> > > + * corresponds to an area of 4x1 tiles in the main surface. The main
> > > surface
> > > + * pitch is required to be a multiple of 4 tile widths.
> > > + */
> > > +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> > > +
> > > /*
> > > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> > > *
> > > --
> > > 2.25.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > 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
[PATCH v7 15/17] vfio/type1: Mark follow_pfn as unsafe
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Alex Williamson
Cc: Cornelia Huck
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/vfio/vfio_iommu_type1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 67e827638995..10170723bb58 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -421,7 +421,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
{
int ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
if (ret) {
bool unlocked = false;
@@ -435,7 +435,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
if (ret)
return ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
}
return ret;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 16/17] kvm: pass kvm argument to follow_pfn callsites
Both Christoph Hellwig and Jason Gunthorpe suggested that usage of
follow_pfn by modules should be locked down more. To do so callers
need to be able to pass the mmu_notifier subscription corresponding
to the mm_struct to follow_pfn().
This patch does the rote work of doing that in the kvm subsystem. In
most places this is solved by passing struct kvm * down the call
stacks as an additional parameter, since that contains the
mmu_notifier.
Compile tested on all affected arch.
Acked-by: Paolo Bonzini
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
arch/powerpc/kvm/book3s_64_mmu_hv.c| 2 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
arch/powerpc/kvm/e500_mmu_host.c | 2 +-
arch/x86/kvm/mmu/mmu.c | 8 ++--
include/linux/kvm_host.h | 9 +++--
virt/kvm/kvm_main.c| 52 +++---
6 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 38ea396a23d6..86781ff76fcb 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -589,7 +589,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_vcpu *vcpu,
write_ok = true;
} else {
/* Call KVM generic code to do the slow-path check */
- pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL,
+ pfn = __gfn_to_pfn_memslot(kvm, memslot, gfn, false, NULL,
writing, _ok);
if (is_error_noslot_pfn(pfn))
return -EFAULT;
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c
b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index bb35490400e9..319a1a99153f 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -821,7 +821,7 @@ int kvmppc_book3s_instantiate_page(struct kvm_vcpu *vcpu,
unsigned long pfn;
/* Call KVM generic code to do the slow-path check */
- pfn = __gfn_to_pfn_memslot(memslot, gfn, false, NULL,
+ pfn = __gfn_to_pfn_memslot(kvm, memslot, gfn, false, NULL,
writing, upgrade_p);
if (is_error_noslot_pfn(pfn))
return -EFAULT;
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index ed0c9c43d0cf..fd2b2d363559 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -446,7 +446,7 @@ static inline int kvmppc_e500_shadow_map(struct
kvmppc_vcpu_e500 *vcpu_e500,
if (likely(!pfnmap)) {
tsize_pages = 1UL << (tsize + 10 - PAGE_SHIFT);
- pfn = gfn_to_pfn_memslot(slot, gfn);
+ pfn = gfn_to_pfn_memslot(kvm, slot, gfn);
if (is_error_noslot_pfn(pfn)) {
if (printk_ratelimit())
pr_err("%s: real page not found for gfn %lx\n",
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 5bb1939b65d8..67ada47aa722 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2679,7 +2679,7 @@ static kvm_pfn_t pte_prefetch_gfn_to_pfn(struct kvm_vcpu
*vcpu, gfn_t gfn,
if (!slot)
return KVM_PFN_ERR_FAULT;
- return gfn_to_pfn_memslot_atomic(slot, gfn);
+ return gfn_to_pfn_memslot_atomic(vcpu->kvm, slot, gfn);
}
static int direct_pte_prefetch_many(struct kvm_vcpu *vcpu,
@@ -3657,7 +3657,8 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool
prefault, gfn_t gfn,
}
async = false;
- *pfn = __gfn_to_pfn_memslot(slot, gfn, false, , write, writable);
+ *pfn = __gfn_to_pfn_memslot(vcpu->kvm, slot, gfn,
+ false, , write, writable);
if (!async)
return false; /* *pfn has correct page already */
@@ -3671,7 +3672,8 @@ static bool try_async_pf(struct kvm_vcpu *vcpu, bool
prefault, gfn_t gfn,
return true;
}
- *pfn = __gfn_to_pfn_memslot(slot, gfn, false, NULL, write, writable);
+ *pfn = __gfn_to_pfn_memslot(vcpu->kvm, slot, gfn,
+ false, NULL, write, writable);
return false;
}
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 7f2e2a09ebbd..864424ce6b6b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -717,9 +717,12 @@ void kvm_set_page_accessed(struct page *page);
kvm_pfn_t gfn_to_pfn(struct kvm *kvm, gfn_t gfn);
kvm_pfn_t gfn_to_pfn_prot(struct kvm *kvm, gfn_t gfn, bool write_fault,
[PATCH v7 17/17] mm: add mmu_notifier argument to follow_pfn
The only safe way for non core/arch code to use follow_pfn() is
together with an mmu_notifier subscription. follow_pfn() is already
marked as _GPL and the kerneldoc explains this restriction.
This patch here enforces all this by adding a mmu_notifier argument
and verifying that it is registered for the correct mm_struct.
Motivated by discussions with Christoph Hellwig and Jason Gunthorpe.
Since requiring an mmu_notifier makes it very clear that follow_pfn()
cannot be used on !CONFIG_MMU hardware, remove it from there. The sole
user kvm not existing on such hardware also supports that.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v7: Comments from Jason:
- ditch follow_pfn from nommu.c
- simplify mmu_notifer->mm check
---
include/linux/mm.h | 3 ++-
mm/memory.c | 38 --
mm/nommu.c | 27 +--
virt/kvm/kvm_main.c | 4 ++--
4 files changed, 33 insertions(+), 39 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index bb3e926afd91..2a564bfd818c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1651,6 +1651,7 @@ void unmap_vmas(struct mmu_gather *tlb, struct
vm_area_struct *start_vma,
unsigned long start, unsigned long end);
struct mmu_notifier_range;
+struct mmu_notifier;
void free_pgd_range(struct mmu_gather *tlb, unsigned long addr,
unsigned long end, unsigned long floor, unsigned long ceiling);
@@ -1660,7 +1661,7 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
address,
struct mmu_notifier_range *range,
pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
- unsigned long *pfn);
+ unsigned long *pfn, struct mmu_notifier *subscription);
int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
diff --git a/mm/memory.c b/mm/memory.c
index 0db0c5e233fd..a27b9b9c22c2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4789,11 +4789,30 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
address,
}
EXPORT_SYMBOL(follow_pte_pmd);
+static int __follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ int ret = -EINVAL;
+ spinlock_t *ptl;
+ pte_t *ptep;
+
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ return ret;
+
+ ret = follow_pte(vma->vm_mm, address, , );
+ if (ret)
+ return ret;
+ *pfn = pte_pfn(*ptep);
+ pte_unmap_unlock(ptep, ptl);
+ return 0;
+}
+
/**
* follow_pfn - look up PFN at a user virtual address
* @vma: memory mapping
* @address: user virtual address
* @pfn: location to store found PFN
+ * @subscription: mmu_notifier subscription for the mm @vma is part of
*
* Only IO mappings and raw PFN mappings are allowed. Note that callers must
* ensure coherency with pte updates by using a _notifier to follow
updates.
@@ -4805,21 +4824,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
* Return: zero and the pfn at @pfn on success, -ve otherwise.
*/
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
- unsigned long *pfn)
+ unsigned long *pfn, struct mmu_notifier *subscription)
{
- int ret = -EINVAL;
- spinlock_t *ptl;
- pte_t *ptep;
-
- if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
- return ret;
+ if (WARN_ON(subscription->mm != vma->vm_mm))
+ return -EINVAL;
- ret = follow_pte(vma->vm_mm, address, , );
- if (ret)
- return ret;
- *pfn = pte_pfn(*ptep);
- pte_unmap_unlock(ptep, ptl);
- return 0;
+ return __follow_pfn(vma, address, pfn);
}
EXPORT_SYMBOL_GPL(follow_pfn);
@@ -4844,7 +4854,7 @@ int unsafe_follow_pfn(struct vm_area_struct *vma,
unsigned long address,
WARN_ONCE(1, "unsafe follow_pfn usage\n");
add_taint(TAINT_USER, LOCKDEP_STILL_OK);
- return follow_pfn(vma, address, pfn);
+ return __follow_pfn(vma, address, pfn);
}
EXPORT_SYMBOL(unsafe_follow_pfn);
diff --git a/mm/nommu.c b/mm/nommu.c
index 79fc98a6c94a..a1e178401146 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -111,27 +111,6 @@ unsigned int kobjsize(const void *objp)
return page_size(page);
}
-/**
- * follow_pfn - look up PFN at a user virtual address
- * @vma: memory mapping
- * @address: user virtual address
- * @pfn: location to store found PFN
- *
- * Only IO mappings and raw PFN mappings
[PATCH v7 14/17] media/videobuf1|2: Mark follow_pfn usage as unsafe
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").
Acked-by: Tomasz Figa
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
Signed-off-by: Daniel Vetter
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
make it abundandtly clear that this patch only affects that, and not
normal memory userptr. The old commit message already explained that
normal memory userptr is unaffected, but I guess that was not clear
enough.
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/frame_vector.c
b/drivers/media/common/videobuf2/frame_vector.c
index a0e65481a201..1a82ec13ea00 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -70,7 +70,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
break;
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
- err = follow_pfn(vma, start, [ret]);
+ err = unsafe_follow_pfn(vma, start, [ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
- ret = follow_pfn(vma, user_address, _pfn);
+ ret = unsafe_follow_pfn(vma, user_address, _pfn);
if (ret)
break;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 03/17] misc/habana: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Reviewed-by: John Hubbard
Reviewed-by: Oded Gabbay
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
Signed-off-by: Daniel Vetter
--
v2: Use unpin_user_pages_dirty_lock (John)
v3: Update kerneldoc (Oded)
v6: Explain why pup_fast is safe, after discussions with John and
Christoph.
v7: Remove error message for kmalloc failures, habanalabs doesn't do
that (Oded)
---
drivers/misc/habanalabs/Kconfig | 1 -
drivers/misc/habanalabs/common/habanalabs.h | 6 ++-
drivers/misc/habanalabs/common/memory.c | 51 -
3 files changed, 22 insertions(+), 36 deletions(-)
diff --git a/drivers/misc/habanalabs/Kconfig b/drivers/misc/habanalabs/Kconfig
index 1640340d3e62..293d79811372 100644
--- a/drivers/misc/habanalabs/Kconfig
+++ b/drivers/misc/habanalabs/Kconfig
@@ -6,7 +6,6 @@
config HABANA_AI
tristate "HabanaAI accelerators (habanalabs)"
depends on PCI && HAS_IOMEM
- select FRAME_VECTOR
select GENERIC_ALLOCATOR
select HWMON
help
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index 6ed974d2def0..107442a20197 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -921,7 +921,8 @@ struct hl_ctx_mgr {
* struct hl_userptr - memory mapping chunk information
* @vm_type: type of the VM.
* @job_node: linked-list node for hanging the object on the Job's list.
- * @vec: pointer to the frame vector.
+ * @pages: pointer to struct page array
+ * @npages: size of @pages array
* @sgt: pointer to the scatter-gather table that holds the pages.
* @dir: for DMA unmapping, the direction must be supplied, so save it.
* @debugfs_list: node in debugfs list of command submissions.
@@ -932,7 +933,8 @@ struct hl_ctx_mgr {
struct hl_userptr {
enum vm_type_t vm_type; /* must be first */
struct list_headjob_node;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
enum dma_data_direction dir;
struct list_headdebugfs_list;
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 84227819e4d1..2c59fa869684 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1291,45 +1291,39 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
return -EFAULT;
}
- userptr->vec = frame_vector_create(npages);
- if (!userptr->vec) {
- dev_err(hdev->dev, "Failed to create frame vector\n");
+ userptr->pages = kvmalloc_array(npages, sizeof(*userptr->pages),
+ GFP_KERNEL);
+ if (!userptr->pages)
return -ENOMEM;
- }
- rc = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- userptr->vec);
+ rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+userptr->pages);
if (rc != npages) {
dev_err(hdev->dev,
"Failed to map host memory, user ptr probably wrong\n");
if (rc < 0)
- goto destroy_framevec;
- rc = -EFAULT;
- goto put_framevec;
- }
-
- if (frame_vector_to_pages(userptr->vec) < 0) {
- dev_err(hdev->dev,
- "Failed to translate frame vector to pages\n");
+ goto destroy_pages;
+ npages = rc;
rc = -EFAULT;
- goto put_framevec;
+ goto put_pages;
}
+ userptr->npages = npages;
rc = sg_alloc_table_from_pages(userptr->sgt,
- frame_vector_pages(userptr->vec),
- npages, offset, size, GFP_ATOMIC);
+ userptr->pages,
+ npages, offset, size, GFP_ATOMIC);
if
[PATCH v7 13/17] mm: Add unsafe_follow_pfn
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.
Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Also mark up follow_pfn as EXPORT_SYMBOL_GPL. The only safe way to use
that by drivers/modules is together with an mmu_notifier, and that's
all _GPL stuff.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v5: Suggestions from Christoph
- reindent for less weirdness
- use IS_ENABLED instead of #ifdef
- same checks for nommu, for consistency
- EXPORT_SYMBOL_GPL for follow_pfn.
- kerneldoc was already updated in previous versions to explain when
follow_pfn can be used safely
---
include/linux/mm.h | 2 ++
mm/memory.c| 34 --
mm/nommu.c | 27 ++-
security/Kconfig | 13 +
4 files changed, 73 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b50cbb33d0f3..bb3e926afd91 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1661,6 +1661,8 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
address,
pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index ac32039ce941..0db0c5e233fd 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4795,7 +4795,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
* @address: user virtual address
* @pfn: location to store found PFN
*
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a _notifier to follow
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
*
* Return: zero and the pfn at @pfn on success, -ve otherwise.
*/
@@ -4816,7 +4821,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
pte_unmap_unlock(ptep, ptl);
return 0;
}
-EXPORT_SYMBOL(follow_pfn);
+EXPORT_SYMBOL_GPL(follow_pfn);
+
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ if (IS_ENABLED(CONFIG_STRICT_FOLLOW_PFN)) {
+ pr_info("unsafe follow_pfn usage rejected, see
CONFIG_STRICT_FOLLOW_PFN\n");
+ return -EINVAL;
+ }
+
+ WARN_ONCE(1, "unsafe follow_pfn usage\n");
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+ return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
diff --git a/mm/nommu.c b/mm/nommu.c
index 0faf39b32cdb..79fc98a6c94a 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -130,7 +130,32 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
*pfn = address >> PAGE_SHIFT;
return 0;
}
[PATCH v7 12/17] PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and proc mmap
support. Let's plug that hole.
For revoke_devmem() to work we need to link our vma into the same
address_space, with consistent vma->vm_pgoff. ->pgoff is already
adjusted, because that's how (io_)remap_pfn_range works, but for the
mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
to adjust this at at ->open time:
- for sysfs this is easy, now that binary attributes support this. We
just set bin_attr->mapping when mmap is supported
- for procfs it's a bit more tricky, since procfs pci access has only
one file per device, and access to a specific resources first needs
to be set up with some ioctl calls. But mmap is only supported for
the same resources as sysfs exposes with mmap support, and otherwise
rejected, so we can set the mapping unconditionally at open time
without harm.
A special consideration is for arch_can_pci_mmap_io() - we need to
make sure that the ->f_mapping doesn't alias between ioport and iomem
space. There's only 2 ways in-tree to support mmap of ioports: generic
pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
architecture hand-rolling. Both approach support ioport mmap through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Acked-by: Bjorn Helgaas
Reviewed-by: Dan Williams
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2:
- Totally new approach: Adjust filp->f_mapping at open time. Note that
this now works on all architectures, not just those support
ARCH_GENERIC_PCI_MMAP_RESOURCE
---
drivers/pci/pci-sysfs.c | 4
drivers/pci/proc.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index d15c881e2e7e..3f1c31bc0b7c 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -929,6 +929,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_io);
error = device_create_bin_file(>dev, b->legacy_io);
if (error)
@@ -941,6 +942,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = 0600;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(>dev, b->legacy_mem);
if (error)
@@ -1156,6 +1158,8 @@ static int pci_create_attr(struct pci_dev *pdev, int num,
int write_combine)
res_attr->mmap = pci_mmap_resource_uc;
}
}
+ if (res_attr->mmap)
+ res_attr->mapping = iomem_get_mapping();
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = 0600;
res_attr->size = pci_resource_len(pdev, num);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 3a2f90beb4cb..9bab07302bbf 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct
file *file)
fpriv->write_combine = 0;
file->private_data = fpriv;
+ file->f_mapping = iomem_get_mapping();
return 0;
}
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 09/17] /dev/mem: Only set filp->f_mapping
When we care about pagecache maintenance, we need to make sure that both f_mapping and i_mapping point at the right mapping. But for iomem mappings we only care about the virtual/pte side of things, so f_mapping is enough. Also setting inode->i_mapping was confusing me as a driver maintainer, since in e.g. drivers/gpu we don't do that. Per Dan this seems to be copypasta from places which do care about pagecache consistency, but not needed. Hence remove it for slightly less confusion. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Reviewed-by: Dan Williams Signed-off-by: Daniel Vetter --- drivers/char/mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 94c2b556cf97..7dcf9e4ea79d 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -891,7 +891,6 @@ static int open_port(struct inode *inode, struct file *filp) * revocations when drivers want to take over a /dev/mem mapped * range. */ - inode->i_mapping = devmem_inode->i_mapping; filp->f_mapping = inode->i_mapping; return 0; -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 11/17] sysfs: Support zapping of binary attr mmaps
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings, so that unmap_mapping_range can find them all, no
matter through which file they've been created. Since this must be set
at open time we need sysfs support for this.
Add an optional mapping parameter bin_attr, which is only consulted
when there's also an mmap callback, since without mmap support
allowing to adjust the ->f_mapping makes no sense.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Christian Brauner
Cc: "David S. Miller"
Cc: Michael Ellerman
Cc: Sourabh Jain
Cc: Daniel Vetter
Cc: Mauro Carvalho Chehab
Cc: Nayna Jain
Signed-off-by: Daniel Vetter
---
fs/sysfs/file.c | 11 +++
include/linux/sysfs.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index 96d0da65e088..9aefa7779b29 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -170,6 +170,16 @@ static int sysfs_kf_bin_mmap(struct kernfs_open_file *of,
return battr->mmap(of->file, kobj, battr, vma);
}
+static int sysfs_kf_bin_open(struct kernfs_open_file *of)
+{
+ struct bin_attribute *battr = of->kn->priv;
+
+ if (battr->mapping)
+ of->file->f_mapping = battr->mapping;
+
+ return 0;
+}
+
void sysfs_notify(struct kobject *kobj, const char *dir, const char *attr)
{
struct kernfs_node *kn = kobj->sd, *tmp;
@@ -241,6 +251,7 @@ static const struct kernfs_ops sysfs_bin_kfops_mmap = {
.read = sysfs_kf_bin_read,
.write = sysfs_kf_bin_write,
.mmap = sysfs_kf_bin_mmap,
+ .open = sysfs_kf_bin_open,
};
int sysfs_add_file_mode_ns(struct kernfs_node *parent,
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 2caa34c1ca1a..d76a1ddf83a3 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -164,11 +164,13 @@ __ATTRIBUTE_GROUPS(_name)
struct file;
struct vm_area_struct;
+struct address_space;
struct bin_attribute {
struct attributeattr;
size_t size;
void*private;
+ struct address_space*mapping;
ssize_t (*read)(struct file *, struct kobject *, struct bin_attribute *,
char *, loff_t, size_t);
ssize_t (*write)(struct file *, struct kobject *, struct bin_attribute
*,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 08/17] PCI: Obey iomem restrictions for procfs mmap
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
Acked-by: Bjorn Helgaas
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Improve commit message (Bjorn)
---
drivers/pci/proc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index d35186b01d98..3a2f90beb4cb 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -274,6 +274,11 @@ static int proc_bus_pci_mmap(struct file *file, struct
vm_area_struct *vma)
else
return -EINVAL;
}
+
+ if (dev->resource[i].flags & IORESOURCE_MEM &&
+ iomem_is_exclusive(dev->resource[i].start))
+ return -EINVAL;
+
ret = pci_mmap_page_range(dev, i, vma,
fpriv->mmap_state, write_combine);
if (ret < 0)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 07/17] mm: Close race in generic_access_phys
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.
Since ioremap might need to manipulate pagetables too we need to drop
the pt lock and have a retry loop if we raced.
While at it, also add kerneldoc and improve the comment for the
vma_ops->access function. It's for accessing, not for moving the
memory from iomem to system memory, as the old comment seemed to
suggest.
References: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Benjamin Herrensmidt
Cc: Dave Airlie
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
v4: While at it, use offset_in_page (Chris Wilson)
---
include/linux/mm.h | 3 ++-
mm/memory.c| 46 +++---
2 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c4cc8ea1402c..b50cbb33d0f3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -574,7 +574,8 @@ struct vm_operations_struct {
vm_fault_t (*pfn_mkwrite)(struct vm_fault *vmf);
/* called by access_process_vm when get_user_pages() fails, typically
-* for use by special VMAs that can switch between memory and hardware
+* for use by special VMAs. See also generic_access_phys() for a generic
+* implementation useful for any iomem mapping.
*/
int (*access)(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write);
diff --git a/mm/memory.c b/mm/memory.c
index c48f8df6e502..ac32039ce941 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4847,28 +4847,68 @@ int follow_phys(struct vm_area_struct *vma,
return ret;
}
+/**
+ * generic_access_phys - generic implementation for iomem mmap access
+ * @vma: the vma to access
+ * @addr: userspace addres, not relative offset within @vma
+ * @buf: buffer to read/write
+ * @len: length of transfer
+ * @write: set to FOLL_WRITE when writing, otherwise reading
+ *
+ * This is a generic implementation for _operations_struct.access for an
+ * iomem mapping. This callback is used by access_process_vm() when the @vma is
+ * not page based.
+ */
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
{
resource_size_t phys_addr;
unsigned long prot = 0;
void __iomem *maddr;
- int offset = addr & (PAGE_SIZE-1);
+ pte_t *ptep, pte;
+ spinlock_t *ptl;
+ int offset = offset_in_page(addr);
+ int ret = -EINVAL;
+
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ return -EINVAL;
+
+retry:
+ if (follow_pte(vma->vm_mm, addr, , ))
+ return -EINVAL;
+ pte = *ptep;
+ pte_unmap_unlock(ptep, ptl);
- if (follow_phys(vma, addr, write, , _addr))
+ prot = pgprot_val(pte_pgprot(pte));
+ phys_addr = (resource_size_t)pte_pfn(pte) << PAGE_SHIFT;
+
+ if ((write & FOLL_WRITE) && !pte_write(pte))
return -EINVAL;
maddr = ioremap_prot(phys_addr, PAGE_ALIGN(len + offset), prot);
if (!maddr)
return -ENOMEM;
+ if (follow_pte(vma->vm_mm, addr, , ))
+ goto out_unmap;
+
+ if (!pte_same(pte, *ptep)) {
+ pte_unmap_unlock(ptep, ptl);
+ iounmap(maddr);
+
+ goto retry;
+ }
+
if (write)
memcpy_toio(maddr + offset, buf, len);
else
memcpy_fromio(buf, maddr + offset, len);
+ ret = len;
+ pte_unmap_unlock(ptep, ptl);
+out_unmap:
iounmap(maddr);
- return len;
+ return ret;
}
EXPORT_SYMBOL_GPL(generic_access_phys);
#endif
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 10/17] resource: Move devmem revoke code to resource framework
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/resource.c.
During review Jason spotted that barriers are used somewhat
inconsistently. Fix that up while we shuffle this code, since it
doesn't have an actual impact at runtime. Otherwise no semantic and
behavioural changes intended, just code extraction and adjusting
comments and names.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: David Hildenbrand
Cc: "Rafael J. Wysocki"
Signed-off-by: Daniel Vetter
--
v3:
- add barrier for consistency and document why we don't have to check
for NULL (Jason)
v4
- Adjust comments to reflect the general nature of this iomem revoke
code now (Dan)
v6:
- An unintentional change which caused side-effects of this
refactoring is that iomem_get_mapping returned NULL for
!CONFIG_IO_STRICT_DEVMEM. But that makes core vfs code blow up,
which assumes a mapping always exists. Undo that accidentional
change. Reported by John.
- Augment the commit message to explain what actually changed with
this extraction (also John).
---
drivers/char/mem.c | 85 +---
include/linux/ioport.h | 6 +--
kernel/resource.c | 98 +-
3 files changed, 99 insertions(+), 90 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 7dcf9e4ea79d..43c871dc7477 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -31,9 +31,6 @@
#include
#include
#include
-#include
-#include
-#include
#ifdef CONFIG_IA64
# include
@@ -836,42 +833,6 @@ static loff_t memory_lseek(struct file *file, loff_t
offset, int orig)
return ret;
}
-static struct inode *devmem_inode;
-
-#ifdef CONFIG_IO_STRICT_DEVMEM
-void revoke_devmem(struct resource *res)
-{
- /* pairs with smp_store_release() in devmem_init_inode() */
- struct inode *inode = smp_load_acquire(_inode);
-
- /*
-* Check that the initialization has completed. Losing the race
-* is ok because it means drivers are claiming resources before
-* the fs_initcall level of init and prevent /dev/mem from
-* establishing mappings.
-*/
- if (!inode)
- return;
-
- /*
-* The expectation is that the driver has successfully marked
-* the resource busy by this point, so devmem_is_allowed()
-* should start returning false, however for performance this
-* does not iterate the entire resource range.
-*/
- if (devmem_is_allowed(PHYS_PFN(res->start)) &&
- devmem_is_allowed(PHYS_PFN(res->end))) {
- /*
-* *cringe* iomem=relaxed says "go ahead, what's the
-* worst that can happen?"
-*/
- return;
- }
-
- unmap_mapping_range(inode->i_mapping, res->start, resource_size(res),
1);
-}
-#endif
-
static int open_port(struct inode *inode, struct file *filp)
{
int rc;
@@ -891,7 +852,7 @@ static int open_port(struct inode *inode, struct file *filp)
* revocations when drivers want to take over a /dev/mem mapped
* range.
*/
- filp->f_mapping = inode->i_mapping;
+ filp->f_mapping = iomem_get_mapping();
return 0;
}
@@ -1023,48 +984,6 @@ static char *mem_devnode(struct device *dev, umode_t
*mode)
static struct class *mem_class;
-static int devmem_fs_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type devmem_fs_type = {
- .name = "devmem",
- .owner = THIS_MODULE,
- .init_fs_context = devmem_fs_init_fs_context,
- .kill_sb= kill_anon_super,
-};
-
-static int devmem_init_inode(void)
-{
- static struct vfsmount *devmem_vfs_mount;
- static int devmem_fs_cnt;
- struct inode *inode;
- int rc;
-
- rc = simple_pin_fs(_fs_type, _vfs_mount, _fs_cnt);
- if (rc < 0) {
- pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
- return rc;
- }
-
- inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
- if (IS_ERR(inode)) {
- rc = PTR_ERR(inode);
- pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
- simple_release_fs(_vfs_mount, _fs_cnt);
- return rc;
- }
-
- /*
[PATCH v7 06/17] media: videobuf2: Move frame_vector into media subsystem
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Acked-by: Hans Verkuil
Acked-by: Mauro Carvalho Chehab
Acked-by: Tomasz Figa
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Daniel Vetter
Signed-off-by: Daniel Vetter
--
v3:
- Create a new frame_vector.h header for this (Mauro)
v5:
- Rebase over changes in frame-vector.c from Tomasz review.
---
drivers/media/common/videobuf2/Kconfig| 1 -
drivers/media/common/videobuf2/Makefile | 1 +
.../media/common/videobuf2}/frame_vector.c| 2 +
drivers/media/platform/omap/Kconfig | 1 -
include/linux/mm.h| 42 -
include/media/frame_vector.h | 47 +++
include/media/videobuf2-core.h| 1 +
mm/Kconfig| 3 --
mm/Makefile | 1 -
9 files changed, 51 insertions(+), 48 deletions(-)
rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
create mode 100644 include/media/frame_vector.h
diff --git a/drivers/media/common/videobuf2/Kconfig
b/drivers/media/common/videobuf2/Kconfig
index edbc99ebba87..d2223a12c95f 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
config VIDEOBUF2_MEMOPS
tristate
- select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/drivers/media/common/videobuf2/Makefile
b/drivers/media/common/videobuf2/Makefile
index 77bebe8b202f..54306f8d096c 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
videobuf2-common-objs := videobuf2-core.o
+videobuf2-common-objs += frame_vector.o
ifeq ($(CONFIG_TRACEPOINTS),y)
videobuf2-common-objs += vb2-trace.o
diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
similarity index 99%
rename from mm/frame_vector.c
rename to drivers/media/common/videobuf2/frame_vector.c
index f8c34b895c76..a0e65481a201 100644
--- a/mm/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
/**
* get_vaddr_frames() - map virtual addresses to pfns
* @start: starting user address
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index f73b5893220d..de16de46c0f4 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
depends on VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
- select FRAME_VECTOR
help
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 29a1941cd255..c4cc8ea1402c 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1751,48 +1751,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned
long pages, bool inc);
int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
struct task_struct *task, bool bypass_rlim);
-/* Container for pinned pfns / pages */
-struct frame_vector {
- unsigned int nr_allocated; /* Number of frames we have space for */
- unsigned int nr_frames; /* Number of frames stored in ptrs array */
- bool got_ref; /* Did we pin pages by getting page ref? */
- bool is_pfns; /* Does array contain pages or pfns? */
- void *ptrs[]; /* Array of pinned pfns / pages. Use
-* pfns_vector_pages() or pfns_vector_pfns()
-* for access */
-};
-
-struct frame_vector *frame_vector_create(unsigned int nr_frames);
-void frame_vector_destroy(struct frame_vector *vec);
-int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
-struct frame_vector *vec);
-void put_vaddr_frames(struct frame_vector *vec);
-int frame_vector_to_pages(struct frame_vector *vec);
-void frame_vector_to_pfns(struct frame_vector *vec);
-
-static inline unsigned int frame_vector_count(struct frame_vector *vec)
-{
- return vec->nr_frames;
-}
-
-static inline struct page **frame_vector_pages(struct frame_vector *vec)
-{
- if (vec->is_pfns) {
- int err = frame_vector_to_pages(vec);
-
- if (err)
- return
[PATCH v7 05/17] mm/frame-vector: Use FOLL_LONGTERM
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Signed-off-by: Daniel Vetter
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Streamline the code and further simplify the loop checks (Jason)
v5: Review from Tomasz:
- fix page counting for the follow_pfn case by resetting ret
- drop gup_flags paramater, now unused
v6: Explain why pup_fast is safe, after discussions with John and
Christoph.
---
.../media/common/videobuf2/videobuf2-memops.c | 3 +-
include/linux/mm.h| 2 +-
mm/frame_vector.c | 53 ++-
3 files changed, 19 insertions(+), 39 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-memops.c
b/drivers/media/common/videobuf2/videobuf2-memops.c
index 6e9e05153f4e..9dd6c27162f4 100644
--- a/drivers/media/common/videobuf2/videobuf2-memops.c
+++ b/drivers/media/common/videobuf2/videobuf2-memops.c
@@ -40,7 +40,6 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
unsigned long first, last;
unsigned long nr;
struct frame_vector *vec;
- unsigned int flags = FOLL_FORCE | FOLL_WRITE;
first = start >> PAGE_SHIFT;
last = (start + length - 1) >> PAGE_SHIFT;
@@ -48,7 +47,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
vec = frame_vector_create(nr);
if (!vec)
return ERR_PTR(-ENOMEM);
- ret = get_vaddr_frames(start & PAGE_MASK, nr, flags, vec);
+ ret = get_vaddr_frames(start & PAGE_MASK, nr, vec);
if (ret < 0)
goto out_destroy;
/* We accept only complete set of PFNs */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 47bff16c182d..29a1941cd255 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1765,7 +1765,7 @@ struct frame_vector {
struct frame_vector *frame_vector_create(unsigned int nr_frames);
void frame_vector_destroy(struct frame_vector *vec);
int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
-unsigned int gup_flags, struct frame_vector *vec);
+struct frame_vector *vec);
void put_vaddr_frames(struct frame_vector *vec);
int frame_vector_to_pages(struct frame_vector *vec);
void frame_vector_to_pfns(struct frame_vector *vec);
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 10f82d5643b6..f8c34b895c76 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -32,13 +32,12 @@
* This function takes care of grabbing mmap_lock as necessary.
*/
int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
-unsigned int gup_flags, struct frame_vector *vec)
+struct frame_vector *vec)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
int ret = 0;
int err;
- int locked;
if (nr_frames == 0)
return 0;
@@ -48,40 +47,26 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
start = untagged_addr(start);
- mmap_read_lock(mm);
- locked = 1;
- vma = find_vma_intersection(mm, start, start + 1);
- if (!vma) {
- ret = -EFAULT;
- goto out;
- }
-
- /*
-* While get_vaddr_frames() could be used for transient (kernel
-* controlled lifetime) pinning of memory pages all current
-* users establish long term (userspace controlled lifetime)
-* page pinning. Treat get_vaddr_frames() like
-* get_user_pages_longterm() and disallow it for filesystem-dax
-* mappings.
-*/
- if (vma_is_fsdax(vma)) {
- ret = -EOPNOTSUPP;
- goto out;
- }
-
- if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
+ ret = pin_user_pages_fast(start, nr_frames,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
+
[PATCH v7 02/17] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ecede41af9b9..1e0c5a7f206e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -475,7 +475,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data
*g2d,
goto err_free;
}
- ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ ret = pin_user_pages_fast(start, npages,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 04/17] misc/habana: Use FOLL_LONGTERM for userptr
These are persistent, not just for the duration of a dma operation.
Reviewed-by: Oded Gabbay
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
Signed-off-by: Daniel Vetter
---
drivers/misc/habanalabs/common/memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 2c59fa869684..0d25ae1d5f3e 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1296,7 +1296,8 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
if (!userptr->pages)
return -ENOMEM;
- rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ rc = pin_user_pages_fast(start, npages,
+FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
userptr->pages);
if (rc != npages) {
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 01/17] drm/exynos: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Note that pin_user_pages_fast is a safe replacement despite the
seeming lack of checking for vma->vm_flasg & (VM_IO | VM_PFNMAP). Such
ptes are marked with pte_mkspecial (which pup_fast rejects in the
fastpath), and only architectures supporting that support the
pin_user_pages_fast fastpath.
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Christoph Hellwig
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Use unpin_user_pages_dirty_lock (John)
v6: Explain why pup_fast is safe, after discussions with John and
Christoph.
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 47 +++--
2 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 951d5f708e92..6a251e3aa779 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -89,7 +89,6 @@ comment "Sub-drivers"
config DRM_EXYNOS_G2D
bool "G2D"
depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST
- select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 967a5cdc120e..ecede41af9b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -205,7 +205,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
atomic_trefcount;
boolin_pool;
@@ -378,7 +379,6 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
bool force)
{
struct g2d_cmdlist_userptr *g2d_userptr = obj;
- struct page **pages;
if (!obj)
return;
@@ -398,15 +398,9 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
DMA_BIDIRECTIONAL, 0);
- pages = frame_vector_pages(g2d_userptr->vec);
- if (!IS_ERR(pages)) {
- int i;
-
- for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
- set_page_dirty_lock(pages[i]);
- }
- put_vaddr_frames(g2d_userptr->vec);
- frame_vector_destroy(g2d_userptr->vec);
+ unpin_user_pages_dirty_lock(g2d_userptr->pages, g2d_userptr->npages,
+ true);
+ kvfree(g2d_userptr->pages);
if (!g2d_userptr->out_of_list)
list_del_init(_userptr->list);
@@ -474,35 +468,34 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
g2d_data *g2d,
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
- g2d_userptr->vec = frame_vector_create(npages);
- if (!g2d_userptr->vec) {
+ g2d_userptr->pages = kvmalloc_array(npages, sizeof(*g2d_userptr->pages),
+ GFP_KERNEL);
+ if (!g2d_userptr->pages) {
ret = -ENOMEM;
goto err_free;
}
- ret = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- g2d_userptr->vec);
+ ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
"failed to get user pages from userptr.\n");
if (ret < 0)
- goto err_destroy_framevec;
- ret = -EFAULT;
- goto err_put_framevec;
- }
- if (frame_vector_to_pages(g2d_userptr->vec) < 0) {
+ goto err_destroy_pages;
+ npages = ret;
ret = -EFAULT;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
+ g2d_userptr->npages = npages;
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
ret = -ENOMEM;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
ret = sg_alloc_table_from_pages(sgt,
-
[PATCH v7 00/17] follow_pfn and other iomap races
Hi all Another update of my patch series to clamp down a bunch of races and gaps around follow_pfn and other access to iomem mmaps. Previous version: v1: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ v2: https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vet...@ffwll.ch v3: https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vet...@ffwll.ch/ v4: https://lore.kernel.org/dri-devel/20201026105818.2585306-1-daniel.vet...@ffwll.ch/ v5: https://lore.kernel.org/dri-devel/20201030100815.2269-1-daniel.vet...@ffwll.ch/ v6: https://lore.kernel.org/dri-devel/20201119144146.1045202-1-daniel.vet...@ffwll.ch/ And the discussion that sparked this journey: https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/ I think the first 12 patches are ready for landing. The parts starting with "mm: Add unsafe_follow_pfn" probably need more baking time. Andrew, can you please pick these up, or do you prefer I do a topic branch and send them to Linus directly in the next merge window? Changes in v7: - more acks/reviews - reordered with the ready pieces at the front - simplified the new follow_pfn function as Jason suggested Changes in v6: - Tested v4l userptr as Tomasz suggested. No boom observed - Added RFC for locking down follow_pfn, per discussion with Christoph and Jason. - Explain why pup_fast is safe in relevant patches, there was a bit a confusion when discussing v5. - Fix up the resource patch, with CONFIG_IO_STRICT_DEVMEM it crashed on boot due to an unintended change (reported by John) Changes in v5: - Tomasz found some issues in the media patches - Polish suggested by Christoph for the unsafe_follow_pfn patch Changes in v4: - Drop the s390 patch, that was very stand-alone and now queued up to land through s390 trees. - Comment polish per Dan's review. Changes in v3: - Bunch of polish all over, no functional changes aside from one barrier in the resource code, for consistency. - A few more r-b tags. Changes in v2: - tons of small polish all over, thanks to all the reviewers who spotted issues - I managed to test at least the generic_access_phys and pci mmap revoke stuff with a few gdb sessions using our i915 debug tools (hence now also the drm/i915 patch to properly request all the pci bar regions) - reworked approach for the pci mmap revoke: Infrastructure moved into kernel/resource.c, address_space mapping is now set up at open time for everyone (which required some sysfs changes). Does indeed look a lot cleaner and a lot less invasive than I feared at first. Coments and review on the remaining bits very much welcome, especially from the kvm and vfio side. Cheers, Daniel Daniel Vetter (17): drm/exynos: Stop using frame_vector helpers drm/exynos: Use FOLL_LONGTERM for g2d cmdlists misc/habana: Stop using frame_vector helpers misc/habana: Use FOLL_LONGTERM for userptr mm/frame-vector: Use FOLL_LONGTERM media: videobuf2: Move frame_vector into media subsystem mm: Close race in generic_access_phys PCI: Obey iomem restrictions for procfs mmap /dev/mem: Only set filp->f_mapping resource: Move devmem revoke code to resource framework sysfs: Support zapping of binary attr mmaps PCI: Revoke mappings like devmem mm: Add unsafe_follow_pfn media/videobuf1|2: Mark follow_pfn usage as unsafe vfio/type1: Mark follow_pfn as unsafe kvm: pass kvm argument to follow_pfn callsites mm: add mmu_notifier argument to follow_pfn arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +- arch/powerpc/kvm/book3s_64_mmu_radix.c| 2 +- arch/powerpc/kvm/e500_mmu_host.c | 2 +- arch/x86/kvm/mmu/mmu.c| 8 +- drivers/char/mem.c| 86 +- drivers/gpu/drm/exynos/Kconfig| 1 - drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 drivers/media/common/videobuf2/Kconfig| 1 - drivers/media/common/videobuf2/Makefile | 1 + .../media/common/videobuf2}/frame_vector.c| 57 - .../media/common/videobuf2/videobuf2-memops.c | 3 +- drivers/media/platform/omap/Kconfig | 1 - drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +- drivers/misc/habanalabs/Kconfig | 1 - drivers/misc/habanalabs/common/habanalabs.h | 6 +- drivers/misc/habanalabs/common/memory.c | 52 +++- drivers/pci/pci-sysfs.c | 4 + drivers/pci/proc.c| 6 + drivers/vfio/vfio_iommu_type1.c | 4 +- fs/sysfs/file.c | 11 ++ include/linux/ioport.h| 6 +- include/linux/kvm_host.h | 9 +- include/linux/mm.h| 50 +--- include/linux/sysfs.h | 2 + include/media/frame_vector.h | 47 include/media/videobuf2-core.h
[PATCH RESEND] drm/nouveau: Drop mutex_lock_nested for atomic
Purely conjecture, but I think the original locking inversion with the
legacy page flip code between flipping and ttm's bo move function
shoudn't exist anymore with atomic: With atomic the bo pinning and
actual modeset commit is completely separated in the code patsh.
This annotation was originally added in
commit 060810d7abaabcab282e062c595871d661561400
Author: Ben Skeggs
Date: Mon Jul 8 14:15:51 2013 +1000
drm/nouveau: fix locking issues in page flipping paths
due to
commit b580c9e2b7ba5030a795aa2fb73b796523d65a78
Author: Maarten Lankhorst
Date: Thu Jun 27 13:48:18 2013 +0200
drm/nouveau: make flipping lockdep safe
Acked-by: Ben Skeggs
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1386b0fc1640..43069dd8b027 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -774,7 +774,10 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict,
return ret;
}
- mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
+ if (drm_drv_uses_atomic_modeset(drm->dev))
+ mutex_lock(>mutex);
+ else
+ mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
ctx->interruptible);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, >mem, new_reg);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- drivers/gpu/drm/i915/intel_device_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index e67cec8fa2aa..ef767f04c37c 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -104,7 +104,7 @@ void intel_device_info_print_static(const struct intel_device_info *info, drm_printf(p, "ppgtt-type: %d\n", info->ppgtt_type); drm_printf(p, "dma_mask_size: %u\n", info->dma_mask_size); -#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name)); +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->name)) DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG); #undef PRINT_FLAG -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu/display: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index f9c81bc21ba4..301e93c9e72a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -1213,7 +1213,7 @@ int emu_soc_asic_init(struct amdgpu_device *adev); #define amdgpu_asic_update_umd_stable_pstate(adev, enter) \ ((adev)->asic_funcs->update_umd_stable_pstate ? (adev)->asic_funcs->update_umd_stable_pstate((adev), (enter)) : 0) -#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)); +#define amdgpu_inc_vram_lost(adev) atomic_inc(&((adev)->vram_lost_counter)) /* Common functions */ bool amdgpu_device_has_job_running(struct amdgpu_device *adev); -- 2.18.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On 11/27/20 9:59 AM, Daniel Vetter wrote: On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote: On 11/25/20 11:36 AM, Daniel Vetter wrote: On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote: Am 25.11.20 um 11:40 schrieb Daniel Vetter: On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König wrote: Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky: On 11/24/20 2:41 AM, Christian König wrote: Am 23.11.20 um 22:08 schrieb Andrey Grodzovsky: On 11/23/20 3:41 PM, Christian König wrote: Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky: On 11/23/20 3:20 PM, Christian König wrote: Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: On 11/25/20 5:42 AM, Christian König wrote: Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: It's needed to drop iommu backed pages on device unplug before device's IOMMU group is released. It would be cleaner if we could do the whole handling in TTM. I also need to double check what you are doing with this function. Christian. Check patch "drm/amdgpu: Register IOMMU topology notifier per device." to see how i use it. I don't see why this should go into TTM mid-layer - the stuff I do inside is vendor specific and also I don't think TTM is explicitly aware of IOMMU ? Do you mean you prefer the IOMMU notifier to be registered from within TTM and then use a hook to call into vendor specific handler ? No, that is really vendor specific. What I meant is to have a function like ttm_resource_manager_evict_all() which you only need to call and all tt objects are unpopulated. So instead of this BO list i create and later iterate in amdgpu from the IOMMU patch you just want to do it within TTM with a single function ? Makes much more sense. Yes, exactly. The list_empty() checks we have in TTM for the LRU are actually not the best idea, we should now check the pin_count instead. This way we could also have a list of the pinned BOs in TTM. So from my IOMMU topology handler I will iterate the TTM LRU for the unpinned BOs and this new function for the pinned ones ? It's probably a good idea to combine both iterations into this new function to cover all the BOs allocated on the device. Yes, that's what I had in my mind as well. BTW: Have you thought about what happens when we unpopulate a BO while we still try to use a kernel mapping for it? That could have unforeseen consequences. Are you asking what happens to kmap or vmap style mapped CPU accesses once we drop all the DMA backing pages for a particular BO ? Because for user mappings (mmap) we took care of this with dummy page reroute but indeed nothing was done for in kernel CPU mappings. Yes exactly that. In other words what happens if we free the ring buffer while the kernel still writes to it? Christian. While we can't control user application accesses to the mapped buffers explicitly and hence we use page fault rerouting I am thinking that in this case we may be able to sprinkle drm_dev_enter/exit in any such sensitive place were we might CPU access a DMA buffer from the kernel ? Yes, I fear we are going to need that. Uh ... problem is that dma_buf_vmap are usually permanent things. Maybe we could stuff this into begin/end_cpu_access Do you mean guarding with drm_dev_enter/exit in dma_buf_ops.begin/end_cpu_access driver specific hook ? (but only for the kernel, so a bit tricky)? Why only kernel ? Why is it a problem to do it if it comes from dma_buf_ioctl by some user process ? And if we do need this distinction I think we should be able to differentiate by looking at current->mm (i.e. mm_struct) pointer being NULL for kernel thread. Userspace mmap is handled by punching out the pte. So we don't need to do anything special there. For kernel mmap the begin/end should be all in the same context (so we could use the srcu lock that works underneath drm_dev_enter/exit), since at least right now kernel vmaps of dma-buf are very long-lived. If by same context you mean the right drm_device (the exporter's one) then this should be ok as I am seeing from amdgpu implementation of the callback - amdgpu_dma_buf_begin_cpu_access. We just need to add handler for .end_cpu_access callback to call drm_dev_exit there. Andrey But the good news is that Thomas Zimmerman is working on this problem already for different reasons, so it might be that we won't have any long-lived kernel vmap anymore. And we could put the drm_dev_enter/exit in there. Oh very very good point! I haven't thought about DMA-buf mmaps in this context yet. btw the other issue with dma-buf (and even worse with dma_fence) is refcounting of the underlying drm_device. I'd expect that all your callbacks go boom if the dma_buf outlives your drm_device. That part isn't yet solved in your series here. Well thinking more about this, it seems to be a another really good argument why mapping pages from DMA-bufs into application address space directly is a very bad idea :) But yes, we essentially can't remove the device as
Re: [PATCH] drm/komeda: Handle NULL pointer access code path in error case
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote: From: Carsten Haitzler komeda_component_get_old_state() technically can return a NULL pointer. komeda_compiz_set_input() even warns when this happens, but then proceeeds to use that NULL pointer tocompare memory content there agains the new sate to see if it changed. In this case, it's better to assume that the input changed as there is no old state to compare against and thus assume the changes happen anyway. Signed-off-by: Carsten Haitzler --- drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index 8f32ae7c25d0..e8b1e15312d8 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -707,7 +707,8 @@ komeda_compiz_set_input(struct komeda_compiz *compiz, WARN_ON(!old_st); /* compare with old to check if this input has been changed */ - if (memcmp(&(to_compiz_st(old_st)->cins[idx]), cin, sizeof(*cin))) + if (!old_st || + memcmp(&(to_compiz_st(old_st)->cins[idx]), cin, sizeof(*cin))) c_st->changed_active_inputs |= BIT(idx); Even better, you can move the WARN_ON into the if: if (WARN_ON(!old_st) || ... Either way: Reviewed-by: Steven Price Steve komeda_component_add_input(c_st, >input, idx); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Remove useless variable assignment
On 27/11/2020 11:00, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
ret is not actually read after this (only written in one case then
returned), so this assign line is useless. This removes that assignment.
Signed-off-by: Carsten Haitzler
Reviewed-by: Steven Price
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 1d767473ba8a..eea76f51f662 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -163,7 +163,6 @@ static int komeda_parse_dt(struct device *dev, struct
komeda_dev *mdev)
ret = of_reserved_mem_device_init(dev);
if (ret && ret != -ENODEV)
return ret;
- ret = 0;
for_each_available_child_of_node(np, child) {
if (of_node_name_eq(child, "pipeline")) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [REGRESSION] omapdrm/N900 display broken
On 27/11/2020 01:17, Ivaylo Dimitrov wrote: > Hi Tomi, > > On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote: >> Hi Aaro, Ivaylo, >> >> On 24/11/2020 23:03, Ivaylo Dimitrov wrote: >> >>> Is there any progress on the issue? I tried 5.9.1 and still nothing >>> displayed. >> >> Can you test the attached patch? >> > > With this patch I don't see oops that Aaro reported, so: > > Tested-by: Ivaylo Dimitrov > > Seems to fix the particular issue, however, now we get another oops. As this > is not upstream kernel > but one with PVR related patches, I will try again with vanilla 5.9. > > Just in case oops rings any bells (the line in question is > https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801) Do the PVR patches touch omapdrm? The call stack looks like normal boot time probing stuff, not something happening later (possibly from PVR). Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Warn on pinning without holding a reference
On Wed, Oct 28, 2020 at 01:11:51PM +0100, Christian König wrote:
> Am 28.10.20 um 12:31 schrieb Daniel Vetter:
> > Not technically a problem for ttm, but very likely a driver bug and
> > pretty big time confusing for reviewing code.
> >
> > So warn about it, both at cleanup time (so we catch these for sure)
> > and at pin/unpin time (so we know who's the culprit).
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Christian Koenig
> > Cc: Huang Rui
>
> Reviewed-by: Christian König
Remembered this patch, pushed it. Thanks to you both for the reviews.
-Daniel
>
> > ---
> > drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> > include/drm/ttm/ttm_bo_api.h | 2 ++
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index f51b5e20fa17..a011072ab61d 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -509,7 +509,7 @@ static void ttm_bo_release(struct kref *kref)
> > * shrinkers, now that they are queued for
> > * destruction.
> > */
> > - if (bo->pin_count) {
> > + if (WARN_ON(bo->pin_count)) {
> > bo->pin_count = 0;
> > ttm_bo_del_from_lru(bo);
> > ttm_bo_add_mem_to_lru(bo, >mem);
> > diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> > index 37102e45e496..b45aee23d7d0 100644
> > --- a/include/drm/ttm/ttm_bo_api.h
> > +++ b/include/drm/ttm/ttm_bo_api.h
> > @@ -571,6 +571,7 @@ static inline bool
> > ttm_bo_uses_embedded_gem_object(struct ttm_buffer_object *bo)
> > static inline void ttm_bo_pin(struct ttm_buffer_object *bo)
> > {
> > dma_resv_assert_held(bo->base.resv);
> > + WARN_ON_ONCE(!kref_read(>kref));
> > ++bo->pin_count;
> > }
> > @@ -584,6 +585,7 @@ static inline void ttm_bo_unpin(struct
> > ttm_buffer_object *bo)
> > {
> > dma_resv_assert_held(bo->base.resv);
> > WARN_ON_ONCE(!bo->pin_count);
> > + WARN_ON_ONCE(!kref_read(>kref));
> > --bo->pin_count;
> > }
>
--
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 v6 00/17] follow_pfn and other iomap races
On Fri, Nov 27, 2020 at 09:12:25AM -0400, Jason Gunthorpe wrote: > On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote: > > I feel like this is ready for some wider soaking. Since the remaining bits > > are all kinda connnected probably simplest if it all goes through -mm. > > Did you figure out a sumbission plan for this stuff? I was kinda hoping Andrew would pick it all up. > > Daniel Vetter (17): > > drm/exynos: Stop using frame_vector helpers > > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > > misc/habana: Stop using frame_vector helpers > > misc/habana: Use FOLL_LONGTERM for userptr > > mm/frame-vector: Use FOLL_LONGTERM > > media: videobuf2: Move frame_vector into media subsystem > > At the very least it would be good to get those in right away. > > > mm: Add unsafe_follow_pfn > > media/videbuf1|2: Mark follow_pfn usage as unsafe > > vfio/type1: Mark follow_pfn as unsafe > > I'm surprised nobody from VFIO has remarked on this, I think thety > won't like it Same here tbh :-) > > mm: Close race in generic_access_phys > > PCI: Obey iomem restrictions for procfs mmap > > /dev/mem: Only set filp->f_mapping > > resource: Move devmem revoke code to resource framework > > sysfs: Support zapping of binary attr mmaps > > PCI: Revoke mappings like devmem > > This sequence seems fairly stand alone, and in good shape as well Yeah your split makes sense. I'll reorder them for the next round (which I'm prepping right now). > > My advice is to put the done things on a branch and get Stephen to put > them in linux-next. You can send a PR to Lins. There is very little mm > stuff in here, and cross subsystem stuff works better in git land, > IMHO. Yeah could do. Andrew, any preferences? -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 v3 10/12] drm/amdgpu: Avoid sysfs dirs removal post device unplug
On 11/27/20 10:04 AM, Daniel Vetter wrote: On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote: On 11/25/20 4:04 AM, Daniel Vetter wrote: On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky wrote: On 11/24/20 9:49 AM, Daniel Vetter wrote: On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzovsky wrote: Avoids NULL ptr due to kobj->sd being unset on device removal. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c index caf828a..812e592 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "amdgpu.h" #include "amdgpu_ras.h" @@ -1043,7 +1044,8 @@ static int amdgpu_ras_sysfs_remove_feature_node(struct amdgpu_device *adev) .attrs = attrs, }; -sysfs_remove_group(>dev->kobj, ); +if (!drm_dev_is_unplugged(>ddev)) +sysfs_remove_group(>dev->kobj, ); This looks wrong. sysfs, like any other interface, should be unconditionally thrown out when we do the drm_dev_unregister. Whether hotunplugged or not should matter at all. Either this isn't needed at all, or something is wrong with the ordering here. But definitely fishy. -Daniel So technically this is needed because kobejct's sysfs directory entry kobj->sd is set to NULL on device removal (from sysfs_remove_dir) but because we don't finalize the device until last reference to drm file is dropped (which can happen later) we end up calling sysfs_remove_file/dir after this pointer is NULL. sysfs_remove_file checks for NULL and aborts while sysfs_remove_dir is not and that why I guard against calls to sysfs_remove_dir. But indeed the whole approach in the driver is incorrect, as Greg pointed out - we should use default groups attributes instead of explicit calls to sysfs interface and this would save those troubles. But again. the issue here of scope of work, converting all of amdgpu to default groups attributes is somewhat lengthy process with extra testing as the entire driver is papered with sysfs references and seems to me more of a standalone cleanup, just like switching to devm_ and drmm_ work. To me at least it seems that it makes more sense to finalize and push the hot unplug patches so that this new functionality can be part of the driver sooner and then incrementally improve it by working on those other topics. Just as devm_/drmm_ I also added sysfs cleanup to my TODO list in the RFC patch. Hm, whether you solve this with the default group stuff to auto-remove, or remove explicitly at the right time doesn't matter much. The underlying problem you have here is that it's done way too late. As far as I understood correctly the default group attrs by reading this article by Greg - https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linux.com%2Fnews%2Fhow-create-sysfs-file-correctly%2Fdata=04%7C01%7CAndrey.Grodzovsky%40amd.com%7C3e993d1dfad7462608d892e5bbb9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637420862696611997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=HAlEqI6CYR3k1n9FFAibpjBlK7I7x9W23yd5CWJVYgM%3Dreserved=0 it will be removed together with the device and not too late like now and I quote from the last paragraph there: "By setting this value, you don’t have to do anything in your probe() or release() functions at all in order for the sysfs files to be properly created and destroyed whenever your device is added or removed from the system. And you will, most importantly, do it in a race-free manner, which is always a good thing." To me this seems like the best solution to the late remove issue. What do you think ? sysfs removal (like all uapi interfaces) need to be removed as part of drm_dev_unregister. Do you mean we need to trace and aggregate all sysfs files creation within the low level drivers and then call some sysfs release function inside drm_dev_unregister to iterate and release them all ? That would just reinvent the proper solution Greg explained above. For now I think you just need some driver callback that you call right after drm_dev_unplug (or drm_dev_unregister) to clean up these sysfs interfaces. Afaiui the important part is to clean up your additional interfaces from the ->remove callback, since at that point the core sysfs stuff still exists. Maybe you want to do another loop over all IP blocks and a ->unregister callback, or maybe it's just 1-2 cases you call directly. Most of them are barried within non ip block entites (e.g amdgpu_device_fini->amdgpu_atombios_fini->amdgpu_atombios_fini->device_remove_file->sysfs_remove_file) or much longer chain in kfd, like
Re: [Intel-gfx] [PATCH 1/2] drm/framebuffer: Format modifier for Intel Gen 12 render compression with Clear Color
On Fri, Nov 27, 2020 at 04:31:00PM +0200, Imre Deak wrote:
> Hi Daniel, Jani,
>
> is it ok to merge this patch along with 2/2 via the i915 tree?
Ack from mesa (userspace in general, but mesa is kinda mandatory) is
missing I think. With that
Acked-by: Daniel Vetter
>
> --Imre
>
> On Mon, Nov 23, 2020 at 08:26:30PM +0200, Imre Deak wrote:
> > From: Radhakrishna Sripada
> >
> > Gen12 display can decompress surfaces compressed by render engine with
> > Clear Color, add a new modifier as the driver needs to know the surface
> > was compressed by render engine.
> >
> > V2: Description changes as suggested by Rafael.
> > V3: Mention the Clear Color size of 64 bits in the comments(DK)
> > v4: Fix trailing whitespaces
> > v5: Explain Clear Color in the documentation.
> > v6: Documentation Nitpicks(Nanley)
> >
> > Cc: Ville Syrjala
> > Cc: Dhinakaran Pandiyan
> > Cc: Kalyan Kondapally
> > Cc: Rafael Antognolli
> > Cc: Nanley Chery
> > Signed-off-by: Radhakrishna Sripada
> > Signed-off-by: Imre Deak
> > ---
> > include/uapi/drm/drm_fourcc.h | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index ca48ed0e6bc1..0a1b2c4c4bee 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -527,6 +527,25 @@ extern "C" {
> > */
> > #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7)
> >
> > +/*
> > + * Intel Color Control Surface with Clear Color (CCS) for Gen-12 render
> > + * compression.
> > + *
> > + * The main surface is Y-tiled and is at plane index 0 whereas CCS is
> > linear
> > + * and at index 1. The clear color is stored at index 2, and the pitch
> > should
> > + * be ignored. The clear color structure is 256 bits. The first 128 bits
> > + * represents Raw Clear Color Red, Green, Blue and Alpha color each
> > represented
> > + * by 32 bits. The raw clear color is consumed by the 3d engine and
> > generates
> > + * the converted clear color of size 64 bits. The first 32 bits store the
> > Lower
> > + * Converted Clear Color value and the next 32 bits store the Higher
> > Converted
> > + * Clear Color value when applicable. The Converted Clear Color values are
> > + * consumed by the DE. The last 64 bits are used to store Color Discard
> > Enable
> > + * and Depth Clear Value Valid which are ignored by the DE. A CCS cache
> > line
> > + * corresponds to an area of 4x1 tiles in the main surface. The main
> > surface
> > + * pitch is required to be a multiple of 4 tile widths.
> > + */
> > +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
> > +
> > /*
> > * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
> > *
> > --
> > 2.25.1
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> 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 v2] fbdev: aty: SPARC64 requires FB_ATY_CT
On Fri, Nov 27, 2020 at 10:15:49AM +0100, Geert Uytterhoeven wrote:
> On Fri, Nov 27, 2020 at 4:18 AM Randy Dunlap wrote:
> > It looks like SPARC64 requires FB_ATY_CT to build without errors,
> > so have FB_ATY select FB_ATY_CT if both SPARC64 and PCI are enabled
> > instead of using "default y if SPARC64 && PCI", which is not strong
> > enough to prevent build errors.
> >
> > As it currently is, FB_ATY_CT can be disabled, resulting in build
> > errors:
> >
> > ERROR: modpost: "aty_postdividers" [drivers/video/fbdev/aty/atyfb.ko]
> > undefined!
> > ERROR: modpost: "aty_ld_pll_ct" [drivers/video/fbdev/aty/atyfb.ko]
> > undefined!
> >
> > Fixes: f7018c213502 ("video: move fbdev to drivers/video/fbdev")
> > Signed-off-by: Randy Dunlap
>
> Reviewed-by: Geert Uytterhoeven
Applied to drm-misc-next, thanks for the patch
-Daniel
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
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/vboxvideo: Used the vram helper
On Fri, Nov 27, 2020 at 11:14:42AM +0800, Tian Tao wrote:
> if the driver uses drmm_vram_helper_init, there is no need to
> call drm_vram_helper_release_mm when the drm module get unloaded,
> as this will done automagically.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/vboxvideo/vbox_ttm.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> index f5a0667..e1909a8 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
> @@ -16,8 +16,8 @@ int vbox_mm_init(struct vbox_private *vbox)
> int ret;
> struct drm_device *dev = >ddev;
>
> - vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(dev->pdev, 0),
> -vbox->available_vram_size);
> + vmm = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
> + vbox->available_vram_size);
Pretty sure this doesn't compile without warnings, since the return value
changes. With that fixed lgtm.
Btw if you're bored, a devm_ version of arch_phys_wc_add is very much on
the wishlist, and would allow us to complete remove vbox_mm_fini.
Cheers, Daniel
> if (IS_ERR(vmm)) {
> ret = PTR_ERR(vmm);
> DRM_ERROR("Error initializing VRAM MM; %d\n", ret);
> @@ -32,5 +32,4 @@ int vbox_mm_init(struct vbox_private *vbox)
> void vbox_mm_fini(struct vbox_private *vbox)
> {
> arch_phys_wc_del(vbox->fb_mtrr);
> - drm_vram_helper_release_mm(>ddev);
> }
> --
> 2.7.4
>
--
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/radeon: fix check order in radeon_bo_move
On Fri, Nov 27, 2020 at 03:49:31PM +0100, Christian König wrote:
> Am 27.11.20 um 15:46 schrieb Daniel Vetter:
> > On Fri, Nov 27, 2020 at 3:10 PM Christian König
> > wrote:
> > > Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > > > Oops sorry for delay LGTM
> > > >
> > > > Reviewed-by: Dave Airlie
> > > Thanks.
> > >
> > > > On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
> > > > > On Wed, Nov 25, 2020 at 3:34 PM Christian König
> > > > > wrote:
> > > > > > Reorder the code to fix checking if blitting is available.
> > > > > Might be good to explain why blitting might not be available, e.g.
> > > > > suspend/resume and or chip death and stuff like that.
> > > > >
> > > > > > Signed-off-by: Christian König
> > > > > Needs Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")
> > > Why does the subject of the patch needs to be in "()" ? I was already
> > > wondering why dim sometimes complains about my Fixes tag.
> > Hm I thought that's the official style. I kinda hacked around on it
> > until linux-next stopped complaining about our Fixes: tags. Maybe it's
> > not quite accurately reflecting the current bikeshed. Iirc checkpatch
> > even complains when you leave out the commit before the sha1, at least
> > in free-form text in the commit message.
>
> Well "git log -1 --oneline 28a68f828266" gives me:
>
> 28a68f828266 drm/radeon/ttm: use multihop
>
> Which is what I would naturally expect here, but no idea what the official
> format should be.
dim cite $sha1 is our attempt at modelling it. And yeah it's just
bikeshedded differently for no good reason. And I just noticed that dim
cite doesn't include the commit before the sha1.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > > > Btw
> > > > >
> > > > > $ dim fixes [sha1]
> > > > >
> > > > > generates that for you plus nice cc list of offenders. With the Fixes
> > > > > line added:
> > > > >
> > > > > Reviewed-by: Daniel Vetter
> > > Thanks,
> > > Christian.
> > >
>
--
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 1/7] drm/radeon: stop using pages with drm_prime_sg_to_page_addr_arrays v2
On Fri, Nov 27, 2020 at 03:11:05PM +0100, Christian König wrote:
> Ping? Daniel any more ideas on this or should we push it?
Occasionally I bit more prose would be nice about why things changed or
so. Iirc the reason I asked about using ttm_sg_tt_init is that it makes it
easier to convince ourselves that we don't mix things up. Maybe add that
(or cover letter next time around). Just helps since at least my silly
brain forgets details like that within days, and is usually terminally
lost when git bisect lands on such a patch. Also helps reviewers stay
motivated sometimes :-)
Anyway I think this looks all reasonable now, on the series:
Acked-by: Daniel Vetter
>
> Thanks,
> Christian.
>
> Am 25.11.20 um 13:59 schrieb Christian König:
> > This is deprecated.
> >
> > v2: also use ttm_sg_tt_init to avoid allocating the page array.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/gpu/drm/radeon/radeon_ttm.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index 0ca381b95d3d..5d00b3dff388 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -401,8 +401,8 @@ static int radeon_ttm_tt_pin_userptr(struct
> > ttm_bo_device *bdev, struct ttm_tt *
> > if (r)
> > goto release_sg;
> > - drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
> > -gtt->ttm.dma_address, ttm->num_pages);
> > + drm_prime_sg_to_page_addr_arrays(ttm->sg, NULL, gtt->ttm.dma_address,
> > +ttm->num_pages);
> > return 0;
> > @@ -542,7 +542,7 @@ static struct ttm_tt *radeon_ttm_tt_create(struct
> > ttm_buffer_object *bo,
> > else
> > caching = ttm_cached;
> > - if (ttm_dma_tt_init(>ttm, bo, page_flags, caching)) {
> > + if (ttm_sg_tt_init(>ttm, bo, page_flags, caching)) {
> > kfree(gtt);
> > return NULL;
> > }
> > @@ -580,8 +580,9 @@ static int radeon_ttm_tt_populate(struct ttm_bo_device
> > *bdev,
> > }
> > if (slave && ttm->sg) {
> > - drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages,
> > -gtt->ttm.dma_address,
> > ttm->num_pages);
> > + drm_prime_sg_to_page_addr_arrays(ttm->sg, NULL,
> > +gtt->ttm.dma_address,
> > +ttm->num_pages);
> > return 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 v3 10/12] drm/amdgpu: Avoid sysfs dirs removal post device unplug
On Wed, Nov 25, 2020 at 12:39:47PM -0500, Andrey Grodzovsky wrote: > > On 11/25/20 4:04 AM, Daniel Vetter wrote: > > On Tue, Nov 24, 2020 at 11:27 PM Andrey Grodzovsky > > wrote: > > > > > > On 11/24/20 9:49 AM, Daniel Vetter wrote: > > > > On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzovsky wrote: > > > > > Avoids NULL ptr due to kobj->sd being unset on device removal. > > > > > > > > > > Signed-off-by: Andrey Grodzovsky > > > > > --- > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 +++- > > > > >drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 4 +++- > > > > >2 files changed, 6 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > > > > > index caf828a..812e592 100644 > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c > > > > > @@ -27,6 +27,7 @@ > > > > >#include > > > > >#include > > > > >#include > > > > > +#include > > > > > > > > > >#include "amdgpu.h" > > > > >#include "amdgpu_ras.h" > > > > > @@ -1043,7 +1044,8 @@ static int > > > > > amdgpu_ras_sysfs_remove_feature_node(struct amdgpu_device *adev) > > > > > .attrs = attrs, > > > > > }; > > > > > > > > > > -sysfs_remove_group(>dev->kobj, ); > > > > > +if (!drm_dev_is_unplugged(>ddev)) > > > > > +sysfs_remove_group(>dev->kobj, ); > > > > This looks wrong. sysfs, like any other interface, should be > > > > unconditionally thrown out when we do the drm_dev_unregister. Whether > > > > hotunplugged or not should matter at all. Either this isn't needed at > > > > all, > > > > or something is wrong with the ordering here. But definitely fishy. > > > > -Daniel > > > > > > So technically this is needed because kobejct's sysfs directory entry > > > kobj->sd > > > is set to NULL > > > on device removal (from sysfs_remove_dir) but because we don't finalize > > > the device > > > until last reference to drm file is dropped (which can happen later) we > > > end up > > > calling sysfs_remove_file/dir after > > > this pointer is NULL. sysfs_remove_file checks for NULL and aborts while > > > sysfs_remove_dir > > > is not and that why I guard against calls to sysfs_remove_dir. > > > But indeed the whole approach in the driver is incorrect, as Greg pointed > > > out - > > > we should use > > > default groups attributes instead of explicit calls to sysfs interface > > > and this > > > would save those troubles. > > > But again. the issue here of scope of work, converting all of amdgpu to > > > default > > > groups attributes is somewhat > > > lengthy process with extra testing as the entire driver is papered with > > > sysfs > > > references and seems to me more of a standalone > > > cleanup, just like switching to devm_ and drmm_ work. To me at least it > > > seems > > > that it makes more sense > > > to finalize and push the hot unplug patches so that this new > > > functionality can > > > be part of the driver sooner > > > and then incrementally improve it by working on those other topics. Just > > > as > > > devm_/drmm_ I also added sysfs cleanup > > > to my TODO list in the RFC patch. > > Hm, whether you solve this with the default group stuff to > > auto-remove, or remove explicitly at the right time doesn't matter > > much. The underlying problem you have here is that it's done way too > > late. > > As far as I understood correctly the default group attrs by reading this > article by Greg - https://www.linux.com/news/how-create-sysfs-file-correctly/ > it will be removed together with the device and not too late like now and I > quote > from the last paragraph there: > > "By setting this value, you don’t have to do anything in your > probe() or release() functions at all in order for the > sysfs files to be properly created and destroyed whenever your > device is added or removed from the system. And you will, most > importantly, do it in a race-free manner, which is always a good thing." > > To me this seems like the best solution to the late remove issue. What do > you think ? > > > > sysfs removal (like all uapi interfaces) need to be removed as > > part of drm_dev_unregister. > > > Do you mean we need to trace and aggregate all sysfs files creation within > the low level drivers and then call some sysfs release function inside > drm_dev_unregister > to iterate and release them all ? That would just reinvent the proper solution Greg explained above. For now I think you just need some driver callback that you call right after drm_dev_unplug (or drm_dev_unregister) to clean up these sysfs interfaces. Afaiui the important part is to clean up your additional interfaces from the ->remove callback, since at that point the core sysfs stuff still exists. Maybe you want to do another loop over all IP blocks and a ->unregister callback, or maybe it's just 1-2 cases you call directly. > >
Re: [PATCH v3 05/12] drm/ttm: Expose ttm_tt_unpopulate for driver use
On Wed, Nov 25, 2020 at 02:34:44PM -0500, Andrey Grodzovsky wrote: > > On 11/25/20 11:36 AM, Daniel Vetter wrote: > > On Wed, Nov 25, 2020 at 01:57:40PM +0100, Christian König wrote: > > > Am 25.11.20 um 11:40 schrieb Daniel Vetter: > > > > On Tue, Nov 24, 2020 at 05:44:07PM +0100, Christian König wrote: > > > > > Am 24.11.20 um 17:22 schrieb Andrey Grodzovsky: > > > > > > On 11/24/20 2:41 AM, Christian König wrote: > > > > > > > Am 23.11.20 um 22:08 schrieb Andrey Grodzovsky: > > > > > > > > On 11/23/20 3:41 PM, Christian König wrote: > > > > > > > > > Am 23.11.20 um 21:38 schrieb Andrey Grodzovsky: > > > > > > > > > > On 11/23/20 3:20 PM, Christian König wrote: > > > > > > > > > > > Am 23.11.20 um 21:05 schrieb Andrey Grodzovsky: > > > > > > > > > > > > On 11/25/20 5:42 AM, Christian König wrote: > > > > > > > > > > > > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky: > > > > > > > > > > > > > > It's needed to drop iommu backed pages on device > > > > > > > > > > > > > > unplug > > > > > > > > > > > > > > before device's IOMMU group is released. > > > > > > > > > > > > > It would be cleaner if we could do the whole > > > > > > > > > > > > > handling in TTM. I also need to double check > > > > > > > > > > > > > what you are doing with this function. > > > > > > > > > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > > > > > Check patch "drm/amdgpu: Register IOMMU topology > > > > > > > > > > > > notifier per device." to see > > > > > > > > > > > > how i use it. I don't see why this should go > > > > > > > > > > > > into TTM mid-layer - the stuff I do inside > > > > > > > > > > > > is vendor specific and also I don't think TTM is > > > > > > > > > > > > explicitly aware of IOMMU ? > > > > > > > > > > > > Do you mean you prefer the IOMMU notifier to be > > > > > > > > > > > > registered from within TTM > > > > > > > > > > > > and then use a hook to call into vendor specific > > > > > > > > > > > > handler ? > > > > > > > > > > > No, that is really vendor specific. > > > > > > > > > > > > > > > > > > > > > > What I meant is to have a function like > > > > > > > > > > > ttm_resource_manager_evict_all() which you only need > > > > > > > > > > > to call and all tt objects are unpopulated. > > > > > > > > > > So instead of this BO list i create and later iterate in > > > > > > > > > > amdgpu from the IOMMU patch you just want to do it > > > > > > > > > > within > > > > > > > > > > TTM with a single function ? Makes much more sense. > > > > > > > > > Yes, exactly. > > > > > > > > > > > > > > > > > > The list_empty() checks we have in TTM for the LRU are > > > > > > > > > actually not the best idea, we should now check the > > > > > > > > > pin_count instead. This way we could also have a list of the > > > > > > > > > pinned BOs in TTM. > > > > > > > > So from my IOMMU topology handler I will iterate the TTM LRU for > > > > > > > > the unpinned BOs and this new function for the pinned ones ? > > > > > > > > It's probably a good idea to combine both iterations into this > > > > > > > > new function to cover all the BOs allocated on the device. > > > > > > > Yes, that's what I had in my mind as well. > > > > > > > > > > > > > > > > BTW: Have you thought about what happens when we unpopulate > > > > > > > > > a BO while we still try to use a kernel mapping for it? That > > > > > > > > > could have unforeseen consequences. > > > > > > > > Are you asking what happens to kmap or vmap style mapped CPU > > > > > > > > accesses once we drop all the DMA backing pages for a particular > > > > > > > > BO ? Because for user mappings > > > > > > > > (mmap) we took care of this with dummy page reroute but indeed > > > > > > > > nothing was done for in kernel CPU mappings. > > > > > > > Yes exactly that. > > > > > > > > > > > > > > In other words what happens if we free the ring buffer while the > > > > > > > kernel still writes to it? > > > > > > > > > > > > > > Christian. > > > > > > While we can't control user application accesses to the mapped > > > > > > buffers > > > > > > explicitly and hence we use page fault rerouting > > > > > > I am thinking that in this case we may be able to sprinkle > > > > > > drm_dev_enter/exit in any such sensitive place were we might > > > > > > CPU access a DMA buffer from the kernel ? > > > > > Yes, I fear we are going to need that. > > > > Uh ... problem is that dma_buf_vmap are usually permanent things. Maybe > > > > we > > > > could stuff this into begin/end_cpu_access > > > Do you mean guarding with drm_dev_enter/exit in > dma_buf_ops.begin/end_cpu_access > driver specific hook ? > > > > > > (but only for the kernel, so a > > > > bit tricky)? > > > Why only kernel ? Why is it a problem to do it if it comes from dma_buf_ioctl > by > some user process ? And if we do need this distinction I think we should be > able to > differentiate by looking at current->mm (i.e. mm_struct) pointer being NULL > for kernel thread. Userspace mmap is handled by punching
[GIT PULL] drm/tegra: Fixes for v5.10-rc7
Hi Dave, The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.10-rc7 for you to fetch changes up to bf3a3cdcad40e5928a22ea0fd200d17fd6d6308d: drm/tegra: sor: Disable clocks on error in tegra_sor_init() (2020-11-26 18:44:48 +0100) I don't have a feature pull request for v5.11 since nothing really on the Tegra DRM side that was ready. The only thing that I've had in my tree were these couple of fixes for minor issues. They are mostly for non-critical bugs, so they don't necessarily need to go into v5.10 if you're not comfortable with it. However, they're all fixes, so they qualify and I didn't see a reason why they shouldn't go into v5.10. Thanks, Thierry drm/tegra: Fixes for v5.10-rc7 This is a set of small fixes for various issues found during the last couple of weeks. Deepak R Varma (1): drm/tegra: replace idr_init() by idr_init_base() Jon Hunter (1): drm/tegra: sor: Don't warn on probe deferral Marc Zyngier (1): drm/tegra: sor: Ensure regulators are disabled on teardown Qinglang Miao (1): drm/tegra: sor: Disable clocks on error in tegra_sor_init() Thierry Reding (1): drm/tegra: output: Do not put OF node twice drivers/gpu/drm/tegra/drm.c| 2 +- drivers/gpu/drm/tegra/output.c | 1 - drivers/gpu/drm/tegra/sor.c| 76 +++--- 3 files changed, 36 insertions(+), 43 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: imx: Move fbdev setup to before output polling
On Thu, Nov 26, 2020 at 09:44:02AM +, Jonas Mark (BT-FIR/ENG1-Grb) wrote: > Hi Daniel, > > > > Thank you very much for your feedback. We appreciate it. > > > > > > > >>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > > >>> b/drivers/gpu/drm/imx/imx-drm-core.c > > > > >>> index 9bf5ad6d18a2..2665040e11c7 100644 > > > > >>> --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > > >>> +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > > >>> @@ -240,14 +240,18 @@ static int imx_drm_bind(struct device *dev) > > > > >>>legacyfb_depth = 16; > > > > >>>} > > > > >>> > > > > >>> + /* > > > > >>> + * The generic fbdev has to be setup before enabling output > > > > >>> polling. > > > > >>> + * Otherwise the fbdev client is not ready to handle delayed > > > > >>> events. > > > > >>> + */ > > > > >>> + drm_fbdev_generic_setup(drm, legacyfb_depth); > > > > >>> + > > > > >>>drm_kms_helper_poll_init(drm); > > > > >>> > > > > >>>ret = drm_dev_register(drm, 0); > > > > >>>if (ret) > > > > >>>goto err_poll_fini; > > > > >>> > > > > >>> - drm_fbdev_generic_setup(drm, legacyfb_depth); > > > > >>> - > > > > >> > > > > >> This does not work well. fbdev is supposed to be another regular > > > > >> DRM client. It has to be enabled after registering the DRM device. > > > > >> > > > > >> I'd rather improve fbdev or the driver to handle this gracefully. > > > > > > > > > > Yeah I'm not understanding the point here. Once fbcon is running, > > > > > you have a screen. Any fbdev userspace client also should do a > > > > > modeset first. And if they dont and it's expected uapi for fbdev > > > > > chardev that the display boots up enabled, then we need to fix > > > > > that in the fbdev helpers, not through clever reordering in > > > > > drivers so that a side-effect causes a modeset. > > > > > > > > > > Note that this is a bit tricky since fbdev shouldn't take over the > > > > > screen by default, so we'd need to delay this until first open of > > > > > /dev/fb0. And we should probably also delay the hotplug handling > > > > > until the first open. fbcon also fake-opens the fbdev file, so > > > > > it's the same code path. > > > > > > > > As far as I understand the commit message, the problem is that the > > > > display blanks out after registering the driver. And fbdev somewhat > > > > mitigates this by doing an early modeset. Users with fbdev disabled > > > > (most of them in embedded, I guess) would still run into the issue > > > > until userspace makes a modeset. > > > > > > > > Mark, if that's the case, an option might be to pick up the device > > > > settings instead of calling drm_mode_config_reset(). The driver > > > > would then continue to display whatever is on the screen. > > > > > > We are started using fbdev in our embedded application with Linux > > > 3.10, later updated to 4.14 and are now in the process of updating to > > > 5.4. So far the uapi appeared to us as if we could rely on an already > > > enabled fbdev. That is, none of our applications does a modeset. > > > > > > When switching to 5.4 we noticed that the fbdev uapi changed. That is, > > > the LCD is switched off until it is explicitly enabled. It could be > > > enabled by writing to /sys/class/graphics/fb0/blank. > > > > > > You are right, we are not using fbcon. fbcon will still enable the LCD > > > but in our embedded domain we have it disabled because we must not show a > > console. > > > > > > Do we understand your proposal correctly to replace the call to > > > drm_mode_config_reset() in imx_drm_bind() [imx-drm-core.c] with > > > picking up the device settings instead? > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Felix > > > ir.bootlin.com%2Flinux%2Fv5.10- > > rc4%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Fim > > > x%2Fimx-drm- > > core.c%23L231data=04%7C01%7CMark.Jonas%40de.bosch.com > > > > > %7C9bbf5ede27ed40be9aaa08d88bac0c53%7C0ae51e1907c84e4bbb6d648ee > > 58410f4 > > > > > %7C0%7C0%7C637412918338819509%7CUnknown%7CTWFpbGZsb3d8eyJ > > WIjoiMC4wLjAw > > > > > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sd > > ata=68 > > > > > 1kOSAs2XsI1l4sOJ7j5UAGkAMciR78ma%2FgbD5jR98%3Dreserved=0 > > > > > > We are a little clueless right now: How do we pick up the device settings? > > > > Nope, not what I had in mind. > > > > Instead intercept the fb_ops->open call and in there if it's a userspace > > open > > (user parameter of the callback tells you that) and kms is not in use, then > > try to > > light up the display for the fbdev userspace to use. drm fbdev helpers > > already > > have that callback as drm_fbdev_fb_open(). I think you could try and just > > call > > drm_fbdev_client_hotplug directly, that should do the trick. Or maybe > > calling > > drm_fb_helper_dpms is the better option, not sure. fbmem.c seems to not > > store > > any blanking state at all, so this is probably all ill-defined. > > > > Important part is
Re: [PATCH] drm/radeon: fix check order in radeon_bo_move
Am 27.11.20 um 15:46 schrieb Daniel Vetter:
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
Am 27.11.20 um 09:31 schrieb Dave Airlie:
Oops sorry for delay LGTM
Reviewed-by: Dave Airlie
Thanks.
On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
On Wed, Nov 25, 2020 at 3:34 PM Christian König
wrote:
Reorder the code to fix checking if blitting is available.
Might be good to explain why blitting might not be available, e.g.
suspend/resume and or chip death and stuff like that.
Signed-off-by: Christian König
Needs Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")
Why does the subject of the patch needs to be in "()" ? I was already
wondering why dim sometimes complains about my Fixes tag.
Hm I thought that's the official style. I kinda hacked around on it
until linux-next stopped complaining about our Fixes: tags. Maybe it's
not quite accurately reflecting the current bikeshed. Iirc checkpatch
even complains when you leave out the commit before the sha1, at least
in free-form text in the commit message.
Well "git log -1 --oneline 28a68f828266" gives me:
28a68f828266 drm/radeon/ttm: use multihop
Which is what I would naturally expect here, but no idea what the
official format should be.
Christian.
-Daniel
Btw
$ dim fixes [sha1]
generates that for you plus nice cc list of offenders. With the Fixes
line added:
Reviewed-by: Daniel Vetter
Thanks,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix check order in radeon_bo_move
On Fri, Nov 27, 2020 at 3:10 PM Christian König
wrote:
>
> Am 27.11.20 um 09:31 schrieb Dave Airlie:
> > Oops sorry for delay LGTM
> >
> > Reviewed-by: Dave Airlie
>
> Thanks.
>
> >
> > On Fri, 27 Nov 2020 at 02:34, Daniel Vetter wrote:
> >> On Wed, Nov 25, 2020 at 3:34 PM Christian König
> >> wrote:
> >>> Reorder the code to fix checking if blitting is available.
> >> Might be good to explain why blitting might not be available, e.g.
> >> suspend/resume and or chip death and stuff like that.
> >>
> >>> Signed-off-by: Christian König
> >> Needs Fixes: 28a68f828266 ("drm/radeon/ttm: use multihop")
>
> Why does the subject of the patch needs to be in "()" ? I was already
> wondering why dim sometimes complains about my Fixes tag.
Hm I thought that's the official style. I kinda hacked around on it
until linux-next stopped complaining about our Fixes: tags. Maybe it's
not quite accurately reflecting the current bikeshed. Iirc checkpatch
even complains when you leave out the commit before the sha1, at least
in free-form text in the commit message.
-Daniel
> >>
> >> Btw
> >>
> >> $ dim fixes [sha1]
> >>
> >> generates that for you plus nice cc list of offenders. With the Fixes
> >> line added:
> >>
> >> Reviewed-by: Daniel Vetter
>
> Thanks,
> Christian.
>
> >>
> >> At least I'm hanging onto the illusion that I understand what you did here
> >> :-)
> >> -Daniel
> >>> ---
> >>> drivers/gpu/drm/radeon/radeon_ttm.c | 54 +
> >>> 1 file changed, 24 insertions(+), 30 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> b/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> index 0ca381b95d3d..2b598141225f 100644
> >>> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> @@ -216,27 +216,15 @@ static int radeon_bo_move(struct ttm_buffer_object
> >>> *bo, bool evict,
> >>> struct ttm_resource *old_mem = >mem;
> >>> int r;
> >>>
> >>> - if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> >>> -new_mem->mem_type == TTM_PL_VRAM) ||
> >>> - (old_mem->mem_type == TTM_PL_VRAM &&
> >>> -new_mem->mem_type == TTM_PL_SYSTEM)) {
> >>> - hop->fpfn = 0;
> >>> - hop->lpfn = 0;
> >>> - hop->mem_type = TTM_PL_TT;
> >>> - hop->flags = 0;
> >>> - return -EMULTIHOP;
> >>> - }
> >>> -
> >>> if (new_mem->mem_type == TTM_PL_TT) {
> >>> r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
> >>> if (r)
> >>> return r;
> >>> }
> >>> - radeon_bo_move_notify(bo, evict, new_mem);
> >>>
> >>> r = ttm_bo_wait_ctx(bo, ctx);
> >>> if (r)
> >>> - goto fail;
> >>> + return r;
> >>>
> >>> /* Can't move a pinned BO */
> >>> rbo = container_of(bo, struct radeon_bo, tbo);
> >>> @@ -246,12 +234,12 @@ static int radeon_bo_move(struct ttm_buffer_object
> >>> *bo, bool evict,
> >>> rdev = radeon_get_rdev(bo->bdev);
> >>> if (old_mem->mem_type == TTM_PL_SYSTEM && bo->ttm == NULL) {
> >>> ttm_bo_move_null(bo, new_mem);
> >>> - return 0;
> >>> + goto out;
> >>> }
> >>> if (old_mem->mem_type == TTM_PL_SYSTEM &&
> >>> new_mem->mem_type == TTM_PL_TT) {
> >>> ttm_bo_move_null(bo, new_mem);
> >>> - return 0;
> >>> + goto out;
> >>> }
> >>>
> >>> if (old_mem->mem_type == TTM_PL_TT &&
> >>> @@ -259,31 +247,37 @@ static int radeon_bo_move(struct ttm_buffer_object
> >>> *bo, bool evict,
> >>> radeon_ttm_tt_unbind(bo->bdev, bo->ttm);
> >>> ttm_resource_free(bo, >mem);
> >>> ttm_bo_assign_mem(bo, new_mem);
> >>> - return 0;
> >>> + goto out;
> >>> }
> >>> - if (!rdev->ring[radeon_copy_ring_index(rdev)].ready ||
> >>> - rdev->asic->copy.copy == NULL) {
> >>> - /* use memcpy */
> >>> - goto memcpy;
> >>> + if (rdev->ring[radeon_copy_ring_index(rdev)].ready &&
> >>> + rdev->asic->copy.copy != NULL) {
> >>> + if ((old_mem->mem_type == TTM_PL_SYSTEM &&
> >>> +new_mem->mem_type == TTM_PL_VRAM) ||
> >>> + (old_mem->mem_type == TTM_PL_VRAM &&
> >>> +new_mem->mem_type == TTM_PL_SYSTEM)) {
> >>> + hop->fpfn = 0;
> >>> + hop->lpfn = 0;
> >>> + hop->mem_type = TTM_PL_TT;
> >>> + hop->flags = 0;
> >>> + return -EMULTIHOP;
> >>> + }
> >>> +
> >>> + r = radeon_move_blit(bo, evict, new_mem, old_mem);
> >>> + } else {
> >>> + r = -ENODEV;
> >>> }
> >>>
> >>> - r =
Re: [Intel-gfx] [RFC PATCH 160/162] drm/i915/dg1: Fix GPU hang due to shmemfs page drop
Quoting Matthew Auld (2020-11-27 12:07:16)
> From: Venkata Ramana Nayana
>
> This is to fix a bug in upstream
> commit a6326a4f8ffb ("drm/i915/gt: Keep a no-frills swappable copy of the
> default context state")
>
> We allocate context state obj ce->state from lmem, so in
> __engines_record_defaults(),
> we call shmem_create_from_object(). Because it is lmem object, this call will
> create a new shmemfs file, copy the contents into it, and return the file
> pointer and assign to engine->default_state. Of course ce->state lmem object
> is freed at the end of function __engines_record_redefaults().
>
> Because a new shmemfs file is create for engine->default_state,
> and more importantly, we DON'T mark the pages dirty after we write into it,
> the OS page cache eviction will drop these pages.
>
> Now with the test move forward, it will create new request/context, and will
> copy the saved engine->default_state into ce->state. If the default_state
> pages are dropped during page cache eviction, the copying will get new pages,
> and copy garbage from the new pages. Next, ce->state will have wrong
> instruction and causes GPU to hang.
>
> The fixing is very simple, we just mark the shmemfs pages to be dirty when
> writing into it, and also mark the pages to accessed when read/write to them.
>
> Fixes: a6326a4f8ffb("drm/i915/gt: Keep a no-frills swappable copy of the
> default context state")
A bug fix, send it. But please write a concise changelog first.
I missed setting the dirty bit, and so the contents were not being saved
on swap out as expected. Impact is severe; any context created after
resume may be gibberish.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] soc / drm: mediatek: cmdq: Remove timeout handler in helper function
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
>
> Hi Chun-Kuang,
>
> On 20/11/2020 00:46, Chun-Kuang Hu wrote:
> > Hi, Matthias:
> >
> > I've provided the example for why of this patch. How do you think
> > about this patch?
> >
>
> Patch looks good to me. If you want to take it through your tree you can add
> my
> Acked-by: Matthias Brugger
>
> Beware that you might need a stable tag for it, so that I can merge it into my
> soc branch, in case there are more changes to cmdq-helper.
I would like this patch to go into your tree because this patch mainly
modify cmdq helper. Even though this patch is one of the series
"Mediatek DRM driver detect CMDQ execution timeout by vblank IRQ" [1],
I would wait for this patch get into mainline then send the next
patch.
Regards,
Chun-Kuang.
>
> Regards,
> Matthias
>
> > Regards,
> > Chun-Kuang.
> >
> > Chun-Kuang Hu 於 2020年11月2日 週一 上午8:04寫道：
> >>
> >> For each client driver, its timeout handler need to dump hardware register
> >> or its state machine information, and their way to detect timeout are
> >> also different, so remove timeout handler in helper function and
> >> let client driver implement its own timeout handler.
> >>
> >> Signed-off-by: Chun-Kuang Hu
> >> ---
> >> v1 is one patch in series "Mediatek DRM driver detect CMDQ execution
> >> timeout by vblank IRQ", but according to Jassi's suggestion [1], send
> >> each patch in different series.
> >>
> >> [2] is an example that different client has different way to calculate
> >> timeout. Some client driver care about each packet's execution time, but
> >> some client driver care about the total execution time for all packets.
> >>
> >> [1]
> >> https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
> >> [2]
> >> https://patchwork.kernel.org/project/linux-mediatek/patch/20201022094152.17662-1-houlong@mediatek.com/
> >>
> >> Changes in v2:
> >> 1. Rebase onto Linux 5.10-rc1
> >> ---
> >> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
> >> drivers/soc/mediatek/mtk-cmdq-helper.c | 41 +
> >> include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
> >> 3 files changed, 3 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >> index ac038572164d..4be5d1fccf2e 100644
> >> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> >> @@ -824,8 +824,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> >> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> >> mtk_crtc->cmdq_client =
> >> cmdq_mbox_create(mtk_crtc->mmsys_dev,
> >> -drm_crtc_index(_crtc->base),
> >> -2000);
> >> +drm_crtc_index(_crtc->base));
> >> if (IS_ERR(mtk_crtc->cmdq_client)) {
> >> dev_dbg(dev, "mtk_crtc %d failed to create mailbox
> >> client, writing register by CPU now\n",
> >> drm_crtc_index(_crtc->base));
> >> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >> index 505651b0d715..280d3bd9f675 100644
> >> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> >> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> >> @@ -70,14 +70,7 @@ int cmdq_dev_get_client_reg(struct device *dev,
> >> }
> >> EXPORT_SYMBOL(cmdq_dev_get_client_reg);
> >>
> >> -static void cmdq_client_timeout(struct timer_list *t)
> >> -{
> >> - struct cmdq_client *client = from_timer(client, t, timer);
> >> -
> >> - dev_err(client->client.dev, "cmdq timeout!\n");
> >> -}
> >> -
> >> -struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32
> >> timeout)
> >> +struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
> >> {
> >> struct cmdq_client *client;
> >>
> >> @@ -85,12 +78,6 @@ struct cmdq_client *cmdq_mbox_create(struct device
> >> *dev, int index, u32 timeout)
> >> if (!client)
> >> return (struct cmdq_client *)-ENOMEM;
> >>
> >> - client->timeout_ms = timeout;
> >> - if (timeout != CMDQ_NO_TIMEOUT) {
> >> - spin_lock_init(>lock);
> >> - timer_setup(>timer, cmdq_client_timeout, 0);
> >> - }
> >> - client->pkt_cnt = 0;
> >> client->client.dev = dev;
> >> client->client.tx_block = false;
> >> client->client.knows_txdone = true;
> >> @@ -112,11 +99,6 @@ EXPORT_SYMBOL(cmdq_mbox_create);
> >>
> >> void cmdq_mbox_destroy(struct cmdq_client *client)
> >> {
> >> - if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
> >> - spin_lock(>lock);
> >> - del_timer_sync(>timer);
> >> - spin_unlock(>lock);
> >> - }
> >> mbox_free_channel(client->chan);
> >> kfree(client);
> >> }
> >> @@ -449,18
Re: [Intel-gfx] [RFC PATCH 157/162] drm/i915: Improve accuracy of eviction stats
Quoting Matthew Auld (2020-11-27 12:07:13) > From: Tvrtko Ursulin > > Current code uses jiffie time to do the accounting and then does: > > diff = jiffies - start; > msec = diff * 1000 / HZ; > ... > atomic_long_add(msec, >time_swap_out_ms); > > If we assume jiffie can be as non-granular as 10ms and that the current > accounting records all evictions faster than one jiffie as infinite speed, > we can end up over-estimating the reported eviction throughput. > > Fix this by accumulating ktime_t and only dividing to more user friendly > granularity at presentation time (debugfs read). > > At the same time consolidate the code a bit and convert from multiple > atomics to single seqlock per stat. > > Signed-off-by: Tvrtko Ursulin > Cc: CQ Tang > Cc: Sudeep Dutt > Cc: Mika Kuoppala A lot of effort to fix up patches after the fact, might as well make it a real PMU interface. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 150/162] drm/i915: need consider system BO snoop for dgfx
Quoting Matthew Auld (2020-11-27 12:07:06)
> From: CQ Tang
>
> When cache_level is NONE, we check HAS_LLC(i915).
> But additionally for DGFX, we also need to check
> HAS_SNOOP(i915) on system memory object to use
> I915_BO_CACHE_COHERENT_FOR_READ. on dg1, has_llc=0, and
> has_snoop=1. Otherwise, we set obj->cache_choerent=0 and
> have performance impact.
>
> Cc: Chris P Wilson
> Cc: Ramalingam C
> Cc: Sudeep Dutt
> Cc: Matthew Auld
> Signed-off-by: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index ddb448f275eb..be603171c444 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -95,6 +95,20 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
> mutex_init(>mm.get_dma_page.lock);
> }
>
> +static bool i915_gem_object_use_llc(struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +
> + if (HAS_LLC(i915))
> + return true;
> +
> + if (IS_DGFX(i915) && HAS_SNOOP(i915) &&
> + !i915_gem_object_is_lmem(obj))
> + return true;
> +
> + return false;
> +}
> +
> /**
> * Mark up the object's coherency levels for a given cache_level
> * @obj: #drm_i915_gem_object
> @@ -108,7 +122,7 @@ void i915_gem_object_set_cache_coherency(struct
> drm_i915_gem_object *obj,
> if (cache_level != I915_CACHE_NONE)
> obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
>I915_BO_CACHE_COHERENT_FOR_WRITE);
> - else if (HAS_LLC(to_i915(obj->base.dev)))
> + else if (i915_gem_object_use_llc(obj))
> obj->cache_coherent = I915_BO_CACHE_COHERENT_FOR_READ;
> else
> obj->cache_coherent = 0;
You must also define obj->cache_level correctly. You can not just assume
the object will be snooped.
-Chris
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 148/162] drm/i915: suspend/resume enable blitter eviction
Quoting Matthew Auld (2020-11-27 12:07:04) > From: Venkata Ramana Nayana > > In suspend mode use blitter eviction before disable the runtime > interrupts and in resume use blitter after the gem resume happens. Consider add it to the suspend prepare function. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
