Re: [PATCH v11 3/9] drm/mediatek: add RDMA fifo size error handle
Hi, Hsin-Yi: On Thu, 2021-01-28 at 15:27 +0800, Hsin-Yi Wang wrote: > From: Yongqiang Niu > > This patch add RDMA fifo size error handle > rdma fifo size will not always bigger than the calculated threshold > if that case happened, we need set fifo size as the threshold > > Signed-off-by: Yongqiang Niu > Signed-off-by: Hsin-Yi Wang > --- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > index b84004394970f..04b9542010b00 100644 > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > @@ -168,6 +168,10 @@ void mtk_rdma_config(struct device *dev, unsigned int > width, >* account for blanking, and with a pixel depth of 4 bytes: >*/ > threshold = width * height * vrefresh * 4 * 7 / 100; > + > + if (threshold > rdma_fifo_size) > + threshold = rdma_fifo_size; > + Please see the discussion in [1]. [1] https://patchwork.kernel.org/project/linux-mediatek/patch/1607591262-21736-6-git-send-email-yongqiang@mediatek.com/ Regards, CK > reg = RDMA_FIFO_UNDERFLOW_EN | > RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) | > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 0/3] add ttm trace event support
Not a bad start, but that needs quite some more work. First of all please rebase on top of current drm-misc-next, a whole bunch of the stuff you want to trace here was already removed or is about to be removed. Then concentrate on the necessary trace points, for example ttm:ttm_bo_device_init/release are overkill. On the other hand I'm missing important events like pool shrink, tt swapout/swapin (ttm_bo_swapout can be dropped) and especially BO init. I would separate the patches into one for each trace point. Not a must have, but it could make it easier to review and we can discuss for each one separately. Thanks, Christian. Am 28.01.21 um 08:13 schrieb Kevin Wang: the kernel ftrace can better help analyze the kernel running status. add some trace events to support TTM. add trace events list: ttm:ttm_bo_add_mem_to_lru ttm:ttm_bo_del_from_lru ttm:ttm_bo_move_mem ttm:ttm_bo_wait ttm:ttm_bo_evict ttm:ttm_bo_swapout ttm:ttm_bo_device_init ttm:ttm_bo_device_release ttm:ttm_bo_init_reserved ttm:ttm_bo_validate ttm:ttm_bo_release ttm:ttm_bo_mmap ttm:ttm_bo_vm_fault ttm:ttm_bo_vm_access ttm:ttm_shrink ttm:ttm_mem_global_reserve ttm:ttm_mem_global_free Kevin Wang (3): drm/ttm: add ttm bo trace event support drm/ttm: add ttm vm bo trace event support drm/ttm: add ttm mem trace event support drivers/gpu/drm/ttm/ttm_bo.c | 23 ++ drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 +- drivers/gpu/drm/ttm/ttm_memory.c | 7 + drivers/gpu/drm/ttm/ttm_module.c | 3 + drivers/gpu/drm/ttm/ttm_trace.h | 469 +++ 5 files changed, 512 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_trace.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 8/9] soc: mediatek: add mtk mutex support for MT8183
Hi, Hsin-Yi:
On Thu, 2021-01-28 at 15:28 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Add mtk mutex support for MT8183 SoC.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/soc/mediatek/mtk-mutex.c | 50
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-mutex.c
> b/drivers/soc/mediatek/mtk-mutex.c
> index f531b119da7a9..b348f962f82a4 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -14,6 +14,8 @@
>
> #define MT2701_MUTEX0_MOD0 0x2c
> #define MT2701_MUTEX0_SOF0 0x30
> +#define MT8183_DISP_MUTEX0_MOD0 0x30
> +#define MT8183_DISP_MUTEX0_SOF0 0x2c
Modify 'DISP_MUTEX' to 'MUTEX'
Regards,
CK
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> @@ -37,6 +39,18 @@
> #define MT8167_MUTEX_MOD_DISP_DITHER 15
> #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8183_MUTEX_MOD_DISP_RDMA0 0
> +#define MT8183_MUTEX_MOD_DISP_RDMA1 1
> +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> +#define MT8183_MUTEX_MOD_DISP_OVL0_2L10
> +#define MT8183_MUTEX_MOD_DISP_OVL1_2L11
> +#define MT8183_MUTEX_MOD_DISP_WDMA0 12
> +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> +#define MT8183_MUTEX_MOD_DISP_DITHER017
> +
> #define MT8173_MUTEX_MOD_DISP_OVL0 11
> #define MT8173_MUTEX_MOD_DISP_OVL1 12
> #define MT8173_MUTEX_MOD_DISP_RDMA0 13
> @@ -87,6 +101,11 @@
> #define MT2712_MUTEX_SOF_DSI36
> #define MT8167_MUTEX_SOF_DPI02
> #define MT8167_MUTEX_SOF_DPI13
> +#define MT8183_MUTEX_SOF_DSI01
> +#define MT8183_MUTEX_SOF_DPI02
> +
> +#define MT8183_MUTEX_EOF_DSI0(MT8183_MUTEX_SOF_DSI0
> << 6)
> +#define MT8183_MUTEX_EOF_DPI0(MT8183_MUTEX_SOF_DPI0
> << 6)
>
> struct mtk_mutex {
> int id;
> @@ -181,6 +200,20 @@ static const unsigned int
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> +};
> +
> static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -198,6 +231,13 @@ static const unsigned int
> mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> };
>
> +/* Add EOF setting so overlay hardware can receive frame done irq */
> +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> + [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> + [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> + [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
> +};
> +
> static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -227,6 +267,14 @@ static const struct mtk_mutex_data
> mt8173_mutex_driver_data = {
> .mutex_sof_reg = MT2701_MUTEX0_SOF0,
> };
>
> +static const struct mtk_mutex_data mt8183_mutex_driver_data = {
> + .mutex_mod = mt8183_mutex_mod,
> + .mutex_sof = mt8183_mutex_sof,
> + .mutex_mod_reg = MT8183_DISP_MUTEX0_MOD0,
> + .mutex_sof_reg = MT8183_DISP_MUTEX0_SOF0,
> + .no_clk = true,
> +};
> +
> struct mtk_mutex *mtk_mutex_get(struct device *dev)
> {
> struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
> @@ -457,6 +505,8 @@ static const struct of_device_id mutex_driver_dt_match[]
> = {
> .data = _mutex_driver_data},
> { .compatible = "mediatek,mt8173-disp-mutex",
> .data = _mutex_driver_data},
> + { .compatible = "mediatek,mt8183-disp-mutex",
> + .data = _mutex_driver_data},
> {},
> };
>
Re: [PATCH v11 7/9] drm/mediatek: enable dither function
Hi, Hsin-Yi:
On Thu, 2021-01-28 at 15:28 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> for 5 or 6 bpc panel, we need enable dither function
> to improve the display quality
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 44 -
> 1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 8173f709272be..e85625704d611 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -53,7 +53,9 @@
> #define DITHER_ENBIT(0)
> #define DISP_DITHER_CFG 0x0020
> #define DITHER_RELAY_MODEBIT(0)
> +#define DITHER_ENGINE_EN BIT(1)
> #define DISP_DITHER_SIZE 0x0030
> +#define DITHER_REG(idx) (0x100 + (idx) * 4)
>
> #define LUT_10BIT_MASK 0x03ff
>
> @@ -313,8 +315,48 @@ static void mtk_dither_config(struct device *dev,
> unsigned int w,
> {
> struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> + bool enable = false;
> +
> + /* default value for dither reg 5 to 14 */
> + const u32 dither_setting[] = {
> + 0x, /* 5 */
> + 0x3002, /* 6 */
> + 0x, /* 7 */
> + 0x, /* 8 */
> + 0x, /* 9 */
> + 0x, /* 10 */
> + 0x, /* 11 */
> + 0x0011, /* 12 */
> + 0x, /* 13 */
> + 0x, /* 14 */
Could you explain what is this?
> + };
> +
> + if (bpc == 5 || bpc == 6) {
> + enable = true;
> + mtk_ddp_write(cmdq_pkt,
> + DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
> + DITHER_ADD_LSHIFT_R(MTK_MAX_BPC - bpc) |
> + DITHER_NEW_BIT_MODE,
> + >cmdq_reg, priv->regs, DITHER_REG(15));
> + mtk_ddp_write(cmdq_pkt,
> + DITHER_LSB_ERR_SHIFT_B(MTK_MAX_BPC - bpc) |
> + DITHER_ADD_LSHIFT_B(MTK_MAX_BPC - bpc) |
> + DITHER_LSB_ERR_SHIFT_G(MTK_MAX_BPC - bpc) |
> + DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
This result in 0x50505050, but previous version is 0x50504040, so this
version is correct and previous version is incorrect?
Regards,
CK
> + >cmdq_reg, priv->regs, DITHER_REG(16));
> + }
> +
> +
> + if (enable) {
> + u32 idx;
> +
> + for (idx = 0; idx < ARRAY_SIZE(dither_setting); idx++)
> + mtk_ddp_write(cmdq_pkt, dither_setting[idx],
> >cmdq_reg, priv->regs,
> + DITHER_REG(idx + 5));
> + }
> +
> mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> DISP_DITHER_SIZE);
> - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg, priv->regs,
> DISP_DITHER_CFG);
> +mtk_ddp_write(cmdq_pkt, enable ? DITHER_ENGINE_EN :
> DITHER_RELAY_MODE, >cmdq_reg, priv->regs, DISP_DITHER_CFG);
> }
>
> static void mtk_dither_start(struct device *dev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 4/9] drm/mediatek: add mtk_dither_set_common() function
On Thu, 2021-01-28 at 15:27 +0800, Hsin-Yi Wang wrote:
> Current implementation of mtk_dither_set() cast dev data to
> struct mtk_ddp_comp_dev. But other devices with different dev data
> would also call this function.
>
> Separate necessary parameters out so other device components (dither,
> gamma) can call this function.
Reviewed-by: CK Hu
>
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 25 +
> 2 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 46d199b7b4a29..c50d5fc9fd349 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -17,6 +17,10 @@ void mtk_color_config(struct device *dev, unsigned int w,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> void mtk_color_start(struct device *dev);
>
> +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> *cmdq_reg,
> +unsigned int bpc, unsigned int CFG,
> +struct cmdq_pkt *cmdq_pkt);
> +
> void mtk_dpi_start(struct device *dev);
> void mtk_dpi_stop(struct device *dev);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 7b5293429426d..53d25823a37cc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -151,33 +151,40 @@ static void mtk_ddp_clk_disable(struct device *dev)
> clk_disable_unprepare(priv->clk);
> }
>
> -static void mtk_dither_set(struct device *dev, unsigned int bpc,
> - unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> -{
> - struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> *cmdq_reg,
> +unsigned int bpc, unsigned int CFG, struct cmdq_pkt
> *cmdq_pkt)
> +{
> /* If bpc equal to 0, the dithering function didn't be enabled */
> if (bpc == 0)
> return;
>
> if (bpc >= MTK_MIN_BPC) {
> - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> DISP_DITHER_5);
> - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> DISP_DITHER_7);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_5);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_7);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_NEW_BIT_MODE,
> - >cmdq_reg, priv->regs, DISP_DITHER_15);
> + cmdq_reg, regs, DISP_DITHER_15);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_LSB_ERR_SHIFT_G(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> - >cmdq_reg, priv->regs, DISP_DITHER_16);
> - mtk_ddp_write(cmdq_pkt, DISP_DITHERING, >cmdq_reg,
> priv->regs, CFG);
> + cmdq_reg, regs, DISP_DITHER_16);
> + mtk_ddp_write(cmdq_pkt, DISP_DITHERING, cmdq_reg, regs, CFG);
> }
> }
>
> +static void mtk_dither_set(struct device *dev, unsigned int bpc,
> + unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc, CFG, cmdq_pkt);
> +}
> +
> static void mtk_od_config(struct device *dev, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] RFC: dma-fence: Document recoverable page fault implications
Am 27.01.21 um 23:00 schrieb Felix Kuehling: Am 2021-01-27 um 7:16 a.m. schrieb Christian König: Am 27.01.21 um 13:11 schrieb Maarten Lankhorst: Op 27-01-2021 om 01:22 schreef Felix Kuehling: Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7Cbee0aeff80f440bcc52108d8c2bcc11f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637473463245588199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ncr%2Fqv5lw0ONrYxFvfdcFAXAZ%2BXcJJa6UY%2BxGfcKGVM%3Dreserved=0 Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: "Christian König" Cc: Jerome Glisse Cc: Felix Kuehling Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. I thought of another possible
[RFC PATCH 2/3] drm/ttm: add ttm vm bo trace event support
add ttm bo VM related trace event support
trace events:
ttm:ttm_bo_mmap
ttm:ttm_bo_vm_fault
ttm:ttm_bo_vm_access
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 -
drivers/gpu/drm/ttm/ttm_trace.h | 78 +
2 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 01693e8f24b7..aece2024c1fd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -42,6 +42,8 @@
#include
#include
+#include "ttm_trace.h"
+
static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
@@ -429,15 +431,17 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
- return ret;
+ goto out;
prot = vma->vm_page_prot;
ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
- return ret;
+ goto out;
dma_resv_unlock(bo->base.resv);
+out:
+ trace_ttm_bo_vm_fault(bo, vmf, ret);
return ret;
}
EXPORT_SYMBOL(ttm_bo_vm_fault);
@@ -516,6 +520,8 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
if (ret)
return ret;
+ trace_ttm_bo_vm_access(bo, !!write, offset, len);
+
switch (bo->mem.mem_type) {
case TTM_PL_SYSTEM:
if (unlikely(bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)) {
@@ -618,6 +624,7 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
*vma,
goto out_unref;
ttm_bo_mmap_vma_setup(bo, vma);
+ trace_ttm_bo_mmap(bo, vma);
return 0;
out_unref:
ttm_bo_put(bo);
@@ -629,6 +636,7 @@ int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct
ttm_buffer_object *bo)
{
ttm_bo_get(bo);
ttm_bo_mmap_vma_setup(bo, vma);
+ trace_ttm_bo_mmap(bo, vma);
return 0;
}
EXPORT_SYMBOL(ttm_bo_mmap_obj);
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
index 7c5e55725e8e..9f7cc34b243b 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#define TTM_PLACEMENT_FLAGS_TRACE \
{ TTM_PL_FLAG_SYSTEM, "SYSTEM"},\
@@ -310,6 +311,83 @@ TRACE_EVENT(ttm_bo_release,
TP_printk("bo:%p", __entry->bo)
);
+TRACE_EVENT(ttm_bo_mmap,
+ TP_PROTO(struct ttm_buffer_object *bo, struct vm_area_struct *vma),
+ TP_ARGS(bo, vma),
+ TP_STRUCT__entry(
+__field(struct ttm_buffer_object *, bo)
+__field(unsigned long, vm_start)
+__field(unsigned long, vm_end)
+__field(unsigned long, vm_pgoff)
+__field(unsigned long, vm_flags)
+),
+
+ TP_fast_assign(
+ __entry->bo = bo;
+ __entry->vm_start = vma->vm_start;
+ __entry->vm_end = vma->vm_end;
+ __entry->vm_pgoff = vma->vm_pgoff;
+ __entry->vm_flags = vma->vm_flags;
+ ),
+
+ TP_printk("bo:%p, vm_start=%lx, vm_end=%lx, vm_pgoff=%lx,
vm_flags=%s",
+ __entry->bo,
+ __entry->vm_start, __entry->vm_end, __entry->vm_pgoff,
+ show_vma_flags(__entry->vm_flags))
+);
+
+TRACE_EVENT(ttm_bo_vm_fault,
+ TP_PROTO(struct ttm_buffer_object *bo, struct vm_fault *vmf, int
result),
+ TP_ARGS(bo, vmf, result),
+ TP_STRUCT__entry(
+__field(struct ttm_buffer_object *, bo)
+__field(struct vm_area_struct *, vma)
+__field(unsigned long, fault_address)
+__field(unsigned long, fault_pgoff)
+__field(int, result)
+__field(unsigned int, flags)
+),
+
+ TP_fast_assign(
+ __entry->bo = bo;
+ __entry->vma = vmf->vma;
+ __entry->fault_address = vmf->address;
+ __entry->fault_pgoff = vmf->pgoff;
+ __entry->flags = vmf->flags;
+ __entry->result = result;
+ ),
+
+ TP_printk("bo:%p, vma=%p, fault_address=%lx, fault_pgoff=%lx,
fault_flags=%s %s",
+ __entry->bo, __entry->vma,
+ __entry->fault_address, __entry->fault_pgoff,
+ __entry->flags ? __print_flags(__entry->flags, "|",
[RFC PATCH 3/3] drm/ttm: add ttm mem trace event support
add ttm memory related trace event support
trace events:
ttm:ttm_shrink
ttm:ttm_mem_global_reserve
ttm:ttm_mem_global_free
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/ttm/ttm_memory.c | 7
drivers/gpu/drm/ttm/ttm_trace.h | 70
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index acd63b70d814..27470b1f1f13 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -39,6 +39,8 @@
#include
#include
+#include "ttm_trace.h"
+
#define TTM_MEMORY_ALLOC_RETRIES 4
struct ttm_mem_global ttm_mem_glob;
@@ -272,6 +274,7 @@ static void ttm_shrink(struct ttm_mem_global *glob, bool
from_wq,
int ret;
spin_lock(>lock);
+ trace_ttm_shrink(from_wq, extra, ctx);
while (ttm_zones_above_swap_target(glob, from_wq, extra)) {
spin_unlock(>lock);
@@ -518,6 +521,8 @@ static void ttm_mem_global_free_zone(struct ttm_mem_global
*glob,
zone->used_mem -= amount;
}
spin_unlock(>lock);
+ trace_ttm_mem_global_free(single_zone->name, amount,
+ single_zone->used_mem, single_zone->max_mem);
}
void ttm_mem_global_free(struct ttm_mem_global *glob,
@@ -590,6 +595,8 @@ static int ttm_mem_global_reserve(struct ttm_mem_global
*glob,
ret = 0;
out_unlock:
spin_unlock(>lock);
+ trace_ttm_mem_global_reserve(single_zone->name, amount,
+ single_zone->used_mem, single_zone->max_mem);
ttm_check_swapping(glob);
return ret;
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
index 9f7cc34b243b..e25b8a2c423c 100644
--- a/drivers/gpu/drm/ttm/ttm_trace.h
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -388,6 +388,76 @@ TRACE_EVENT(ttm_bo_vm_access,
__entry->offset, __entry->len, __entry->mem_type)
);
+TRACE_EVENT(ttm_shrink,
+ TP_PROTO(bool from_wq, uint64_t extra, struct ttm_operation_ctx
*ctx),
+ TP_ARGS(from_wq, extra, ctx),
+ TP_STRUCT__entry(
+__field(bool, from_wq)
+__field(bool, interruptible)
+__field(bool, wait_gpu)
+__field(uint64_t, extra)
+),
+
+ TP_fast_assign(
+ __entry->from_wq = from_wq;
+ __entry->extra = extra;
+ __entry->interruptible= ctx->interruptible;
+ __entry->wait_gpu = !ctx->no_wait_gpu;
+ ),
+
+ TP_printk("ttm_shrink: from_wq=%s, interruptible=%s, wait_gpu=%s,
extra=0x%llx(%lld)",
+ __entry->from_wq ? "true" : "false",
+ __entry->interruptible ? "true" : "false",
+ __entry->wait_gpu? "true" : "false",
+ __entry->extra, __entry->extra)
+);
+
+TRACE_EVENT(ttm_mem_global_reserve,
+ TP_PROTO(const char *zone_name, uint64_t amount,
+uint64_t used_mem, uint64_t max_mem),
+ TP_ARGS(zone_name, amount, used_mem, max_mem),
+ TP_STRUCT__entry(
+__string(zone, zone_name)
+__field(uint64_t, amount)
+__field(uint64_t, used_mem)
+__field(uint64_t, max_mem)
+),
+
+ TP_fast_assign(
+ __assign_str(zone, zone_name);
+ __entry->amount = amount;
+ __entry->used_mem = used_mem;
+ __entry->max_mem = max_mem;
+ ),
+
+ TP_printk("zone:%s, amount=%lld, used=%lld/%lld",
+ __get_str(zone), __entry->amount,
+ __entry->used_mem, __entry->max_mem)
+);
+
+TRACE_EVENT(ttm_mem_global_free,
+ TP_PROTO(const char *zone_name, uint64_t amount,
+uint64_t used_mem, uint64_t max_mem),
+ TP_ARGS(zone_name, amount, used_mem, max_mem),
+ TP_STRUCT__entry(
+__string(zone, zone_name)
+__field(uint64_t, amount)
+__field(uint64_t, used_mem)
+__field(uint64_t, max_mem)
+),
+
+ TP_fast_assign(
+ __assign_str(zone, zone_name);
+ __entry->amount = amount;
+ __entry->used_mem = used_mem;
+ __entry->max_mem = max_mem;
+ ),
+
+ TP_printk("zone:%s, amount=%lld, used=%lld/%lld",
+ __get_str(zone), __entry->amount,
+ __entry->used_mem, __entry->max_mem)
+);
+
#endif
#undef
[RFC PATCH 1/3] drm/ttm: add ttm bo trace event support
add ttm bo related trace event support
trace events:
ttm:ttm_bo_add_mem_to_lru
ttm:ttm_bo_del_from_lru
ttm:ttm_bo_move_mem
ttm:ttm_bo_wait
ttm:ttm_bo_evict
ttm:ttm_bo_swapout
ttm:ttm_bo_device_init
ttm:ttm_bo_device_release
ttm:ttm_bo_init_reserved
ttm:ttm_bo_validate
ttm:ttm_bo_release
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/ttm/ttm_bo.c | 23 +++
drivers/gpu/drm/ttm/ttm_module.c | 3 +
drivers/gpu/drm/ttm/ttm_trace.h | 321 +++
3 files changed, 347 insertions(+)
create mode 100644 drivers/gpu/drm/ttm/ttm_trace.h
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e3931e515906..074afd05aaa8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -43,6 +43,8 @@
#include
#include
+#include "ttm_trace.h"
+
static void ttm_bo_global_kobj_release(struct kobject *kobj);
/**
@@ -143,6 +145,8 @@ static void ttm_bo_add_mem_to_lru(struct ttm_buffer_object
*bo,
if (mem->placement & TTM_PL_FLAG_NO_EVICT)
return;
+ trace_ttm_bo_add_mem_to_lru(bo, mem);
+
man = ttm_manager_type(bdev, mem->mem_type);
list_add_tail(>lru, >lru[bo->priority]);
@@ -167,6 +171,8 @@ static void ttm_bo_del_from_lru(struct ttm_buffer_object
*bo)
notify = true;
}
+ trace_ttm_bo_del_from_lru(bo, notify);
+
if (notify && bdev->driver->del_from_lru_notify)
bdev->driver->del_from_lru_notify(bo);
}
@@ -299,6 +305,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
}
+ trace_ttm_bo_move_mem(bo, mem, evict);
+
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
@@ -542,6 +550,8 @@ static void ttm_bo_release(struct kref *kref)
size_t acc_size = bo->acc_size;
int ret;
+ trace_ttm_bo_release(bo);
+
if (!bo->deleted) {
ret = ttm_bo_individualize_resv(bo);
if (ret) {
@@ -668,6 +678,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
ttm_resource_free(bo, _mem);
goto out;
}
+
+ trace_ttm_bo_evict(bo, _mem);
bo->evicted = true;
out:
return ret;
@@ -1151,6 +1163,8 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
dma_resv_assert_held(bo->base.resv);
+ trace_ttm_bo_validate(bo);
+
/*
* Remove the backing store if no placement is given.
*/
@@ -1263,6 +1277,8 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
}
atomic_inc(_bo_glob.bo_count);
+ trace_ttm_bo_init_reserved(bo, size);
+
/*
* For ttm_bo_type_device buffers, allocate
* address space from the device.
@@ -1487,6 +1503,8 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
if (!ret)
ttm_bo_global_release();
+ trace_ttm_bo_device_release(bdev);
+
return ret;
}
EXPORT_SYMBOL(ttm_bo_device_release);
@@ -1537,6 +1555,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
list_add_tail(>device_list, >device_list);
mutex_unlock(_global_mutex);
+ trace_ttm_bo_device_init(bdev);
+
return 0;
}
EXPORT_SYMBOL(ttm_bo_device_init);
@@ -1580,6 +1600,8 @@ int ttm_bo_wait(struct ttm_buffer_object *bo,
timeout = dma_resv_wait_timeout_rcu(bo->base.resv, true,
interruptible, timeout);
+
+ trace_ttm_bo_wait(bo, interruptible, timeout);
if (timeout < 0)
return timeout;
@@ -1670,6 +1692,7 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct
ttm_operation_ctx *ctx)
* anyone tries to access a ttm page.
*/
+ trace_ttm_bo_swapout(bo, i);
if (bo->bdev->driver->swap_notify)
bo->bdev->driver->swap_notify(bo);
diff --git a/drivers/gpu/drm/ttm/ttm_module.c b/drivers/gpu/drm/ttm/ttm_module.c
index 6ff40c041d79..8b70e8aebecb 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -35,6 +35,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include "ttm_trace.h"
+
static DECLARE_WAIT_QUEUE_HEAD(exit_q);
static atomic_t device_released;
diff --git a/drivers/gpu/drm/ttm/ttm_trace.h b/drivers/gpu/drm/ttm/ttm_trace.h
new file mode 100644
index ..7c5e55725e8e
--- /dev/null
+++ b/drivers/gpu/drm/ttm/ttm_trace.h
@@ -0,0 +1,321 @@
+/*
+ * Copyright 2021 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the
[RFC PATCH 0/3] add ttm trace event support
the kernel ftrace can better help analyze the kernel running status. add some trace events to support TTM. add trace events list: ttm:ttm_bo_add_mem_to_lru ttm:ttm_bo_del_from_lru ttm:ttm_bo_move_mem ttm:ttm_bo_wait ttm:ttm_bo_evict ttm:ttm_bo_swapout ttm:ttm_bo_device_init ttm:ttm_bo_device_release ttm:ttm_bo_init_reserved ttm:ttm_bo_validate ttm:ttm_bo_release ttm:ttm_bo_mmap ttm:ttm_bo_vm_fault ttm:ttm_bo_vm_access ttm:ttm_shrink ttm:ttm_mem_global_reserve ttm:ttm_mem_global_free Kevin Wang (3): drm/ttm: add ttm bo trace event support drm/ttm: add ttm vm bo trace event support drm/ttm: add ttm mem trace event support drivers/gpu/drm/ttm/ttm_bo.c | 23 ++ drivers/gpu/drm/ttm/ttm_bo_vm.c | 12 +- drivers/gpu/drm/ttm/ttm_memory.c | 7 + drivers/gpu/drm/ttm/ttm_module.c | 3 + drivers/gpu/drm/ttm/ttm_trace.h | 469 +++ 5 files changed, 512 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/ttm/ttm_trace.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 8/9] drm/mediatek: add DDP support for MT8183
On Thu, 2021-01-28 at 14:15 +0800, Hsin-Yi Wang wrote:
> On Thu, Jan 28, 2021 at 2:13 PM CK Hu wrote:
> >
> > Hi, Hsin-Yi:
> >
> > Modify the title's prefix to 'soc: mediatek:'
> >
> > On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> > > From: Yongqiang Niu
> > >
> > > Add DDP support for MT8183 SoC.
> > >
> > > Signed-off-by: Yongqiang Niu
> > > Signed-off-by: Hsin-Yi Wang
> > > ---
> > > drivers/soc/mediatek/mtk-mutex.c | 50
> > > 1 file changed, 50 insertions(+)
> > >
> > > diff --git a/drivers/soc/mediatek/mtk-mutex.c
> > > b/drivers/soc/mediatek/mtk-mutex.c
> > > index f531b119da7a9..f64e9c33e85ad 100644
> > > --- a/drivers/soc/mediatek/mtk-mutex.c
> > > +++ b/drivers/soc/mediatek/mtk-mutex.c
> > > @@ -14,6 +14,8 @@
> > >
> > > #define MT2701_MUTEX0_MOD0 0x2c
> > > #define MT2701_MUTEX0_SOF0 0x30
> > > +#define MT8183_DISP_MUTEX0_MOD0 0x30
> > > +#define MT8183_DISP_MUTEX0_SOF0 0x2c
> >
> > Modify 'DISP_MUTEX' to 'MUTEX'
> >
> > >
> > > #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> > > #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> > > @@ -37,6 +39,18 @@
> > > #define MT8167_MUTEX_MOD_DISP_DITHER 15
> > > #define MT8167_MUTEX_MOD_DISP_UFOE 16
> > >
> > > +#define MT8183_MUTEX_MOD_DISP_RDMA0 0
> > > +#define MT8183_MUTEX_MOD_DISP_RDMA1 1
> > > +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> > > +#define MT8183_MUTEX_MOD_DISP_OVL0_2L10
> > > +#define MT8183_MUTEX_MOD_DISP_OVL1_2L11
> > > +#define MT8183_MUTEX_MOD_DISP_WDMA0 12
> > > +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> > > +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> > > +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> > > +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> > > +#define MT8183_MUTEX_MOD_DISP_DITHER017
> > > +
> > > #define MT8173_MUTEX_MOD_DISP_OVL0 11
> > > #define MT8173_MUTEX_MOD_DISP_OVL1 12
> > > #define MT8173_MUTEX_MOD_DISP_RDMA0 13
> > > @@ -87,6 +101,12 @@
> > > #define MT2712_MUTEX_SOF_DSI36
> > > #define MT8167_MUTEX_SOF_DPI02
> > > #define MT8167_MUTEX_SOF_DPI13
> > > +#define MT8183_MUTEX_SOF_DSI01
> > > +#define MT8183_MUTEX_SOF_DPI02
> > > +
> > > +/* Add EOF setting so overlay hardware can receive frame done irq */
> > > +#define MT8183_MUTEX_EOF_DSI0
> > > (MT8183_MUTEX_SOF_DSI0 << 6)
> > > +#define MT8183_MUTEX_EOF_DPI0
> > > (MT8183_MUTEX_SOF_DPI0 << 6)
> > >
>
> Hi CK, comment is added here. I can move to mt8183_mutex_sof if preferred.
I prefer to move comment to mt8183_mutex_sof.
>
> > > struct mtk_mutex {
> > > int id;
> > > @@ -181,6 +201,20 @@ static const unsigned int
> > > mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > > [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> > > };
> > >
> > > +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > > + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> > > + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> > > + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> > > + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> > > + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> > > + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> > > + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> > > + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> > > + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> > > + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> > > + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> > > +};
> > > +
> > > static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > > [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > > [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> > > @@ -198,6 +232,12 @@ static const unsigned int
> > > mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > > [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> > > };
> > >
> > > +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > > + [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > > + [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> > > + [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
> >
> > According to discussion in [1], add comment for the odd EOF setting.
> >
> > [1]
> > https://patchwork.kernel.org/project/linux-mediatek/patch/1595469798-3824-8-git-send-email-yongqiang@mediatek.com/
> >
> > Regards,
> > CK.
> >
> >
> > > +};
> > > +
> > > static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> > > .mutex_mod = mt2701_mutex_mod,
> > > .mutex_sof
[PATCH v3 3/3] dma-buf: system_heap: Add deferred freeing to the system heap
Utilize the deferred free helper library in the system heap.
This provides a nice performance bump and puts the
system heap performance on par with ION.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Rework deferred-free api to use reason enum as suggested by
Suren Baghdasaryan
---
drivers/dma-buf/heaps/Kconfig | 1 +
drivers/dma-buf/heaps/system_heap.c | 32 ++---
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 45c7d277448b..2276420ae905 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -6,6 +6,7 @@ config DMABUF_HEAPS_SYSTEM
depends on DMABUF_HEAPS
select NET
select PAGE_POOL
+ select DMABUF_HEAPS_DEFERRED_FREE
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 2addb6d832e0..fe122b5eff10 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -22,6 +22,8 @@
#include
#include
+#include "deferred-free-helper.h"
+
static struct dma_heap *sys_heap;
struct system_heap_buffer {
@@ -32,6 +34,7 @@ struct system_heap_buffer {
struct sg_table sg_table;
int vmap_cnt;
void *vaddr;
+ struct deferred_freelist_item deferred_free;
};
struct dma_heap_attachment {
@@ -301,30 +304,45 @@ static int system_heap_zero_buffer(struct
system_heap_buffer *buffer)
return ret;
}
-static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+static void system_heap_buf_free(struct deferred_freelist_item *item,
+enum df_reason reason)
{
- struct system_heap_buffer *buffer = dmabuf->priv;
+ struct system_heap_buffer *buffer;
struct sg_table *table;
struct scatterlist *sg;
int i, j;
+ buffer = container_of(item, struct system_heap_buffer, deferred_free);
/* Zero the buffer pages before adding back to the pool */
- system_heap_zero_buffer(buffer);
+ if (reason == DF_NORMAL)
+ if (system_heap_zero_buffer(buffer))
+ reason = DF_UNDER_PRESSURE; // On failure, just free
table = >sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- for (j = 0; j < NUM_ORDERS; j++) {
- if (compound_order(page) == orders[j])
- break;
+ if (reason == DF_UNDER_PRESSURE) {
+ __free_pages(page, compound_order(page));
+ } else {
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
- page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
}
+static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
+{
+ struct system_heap_buffer *buffer = dmabuf->priv;
+
+ deferred_free(>deferred_free, system_heap_buf_free,
buffer->len);
+}
+
static const struct dma_buf_ops system_heap_buf_ops = {
.attach = system_heap_attach,
.detach = system_heap_detach,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] dma-buf: system_heap: Add pagepool support to system heap
Reuse/abuse the pagepool code from the network code to speed
up allocation performance.
This is similar to the ION pagepool usage, but tries to
utilize generic code instead of a custom implementation.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix build issue caused by selecting PAGE_POOL w/o NET
as Reported-by: kernel test robot
v3:
* Simplify the page zeroing logic a bit by using kmap_atomic
instead of vmap as suggested by Daniel Mentz
---
drivers/dma-buf/heaps/Kconfig | 2 ++
drivers/dma-buf/heaps/system_heap.c | 52 ++---
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index f7aef8bc7119..45c7d277448b 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -4,6 +4,8 @@ config DMABUF_HEAPS_DEFERRED_FREE
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
+ select NET
+ select PAGE_POOL
help
Choose this option to enable the system dmabuf heap. The system heap
is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..2addb6d832e0 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
static struct dma_heap *sys_heap;
@@ -53,6 +54,7 @@ static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP,
LOW_ORDER_GFP};
*/
static const unsigned int orders[] = {8, 4, 0};
#define NUM_ORDERS ARRAY_SIZE(orders)
+struct page_pool *pools[NUM_ORDERS];
static struct sg_table *dup_sg_table(struct sg_table *table)
{
@@ -281,18 +283,43 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
struct dma_buf_map *map)
dma_buf_map_clear(map);
}
+static int system_heap_zero_buffer(struct system_heap_buffer *buffer)
+{
+ struct sg_table *sgt = >sg_table;
+ struct sg_page_iter piter;
+ struct page *p;
+ void *vaddr;
+ int ret = 0;
+
+ for_each_sgtable_page(sgt, , 0) {
+ p = sg_page_iter_page();
+ vaddr = kmap_atomic(p);
+ memset(vaddr, 0, PAGE_SIZE);
+ kunmap_atomic(vaddr);
+ }
+
+ return ret;
+}
+
static void system_heap_dma_buf_release(struct dma_buf *dmabuf)
{
struct system_heap_buffer *buffer = dmabuf->priv;
struct sg_table *table;
struct scatterlist *sg;
- int i;
+ int i, j;
+
+ /* Zero the buffer pages before adding back to the pool */
+ system_heap_zero_buffer(buffer);
table = >sg_table;
for_each_sg(table->sgl, sg, table->nents, i) {
struct page *page = sg_page(sg);
- __free_pages(page, compound_order(page));
+ for (j = 0; j < NUM_ORDERS; j++) {
+ if (compound_order(page) == orders[j])
+ break;
+ }
+ page_pool_put_full_page(pools[j], page, false);
}
sg_free_table(table);
kfree(buffer);
@@ -322,8 +349,7 @@ static struct page *alloc_largest_available(unsigned long
size,
continue;
if (max_order < orders[i])
continue;
-
- page = alloc_pages(order_flags[i], orders[i]);
+ page = page_pool_alloc_pages(pools[i], order_flags[i]);
if (!page)
continue;
return page;
@@ -428,6 +454,24 @@ static const struct dma_heap_ops system_heap_ops = {
static int system_heap_create(void)
{
struct dma_heap_export_info exp_info;
+ int i;
+
+ for (i = 0; i < NUM_ORDERS; i++) {
+ struct page_pool_params pp;
+
+ memset(, 0, sizeof(pp));
+ pp.order = orders[i];
+ pools[i] = page_pool_create();
+
+ if (IS_ERR(pools[i])) {
+ int j;
+
+ pr_err("%s: page pool creation failed!\n", __func__);
+ for (j = 0; j < i; j++)
+ page_pool_destroy(pools[j]);
+ return PTR_ERR(pools[i]);
+ }
+ }
exp_info.name = "system";
exp_info.ops = _heap_ops;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] dma-buf: heaps: Add deferred-free-helper library code
This patch provides infrastructure for deferring buffer frees.
This is a feature ION provided which when used with some form
of a page pool, provides a nice performance boost in an
allocation microbenchmark. The reason it helps is it allows the
page-zeroing to be done out of the normal allocation/free path,
and pushed off to a kthread.
As not all heaps will find this useful, its implemented as
a optional helper library that heaps can utilize.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
v2:
* Fix sleep in atomic issue from using a mutex, by switching
to a spinlock as Reported-by: kernel test robot
* Cleanup API to use a reason enum for clarity and add some documentation
comments as suggested by Suren Baghdasaryan.
v3:
* Minor tweaks so it can be built as a module
* A few small fixups suggested by Daniel Mentz
---
drivers/dma-buf/heaps/Kconfig| 3 +
drivers/dma-buf/heaps/Makefile | 1 +
drivers/dma-buf/heaps/deferred-free-helper.c | 138 +++
drivers/dma-buf/heaps/deferred-free-helper.h | 55
4 files changed, 197 insertions(+)
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.c
create mode 100644 drivers/dma-buf/heaps/deferred-free-helper.h
diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..f7aef8bc7119 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -1,3 +1,6 @@
+config DMABUF_HEAPS_DEFERRED_FREE
+ tristate
+
config DMABUF_HEAPS_SYSTEM
bool "DMA-BUF System Heap"
depends on DMABUF_HEAPS
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..4e7839875615 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_HEAPS_DEFERRED_FREE) += deferred-free-helper.o
obj-$(CONFIG_DMABUF_HEAPS_SYSTEM) += system_heap.o
obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
diff --git a/drivers/dma-buf/heaps/deferred-free-helper.c
b/drivers/dma-buf/heaps/deferred-free-helper.c
new file mode 100644
index ..941608319a94
--- /dev/null
+++ b/drivers/dma-buf/heaps/deferred-free-helper.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Deferred dmabuf freeing helper
+ *
+ * Copyright (C) 2020 Linaro, Ltd.
+ *
+ * Based on the ION page pool code
+ * Copyright (C) 2011 Google, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "deferred-free-helper.h"
+
+static LIST_HEAD(free_list);
+static size_t list_size;
+wait_queue_head_t freelist_waitqueue;
+struct task_struct *freelist_task;
+static DEFINE_SPINLOCK(free_list_lock);
+
+void deferred_free(struct deferred_freelist_item *item,
+ void (*free)(struct deferred_freelist_item*,
+ enum df_reason),
+ size_t size)
+{
+ unsigned long flags;
+
+ INIT_LIST_HEAD(>list);
+ item->size = size;
+ item->free = free;
+
+ spin_lock_irqsave(_list_lock, flags);
+ list_add(>list, _list);
+ list_size += size;
+ spin_unlock_irqrestore(_list_lock, flags);
+ wake_up(_waitqueue);
+}
+EXPORT_SYMBOL_GPL(deferred_free);
+
+static size_t free_one_item(enum df_reason reason)
+{
+ unsigned long flags;
+ size_t size = 0;
+ struct deferred_freelist_item *item;
+
+ spin_lock_irqsave(_list_lock, flags);
+ if (list_empty(_list)) {
+ spin_unlock_irqrestore(_list_lock, flags);
+ return 0;
+ }
+ item = list_first_entry(_list, struct deferred_freelist_item,
list);
+ list_del(>list);
+ size = item->size;
+ list_size -= size;
+ spin_unlock_irqrestore(_list_lock, flags);
+
+ item->free(item, reason);
+ return size;
+}
+
+static unsigned long get_freelist_size(void)
+{
+ unsigned long size;
+ unsigned long flags;
+
+ spin_lock_irqsave(_list_lock, flags);
+ size = list_size;
+ spin_unlock_irqrestore(_list_lock, flags);
+ return size;
+}
+
+static unsigned long freelist_shrink_count(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ return get_freelist_size();
+}
+
+static unsigned long freelist_shrink_scan(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+ unsigned long total_freed = 0;
+
+ if (sc->nr_to_scan == 0)
+ return 0;
+
+ while (total_freed < sc->nr_to_scan) {
+ size_t freed =
Re: [PATCH v10 8/9] drm/mediatek: add DDP support for MT8183
On Thu, 2021-01-28 at 14:13 +0800, CK Hu wrote:
> Hi, Hsin-Yi:
>
> Modify the title's prefix to 'soc: mediatek:'
Modify more, the title should be 'soc: mediatek: add mtk mutex support
for MT8183'
>
> On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> > From: Yongqiang Niu
> >
> > Add DDP support for MT8183 SoC.
> >
> > Signed-off-by: Yongqiang Niu
> > Signed-off-by: Hsin-Yi Wang
> > ---
> > drivers/soc/mediatek/mtk-mutex.c | 50
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-mutex.c
> > b/drivers/soc/mediatek/mtk-mutex.c
> > index f531b119da7a9..f64e9c33e85ad 100644
> > --- a/drivers/soc/mediatek/mtk-mutex.c
> > +++ b/drivers/soc/mediatek/mtk-mutex.c
> > @@ -14,6 +14,8 @@
> >
> > #define MT2701_MUTEX0_MOD0 0x2c
> > #define MT2701_MUTEX0_SOF0 0x30
> > +#define MT8183_DISP_MUTEX0_MOD00x30
> > +#define MT8183_DISP_MUTEX0_SOF00x2c
>
> Modify 'DISP_MUTEX' to 'MUTEX'
>
> >
> > #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> > #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> > @@ -37,6 +39,18 @@
> > #define MT8167_MUTEX_MOD_DISP_DITHER 15
> > #define MT8167_MUTEX_MOD_DISP_UFOE 16
> >
> > +#define MT8183_MUTEX_MOD_DISP_RDMA00
> > +#define MT8183_MUTEX_MOD_DISP_RDMA11
> > +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> > +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> > +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> > +#define MT8183_MUTEX_MOD_DISP_WDMA012
> > +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> > +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> > +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> > +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> > +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> > +
> > #define MT8173_MUTEX_MOD_DISP_OVL0 11
> > #define MT8173_MUTEX_MOD_DISP_OVL1 12
> > #define MT8173_MUTEX_MOD_DISP_RDMA013
> > @@ -87,6 +101,12 @@
> > #define MT2712_MUTEX_SOF_DSI3 6
> > #define MT8167_MUTEX_SOF_DPI0 2
> > #define MT8167_MUTEX_SOF_DPI1 3
> > +#define MT8183_MUTEX_SOF_DSI0 1
> > +#define MT8183_MUTEX_SOF_DPI0 2
> > +
> > +/* Add EOF setting so overlay hardware can receive frame done irq */
> > +#define MT8183_MUTEX_EOF_DSI0 (MT8183_MUTEX_SOF_DSI0
> > << 6)
> > +#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0
> > << 6)
> >
> > struct mtk_mutex {
> > int id;
> > @@ -181,6 +201,20 @@ static const unsigned int
> > mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> > };
> >
> > +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> > + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> > + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> > + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> > + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> > + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> > + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> > + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> > + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> > + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> > + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> > +};
> > +
> > static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> > @@ -198,6 +232,12 @@ static const unsigned int
> > mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> > };
> >
> > +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> > + [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> > + [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> > + [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
>
> According to discussion in [1], add comment for the odd EOF setting.
>
> [1]
> https://patchwork.kernel.org/project/linux-mediatek/patch/1595469798-3824-8-git-send-email-yongqiang@mediatek.com/
>
> Regards,
> CK.
>
>
> > +};
> > +
> > static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> > .mutex_mod = mt2701_mutex_mod,
> > .mutex_sof = mt2712_mutex_sof,
> > @@ -227,6 +267,14 @@ static const struct mtk_mutex_data
> > mt8173_mutex_driver_data = {
> > .mutex_sof_reg = MT2701_MUTEX0_SOF0,
> > };
> >
> > +static const struct mtk_mutex_data mt8183_mutex_driver_data = {
> > + .mutex_mod = mt8183_mutex_mod,
> > + .mutex_sof = mt8183_mutex_sof,
> > +
Re: [PATCH v10 9/9] drm/mediatek: add support for mediatek SOC MT8183
Hi, Hsin-Yi:
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> 1. add ovl private data
> 2. add rdma private data
> 3. add gamma privte data
> 4. add main and external path module for crtc create
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 1 +
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c| 45 +++
> 4 files changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index c98fe284265d0..93ad76a2dda5e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -179,6 +179,7 @@ static const struct mtk_disp_gamma_data
> mt8173_gamma_driver_data = {
> static const struct of_device_id mtk_disp_gamma_driver_dt_match[] = {
> { .compatible = "mediatek,mt8173-disp-gamma",
> .data = _gamma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-gamma"},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 1c295c58a5e82..da7e38a28759b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -424,11 +424,29 @@ static const struct mtk_disp_ovl_data
> mt8173_ovl_driver_data = {
> .fmt_rgb565_is_0 = true,
> };
>
> +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 2,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = _ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
> + .data = _ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> + .data = _ovl_2l_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 04b9542010b00..29fa5f3a05c30 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -355,11 +355,17 @@ static const struct mtk_disp_rdma_data
> mt8173_rdma_driver_data = {
> .fifo_size = SZ_8K,
> };
>
> +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> + .fifo_size = 5 * SZ_1K,
> +};
> +
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-rdma",
> .data = _rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = _rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma",
> + .data = _rdma_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 279d3e6f11563..486e73e675ad5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -129,6 +129,24 @@ static const enum mtk_ddp_comp_id mt8173_mtk_ddp_ext[] =
> {
> DDP_COMPONENT_DPI0,
> };
>
> +static const enum mtk_ddp_comp_id mt8183_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_OVL_2L0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_CCORR,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_GAMMA,
> + DDP_COMPONENT_DITHER,
> + DDP_COMPONENT_DSI0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
> + DDP_COMPONENT_OVL_2L1,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI0,
> +};
> +
> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .main_path = mt2701_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
> @@ -161,6 +179,13 @@ static const struct mtk_mmsys_driver_data
> mt8173_mmsys_driver_data = {
> .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> };
>
> +static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
> + .main_path = mt8183_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt8183_mtk_ddp_main),
> + .ext_path = mt8183_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
> +};
> +
> static int mtk_drm_kms_init(struct drm_device *drm)
> {
> struct mtk_drm_private *private =
Re: [PATCH v10 8/9] drm/mediatek: add DDP support for MT8183
Hi, Hsin-Yi:
Modify the title's prefix to 'soc: mediatek:'
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Add DDP support for MT8183 SoC.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/soc/mediatek/mtk-mutex.c | 50
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-mutex.c
> b/drivers/soc/mediatek/mtk-mutex.c
> index f531b119da7a9..f64e9c33e85ad 100644
> --- a/drivers/soc/mediatek/mtk-mutex.c
> +++ b/drivers/soc/mediatek/mtk-mutex.c
> @@ -14,6 +14,8 @@
>
> #define MT2701_MUTEX0_MOD0 0x2c
> #define MT2701_MUTEX0_SOF0 0x30
> +#define MT8183_DISP_MUTEX0_MOD0 0x30
> +#define MT8183_DISP_MUTEX0_SOF0 0x2c
Modify 'DISP_MUTEX' to 'MUTEX'
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n)(0x24 + 0x20 * (n))
> @@ -37,6 +39,18 @@
> #define MT8167_MUTEX_MOD_DISP_DITHER 15
> #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8183_MUTEX_MOD_DISP_RDMA0 0
> +#define MT8183_MUTEX_MOD_DISP_RDMA1 1
> +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> +#define MT8183_MUTEX_MOD_DISP_OVL0_2L10
> +#define MT8183_MUTEX_MOD_DISP_OVL1_2L11
> +#define MT8183_MUTEX_MOD_DISP_WDMA0 12
> +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> +#define MT8183_MUTEX_MOD_DISP_DITHER017
> +
> #define MT8173_MUTEX_MOD_DISP_OVL0 11
> #define MT8173_MUTEX_MOD_DISP_OVL1 12
> #define MT8173_MUTEX_MOD_DISP_RDMA0 13
> @@ -87,6 +101,12 @@
> #define MT2712_MUTEX_SOF_DSI36
> #define MT8167_MUTEX_SOF_DPI02
> #define MT8167_MUTEX_SOF_DPI13
> +#define MT8183_MUTEX_SOF_DSI01
> +#define MT8183_MUTEX_SOF_DPI02
> +
> +/* Add EOF setting so overlay hardware can receive frame done irq */
> +#define MT8183_MUTEX_EOF_DSI0(MT8183_MUTEX_SOF_DSI0
> << 6)
> +#define MT8183_MUTEX_EOF_DPI0(MT8183_MUTEX_SOF_DPI0
> << 6)
>
> struct mtk_mutex {
> int id;
> @@ -181,6 +201,20 @@ static const unsigned int
> mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> +};
> +
> static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -198,6 +232,12 @@ static const unsigned int
> mt8167_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> [MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> };
>
> +static const unsigned int mt8183_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
> + [MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> + [MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> + [MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
According to discussion in [1], add comment for the odd EOF setting.
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/1595469798-3824-8-git-send-email-yongqiang@mediatek.com/
Regards,
CK.
> +};
> +
> static const struct mtk_mutex_data mt2701_mutex_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -227,6 +267,14 @@ static const struct mtk_mutex_data
> mt8173_mutex_driver_data = {
> .mutex_sof_reg = MT2701_MUTEX0_SOF0,
> };
>
> +static const struct mtk_mutex_data mt8183_mutex_driver_data = {
> + .mutex_mod = mt8183_mutex_mod,
> + .mutex_sof = mt8183_mutex_sof,
> + .mutex_mod_reg = MT8183_DISP_MUTEX0_MOD0,
> + .mutex_sof_reg = MT8183_DISP_MUTEX0_SOF0,
> + .no_clk = true,
> +};
> +
> struct mtk_mutex *mtk_mutex_get(struct device *dev)
> {
> struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
> @@ -457,6 +505,8 @@ static const struct of_device_id mutex_driver_dt_match[]
> = {
>
Re: [PATCH v10 7/9] drm/mediatek: enable dither function
Hi, Hsin-Yi:
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> for 5 or 6 bpc panel, we need enable dither function
> to improve the display quality
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 37 -
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 8173f709272be..ee54505412dcd 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -53,7 +53,9 @@
> #define DITHER_ENBIT(0)
> #define DISP_DITHER_CFG 0x0020
> #define DITHER_RELAY_MODEBIT(0)
> +#define DITHER_ENGINE_EN BIT(1)
> #define DISP_DITHER_SIZE 0x0030
> +#define DITHER_REG(idx) (0x100 + (idx) * 4)
>
> #define LUT_10BIT_MASK 0x03ff
>
> @@ -313,8 +315,41 @@ static void mtk_dither_config(struct device *dev,
> unsigned int w,
> {
> struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> + bool enable = true;
> +
> + const u32 dither_setting[] = {
> + 0x, /* 5 */
> + 0x3002, /* 6 */
> + 0x, /* 7 */
> + 0x, /* 8 */
> + 0x, /* 9 */
> + 0x, /* 10 */
> + 0x, /* 11 */
> + 0x0011, /* 12 */
> + 0x, /* 13 */
> + 0x, /* 14 */
Could you explain what is this?
> + };
> +
> + if (bpc == 6) {
> + mtk_ddp_write(cmdq_pkt, 0x4041, >cmdq_reg,
> priv->regs, DITHER_REG(15));
> + mtk_ddp_write(cmdq_pkt, 0x40404040, >cmdq_reg,
> priv->regs, DITHER_REG(16));
> + } else if (bpc == 5) {
> + mtk_ddp_write(cmdq_pkt, 0x5051, >cmdq_reg,
> priv->regs, DITHER_REG(15));
> + mtk_ddp_write(cmdq_pkt, 0x50504040, >cmdq_reg,
> priv->regs, DITHER_REG(16));
This looks very similar to the code in mtk_dither_set(), could you
symbolize this magic number like mtk_dither_set()?
Regards,
CK
> + } else {
> + enable = false;
> + }
> +
> + if (enable) {
> + u32 idx;
> +
> + for (idx = 0; idx < ARRAY_SIZE(dither_setting); idx++)
> + mtk_ddp_write(cmdq_pkt, dither_setting[idx],
> >cmdq_reg, priv->regs,
> + DITHER_REG(idx + 5));
> + }
> +
> mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, priv->regs,
> DISP_DITHER_SIZE);
> - mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, >cmdq_reg, priv->regs,
> DISP_DITHER_CFG);
> +mtk_ddp_write(cmdq_pkt, enable ? DITHER_ENGINE_EN :
> DITHER_RELAY_MODE, >cmdq_reg, priv->regs, DISP_DITHER_CFG);
> }
>
> static void mtk_dither_start(struct device *dev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #21 from bola...@163.com --- (In reply to Michel Dänzer from comment #14) > > If enable 64bit kernel support,I need to recompile everything on LFS10.0 in > > next weeks. > > You shouldn't. 32-bit user-space works fine with a 64-bit kernel. You advise is very effective! I use Ubuntu to compile the X64 kernel . Thanks ! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 6/9] drm/mediatek: add has_dither private data for gamma
Hi, Hsin-Yi:
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> Not all SoC has dither function in gamma module.
> Add private data to control this function setting.
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index b5a499d7e472c..c98fe284265d0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -25,7 +25,7 @@
> #define LUT_10BIT_MASK 0x03ff
>
> struct mtk_disp_gamma_data {
> - u32 reserved;
> + bool has_dither;
> };
>
> /**
> @@ -91,7 +91,8 @@ void mtk_gamma_config(struct device *dev, unsigned int w,
>
> mtk_ddp_write(cmdq_pkt, h << 16 | w, >cmdq_reg, gamma->regs,
> DISP_GAMMA_SIZE);
> - mtk_dither_set_common(gamma->regs, >cmdq_reg, bpc,
> DISP_GAMMA_CFG, cmdq_pkt);
> + if (gamma->data && gamma->data->has_dither)
> + mtk_dither_set_common(gamma->regs, >cmdq_reg, bpc,
> DISP_GAMMA_CFG, cmdq_pkt);
> }
>
> void mtk_gamma_start(struct device *dev)
> @@ -171,8 +172,13 @@ static int mtk_disp_gamma_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
> + .has_dither = true,
> +};
> +
> static const struct of_device_id mtk_disp_gamma_driver_dt_match[] = {
> - { .compatible = "mediatek,mt8173-disp-gamma"},
> + { .compatible = "mediatek,mt8173-disp-gamma",
> + .data = _gamma_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 5/9] drm/mediatek: separate gamma module
Hi, Hsin-Yi:
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> mt8183 gamma module will different with mt8173
> separate gamma for add private data
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 10 ++
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 188
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 71 ++--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 214 insertions(+), 61 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_gamma.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 01d06332f7679..b64674b944860 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> mediatek-drm-y := mtk_disp_color.o \
> + mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index c50d5fc9fd349..c1e658b490b6c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -27,6 +27,16 @@ void mtk_dpi_stop(struct device *dev);
> void mtk_dsi_ddp_start(struct device *dev);
> void mtk_dsi_ddp_stop(struct device *dev);
>
> +int mtk_gamma_clk_enable(struct device *dev);
> +void mtk_gamma_clk_disable(struct device *dev);
> +void mtk_gamma_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_gamma_set(struct device *dev, struct drm_crtc_state *state);
> +void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state);
> +void mtk_gamma_start(struct device *dev);
> +void mtk_gamma_stop(struct device *dev);
> +
> void mtk_ovl_bgclr_in_on(struct device *dev);
> void mtk_ovl_bgclr_in_off(struct device *dev);
> void mtk_ovl_bypass_shadow(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> new file mode 100644
> index 0..b5a499d7e472c
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -0,0 +1,188 @@
> +/*
> + * SPDX-License-Identifier:
> + *
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_GAMMA_EN0x
> +#define GAMMA_EN BIT(0)
> +#define DISP_GAMMA_CFG 0x0020
> +#define GAMMA_LUT_EN BIT(1)
> +#define DISP_GAMMA_SIZE 0x0030
> +#define DISP_GAMMA_LUT 0x0700
> +
> +#define LUT_10BIT_MASK 0x03ff
> +
> +struct mtk_disp_gamma_data {
> + u32 reserved;
> +};
> +
> +/**
> + * struct mtk_disp_gamma - DISP_GAMMA driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_gamma {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> + const struct mtk_disp_gamma_data *data;
> +};
> +
> +int mtk_gamma_clk_enable(struct device *dev)
> +{
> + struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(gamma->clk);
> +}
> +
> +void mtk_gamma_clk_disable(struct device *dev)
> +{
> + struct mtk_disp_gamma *gamma = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(gamma->clk);
> +}
> +
> +void mtk_gamma_set_common(void __iomem *regs, struct drm_crtc_state *state)
> +{
> + unsigned int i, reg;
> + struct drm_color_lut *lut;
> + void __iomem *lut_base;
> + u32 word;
> +
> + if (state->gamma_lut) {
> + reg = readl(regs + DISP_GAMMA_CFG);
> + reg = reg | GAMMA_LUT_EN;
> + writel(reg, regs + DISP_GAMMA_CFG);
> + lut_base = regs + DISP_GAMMA_LUT;
> + lut = (struct drm_color_lut *)state->gamma_lut->data;
> + for (i = 0; i < MTK_LUT_SIZE; i++) {
> + word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
> + (((lut[i].green >> 6) & LUT_10BIT_MASK) << 10) +
> + ((lut[i].blue >> 6) & LUT_10BIT_MASK);
> + writel(word, (lut_base + i * 4));
> + }
> + }
> +}
> +
> +void mtk_gamma_set(struct device *dev, struct
Re: [PATCH v10 4/9] drm/mediatek: generalize mtk_dither_set() function
On Thu, 2021-01-28 at 13:09 +0800, Hsin-Yi Wang wrote:
> On Thu, Jan 28, 2021 at 12:39 PM CK Hu wrote:
> >
> > Hi, Hsin-Yi:
> >
> > On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> > > There may be data structure other than mtk_ddp_comp_dev that would call
> > > mtk_dither_set(), so use regs as parameter instead of device.
> >
> > You does not change the interface of mtk_dither_set(). You move the
> > common part in mtk_dither_set() to a new function which could be called
> > by another caller.
> >
> > Regards,
> > CK.
> >
> Current mtk_dither_set() cast dev data to struct mtk_ddp_comp_dev. But
> mtk_disp_gamma in next patch would also call this function. But it's
> dev data is struct mtk_disp_gamma, which is different, so we can't
> cast to mtk_ddp_comp_dev. I separate the necessary parameters (regs,
> cmdq_reg) out, so both component dither and gamma can both call this
> separated function.
I know this. This patch looks good to me but the description would
confuse me.From the description, it seems that you modify the interface
of mtk_dither_set(). So please modify the description to be more clear.
Regards,
CK
>
> This is similar to the mtk_gamma_set_common() in the next patch, which
> gamma and aal both used.
>
> > >
> > > Signed-off-by: Hsin-Yi Wang
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 25 +
> > > 2 files changed, 20 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > index 46d199b7b4a29..c50d5fc9fd349 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > > @@ -17,6 +17,10 @@ void mtk_color_config(struct device *dev, unsigned int
> > > w,
> > > unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> > > void mtk_color_start(struct device *dev);
> > >
> > > +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> > > *cmdq_reg,
> > > +unsigned int bpc, unsigned int CFG,
> > > +struct cmdq_pkt *cmdq_pkt);
> > > +
> > > void mtk_dpi_start(struct device *dev);
> > > void mtk_dpi_stop(struct device *dev);
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index 7b5293429426d..53d25823a37cc 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -151,33 +151,40 @@ static void mtk_ddp_clk_disable(struct device *dev)
> > > clk_disable_unprepare(priv->clk);
> > > }
> > >
> > > -static void mtk_dither_set(struct device *dev, unsigned int bpc,
> > > - unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> > > -{
> > > - struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > >
> > > +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> > > *cmdq_reg,
> > > +unsigned int bpc, unsigned int CFG, struct
> > > cmdq_pkt *cmdq_pkt)
> > > +{
> > > /* If bpc equal to 0, the dithering function didn't be enabled */
> > > if (bpc == 0)
> > > return;
> > >
> > > if (bpc >= MTK_MIN_BPC) {
> > > - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> > > DISP_DITHER_5);
> > > - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> > > DISP_DITHER_7);
> > > + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_5);
> > > + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_7);
> > > mtk_ddp_write(cmdq_pkt,
> > > DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
> > > DITHER_ADD_LSHIFT_R(MTK_MAX_BPC - bpc) |
> > > DITHER_NEW_BIT_MODE,
> > > - >cmdq_reg, priv->regs, DISP_DITHER_15);
> > > + cmdq_reg, regs, DISP_DITHER_15);
> > > mtk_ddp_write(cmdq_pkt,
> > > DITHER_LSB_ERR_SHIFT_B(MTK_MAX_BPC - bpc) |
> > > DITHER_ADD_LSHIFT_B(MTK_MAX_BPC - bpc) |
> > > DITHER_LSB_ERR_SHIFT_G(MTK_MAX_BPC - bpc) |
> > > DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> > > - >cmdq_reg, priv->regs, DISP_DITHER_16);
> > > - mtk_ddp_write(cmdq_pkt, DISP_DITHERING, >cmdq_reg,
> > > priv->regs, CFG);
> > > + cmdq_reg, regs, DISP_DITHER_16);
> > > + mtk_ddp_write(cmdq_pkt, DISP_DITHERING, cmdq_reg, regs,
> > > CFG);
> > > }
> > > }
> > >
> > > +static void mtk_dither_set(struct device *dev, unsigned int bpc,
> > > + unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> > > +{
> > > + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> > > +
> > > +
Re: [PATCH v2 2/3] dma-buf: system_heap: Add pagepool support to system heap
On Wed, Jan 27, 2021 at 12:21 PM Daniel Mentz wrote:
>
> On Fri, Jan 22, 2021 at 7:47 PM John Stultz wrote:
> > +static int system_heap_clear_pages(struct page **pages, int num, pgprot_t
> > pgprot)
> > +{
> > + void *addr = vmap(pages, num, VM_MAP, pgprot);
> > +
> > + if (!addr)
> > + return -ENOMEM;
> > + memset(addr, 0, PAGE_SIZE * num);
> > + vunmap(addr);
> > + return 0;
> > +}
>
> I thought that vmap/vunmap are expensive, and I am wondering if
> there's a faster way that avoids vmap.
>
> How about lifting this code from lib/iov_iter.c
> static void memzero_page(struct page *page, size_t offset, size_t len)
> {
> char *addr = kmap_atomic(page);
> memset(addr + offset, 0, len);
> kunmap_atomic(addr);
> }
>
> Or what about lifting that code from the old ion_cma_heap.c
>
> if (PageHighMem(pages)) {
> unsigned long nr_clear_pages = nr_pages;
> struct page *page = pages;
>
> while (nr_clear_pages > 0) {
> void *vaddr = kmap_atomic(page);
>
> memset(vaddr, 0, PAGE_SIZE);
> kunmap_atomic(vaddr);
> page++;
> nr_clear_pages--;
> }
> } else {
> memset(page_address(pages), 0, size);
> }
Though, this last memset only works since CMA is contiguous, so it
probably needs to always do the kmap_atomic for each page, right?
I'm still a little worried if this is right, as the current
implementation with the vmap comes from the old ion_heap_sglist_zero
logic, which similarly tries to batch the vmaps 32 pages at at time,
but I'll give it a try.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 bola...@163.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #20 from bola...@163.com --- Everything is OK!I recompiled the 5.10.8 X64 kernel,AMDGPU is successful load !It seems the 32bit kernel is not supported now .I think the AMDGPU drivers need IOMMU and HSPA support,the 32bit kernel haven't supported them. Thanks for all people who replied and helped me ! Thanks a lot ! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #19 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your xorg log and dmesg output. Note that if you want an fbdev interface for the console, you need to enable CONFIG_DRM_FBDEV_EMULATION=y in your config. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 4/9] drm/mediatek: generalize mtk_dither_set() function
Hi, Hsin-Yi:
On Wed, 2021-01-27 at 12:54 +0800, Hsin-Yi Wang wrote:
> There may be data structure other than mtk_ddp_comp_dev that would call
> mtk_dither_set(), so use regs as parameter instead of device.
You does not change the interface of mtk_dither_set(). You move the
common part in mtk_dither_set() to a new function which could be called
by another caller.
Regards,
CK.
>
> Signed-off-by: Hsin-Yi Wang
> ---
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 25 +
> 2 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 46d199b7b4a29..c50d5fc9fd349 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -17,6 +17,10 @@ void mtk_color_config(struct device *dev, unsigned int w,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> void mtk_color_start(struct device *dev);
>
> +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> *cmdq_reg,
> +unsigned int bpc, unsigned int CFG,
> +struct cmdq_pkt *cmdq_pkt);
> +
> void mtk_dpi_start(struct device *dev);
> void mtk_dpi_stop(struct device *dev);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index 7b5293429426d..53d25823a37cc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -151,33 +151,40 @@ static void mtk_ddp_clk_disable(struct device *dev)
> clk_disable_unprepare(priv->clk);
> }
>
> -static void mtk_dither_set(struct device *dev, unsigned int bpc,
> - unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> -{
> - struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
>
> +void mtk_dither_set_common(void __iomem *regs, struct cmdq_client_reg
> *cmdq_reg,
> +unsigned int bpc, unsigned int CFG, struct cmdq_pkt
> *cmdq_pkt)
> +{
> /* If bpc equal to 0, the dithering function didn't be enabled */
> if (bpc == 0)
> return;
>
> if (bpc >= MTK_MIN_BPC) {
> - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> DISP_DITHER_5);
> - mtk_ddp_write(cmdq_pkt, 0, >cmdq_reg, priv->regs,
> DISP_DITHER_7);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_5);
> + mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_7);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_R(MTK_MAX_BPC - bpc) |
> DITHER_NEW_BIT_MODE,
> - >cmdq_reg, priv->regs, DISP_DITHER_15);
> + cmdq_reg, regs, DISP_DITHER_15);
> mtk_ddp_write(cmdq_pkt,
> DITHER_LSB_ERR_SHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_B(MTK_MAX_BPC - bpc) |
> DITHER_LSB_ERR_SHIFT_G(MTK_MAX_BPC - bpc) |
> DITHER_ADD_LSHIFT_G(MTK_MAX_BPC - bpc),
> - >cmdq_reg, priv->regs, DISP_DITHER_16);
> - mtk_ddp_write(cmdq_pkt, DISP_DITHERING, >cmdq_reg,
> priv->regs, CFG);
> + cmdq_reg, regs, DISP_DITHER_16);
> + mtk_ddp_write(cmdq_pkt, DISP_DITHERING, cmdq_reg, regs, CFG);
> }
> }
>
> +static void mtk_dither_set(struct device *dev, unsigned int bpc,
> + unsigned int CFG, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + mtk_dither_set_common(priv->regs, >cmdq_reg, bpc, CFG, cmdq_pkt);
> +}
> +
> static void mtk_od_config(struct device *dev, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #18 from bola...@163.com --- I have compiled x64 kernel for my LFS10.0.Booting with the X64 kernel,when load the amdgpu driver,screen frozen again. check the kern log ,everything seems OK but no amdgpudrmfb .I try to start X11,but failed with no fittable modes. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3 v2] drm/msm: Clean up GMU OOB set/clear handling.
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
Previous version hadn't been rebased off of a bit of debug code I had,
so it wouldn't cleanly apply.
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed, 77 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b3318f86aabc..9066e98eb8ef 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -245,47 +245,66 @@ static int a6xx_gmu_hfi_start(struct a6xx_gmu *gmu)
return ret;
}
+struct a6xx_gmu_oob_bits {
+ int set, ack, set_new, ack_new;
+ const char *name;
+};
+
+/* These are the interrupt / ack bits for each OOB request that are set
+ * in a6xx_gmu_set_oob and a6xx_clear_oob
+ */
+static const struct a6xx_gmu_oob_bits a6xx_gmu_oob_bits[] = {
+ [GMU_OOB_GPU_SET] = {
+ .name = "GPU_SET",
+ .set = 16,
+ .ack = 24,
+ .set_new = 30,
+ .ack_new = 31,
+ },
+
+ [GMU_OOB_PERFCOUNTER_SET] = {
+ .name = "PERFCOUNTER",
+ .set = 17,
+ .ack = 25,
+ .set_new = 28,
+ .ack_new = 30,
+ },
+
+ [GMU_OOB_BOOT_SLUMBER] = {
+ .name = "BOOT_SLUMBER",
+ .set = 22,
+ .ack = 30,
+ },
+
+ [GMU_OOB_DCVS_SET] = {
+ .name = "GPU_DCVS",
+ .set = 23,
+ .ack = 31,
+ },
+};
+
/* Trigger a OOB (out of band) request to the GMU */
int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
int ret;
u32 val;
int request, ack;
- const char *name;
- switch (state) {
- case GMU_OOB_GPU_SET:
- if (gmu->legacy) {
- request = GMU_OOB_GPU_SET_REQUEST;
- ack = GMU_OOB_GPU_SET_ACK;
- } else {
- request = GMU_OOB_GPU_SET_REQUEST_NEW;
- ack = GMU_OOB_GPU_SET_ACK_NEW;
- }
- name = "GPU_SET";
- break;
- case GMU_OOB_PERFCOUNTER_SET:
- if (gmu->legacy) {
- request = GMU_OOB_PERFCOUNTER_REQUEST;
- ack = GMU_OOB_PERFCOUNTER_ACK;
- } else {
- request = GMU_OOB_PERFCOUNTER_REQUEST_NEW;
- ack = GMU_OOB_PERFCOUNTER_ACK_NEW;
- }
- name = "PERFCOUNTER";
- break;
- case GMU_OOB_BOOT_SLUMBER:
- request = GMU_OOB_BOOT_SLUMBER_REQUEST;
- ack = GMU_OOB_BOOT_SLUMBER_ACK;
- name = "BOOT_SLUMBER";
- break;
- case GMU_OOB_DCVS_SET:
- request = GMU_OOB_DCVS_REQUEST;
- ack = GMU_OOB_DCVS_ACK;
- name = "GPU_DCVS";
- break;
- default:
+ if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return -EINVAL;
+
+ if (gmu->legacy) {
+ request = a6xx_gmu_oob_bits[state].set;
+ ack = a6xx_gmu_oob_bits[state].ack;
+ } else {
+ request = a6xx_gmu_oob_bits[state].set_new;
+ ack = a6xx_gmu_oob_bits[state].ack_new;
+ if (!request || !ack) {
+ DRM_DEV_ERROR(gmu->dev,
+ "Invalid non-legacy GMU request %s\n",
+ a6xx_gmu_oob_bits[state].name);
+ return -EINVAL;
+ }
}
/* Trigger the equested OOB operation */
@@ -298,7 +317,7 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
if (ret)
DRM_DEV_ERROR(gmu->dev,
"Timeout waiting for GMU OOB set %s: 0x%x\n",
- name,
+ a6xx_gmu_oob_bits[state].name,
gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO));
/* Clear the acknowledge interrupt */
@@ -310,36 +329,17 @@ int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
/* Clear a pending OOB state in the GMU */
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
- if (!gmu->legacy) {
- if (state == GMU_OOB_GPU_SET) {
- gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
- 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
- } else {
- WARN_ON(state != GMU_OOB_PERFCOUNTER_SET);
- gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
- 1 << GMU_OOB_PERFCOUNTER_CLEAR_NEW);
- }
+
[PATCH 3/3] drm/msm: Clean up GMU OOB set/clear handling.
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed, 77 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 378dc7f190c3..c497e0942141 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -245,47 +245,66 @@ static int a6xx_gmu_hfi_start(struct a6xx_gmu *gmu)
return ret;
}
+struct a6xx_gmu_oob_bits {
+ int set, ack, set_new, ack_new;
+ const char *name;
+};
+
+/* These are the interrupt / ack bits for each OOB request that are set
+ * in a6xx_gmu_set_oob and a6xx_clear_oob
+ */
+static const struct a6xx_gmu_oob_bits a6xx_gmu_oob_bits[] = {
+ [GMU_OOB_GPU_SET] = {
+ .name = "GPU_SET",
+ .set = 16,
+ .ack = 24,
+ .set_new = 30,
+ .ack_new = 31,
+ },
+
+ [GMU_OOB_PERFCOUNTER_SET] = {
+ .name = "PERFCOUNTER",
+ .set = 17,
+ .ack = 25,
+ .set_new = 28,
+ .ack_new = 30,
+ },
+
+ [GMU_OOB_BOOT_SLUMBER] = {
+ .name = "BOOT_SLUMBER",
+ .set = 22,
+ .ack = 30,
+ },
+
+ [GMU_OOB_DCVS_SET] = {
+ .name = "GPU_DCVS",
+ .set = 23,
+ .ack = 31,
+ },
+};
+
/* Trigger a OOB (out of band) request to the GMU */
int _a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state,
char *file, int line)
{
int ret;
u32 val;
int request, ack;
- const char *name;
- switch (state) {
- case GMU_OOB_GPU_SET:
- if (gmu->legacy) {
- request = GMU_OOB_GPU_SET_REQUEST;
- ack = GMU_OOB_GPU_SET_ACK;
- } else {
- request = GMU_OOB_GPU_SET_REQUEST_NEW;
- ack = GMU_OOB_GPU_SET_ACK_NEW;
- }
- name = "GPU_SET";
- break;
- case GMU_OOB_PERFCOUNTER_SET:
- if (gmu->legacy) {
- request = GMU_OOB_PERFCOUNTER_REQUEST;
- ack = GMU_OOB_PERFCOUNTER_ACK;
- } else {
- request = GMU_OOB_PERFCOUNTER_REQUEST_NEW;
- ack = GMU_OOB_PERFCOUNTER_ACK_NEW;
- }
- name = "PERFCOUNTER";
- break;
- case GMU_OOB_BOOT_SLUMBER:
- request = GMU_OOB_BOOT_SLUMBER_REQUEST;
- ack = GMU_OOB_BOOT_SLUMBER_ACK;
- name = "BOOT_SLUMBER";
- break;
- case GMU_OOB_DCVS_SET:
- request = GMU_OOB_DCVS_REQUEST;
- ack = GMU_OOB_DCVS_ACK;
- name = "GPU_DCVS";
- break;
- default:
+ if (state >= ARRAY_SIZE(a6xx_gmu_oob_bits))
return -EINVAL;
+
+ if (gmu->legacy) {
+ request = a6xx_gmu_oob_bits[state].set;
+ ack = a6xx_gmu_oob_bits[state].ack;
+ } else {
+ request = a6xx_gmu_oob_bits[state].set_new;
+ ack = a6xx_gmu_oob_bits[state].ack_new;
+ if (!request || !ack) {
+ DRM_DEV_ERROR(gmu->dev,
+ "Invalid non-legacy GMU request %s\n",
+ a6xx_gmu_oob_bits[state].name);
+ return -EINVAL;
+ }
}
/* Trigger the equested OOB operation */
@@ -299,7 +318,7 @@ int _a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state, char
DRM_DEV_ERROR(gmu->dev,
"%s:%d Timeout waiting for GMU OOB set %s: 0x%x\n",
file, line,
- name,
+ a6xx_gmu_oob_bits[state].name,
gmu_read(gmu, REG_A6XX_GMU_GMU2HOST_INTR_INFO));
/* Clear the acknowledge interrupt */
@@ -311,36 +330,17 @@ int _a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state, char
/* Clear a pending OOB state in the GMU */
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
- if (!gmu->legacy) {
- if (state == GMU_OOB_GPU_SET) {
- gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
- 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
- } else {
- WARN_ON(state != GMU_OOB_PERFCOUNTER_SET);
- gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
- 1 << GMU_OOB_PERFCOUNTER_CLEAR_NEW);
- }
+ int bit;
+
+ if (state >=
[PATCH 2/3] drm/msm: Fix races managing the OOB state for timestamp vs timestamps.
Now that we're not racing with GPU setup, also fix races of timestamps
against other timestamps. In CI, we were seeing this path trigger
timeouts on setting the GMU bit, especially on the first set of tests
right after boot (it's probably easier to lose the race than one might
think, given that we start many tests in parallel, and waiting for NFS
to page in code probably means that lots of tests hit the same point
of screen init at the same time).
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 7424a70b9d35..e8f0b5325a7f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1175,6 +1175,9 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ static DEFINE_MUTEX(perfcounter_oob);
+
+ mutex_lock(_oob);
/* Force the GPU power on so we can read this register */
a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
@@ -1183,6 +1186,7 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
REG_A6XX_RBBM_PERFCTR_CP_0_HI);
a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
+ mutex_unlock(_oob);
return 0;
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/msm: Fix race of GPU init vs timestamp power management.
We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 8
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++--
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 78836b4fb98e..378dc7f190c3 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -264,6 +264,16 @@ int _a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state, char
}
name = "GPU_SET";
break;
+ case GMU_OOB_PERFCOUNTER_SET:
+ if (gmu->legacy) {
+ request = GMU_OOB_PERFCOUNTER_REQUEST;
+ ack = GMU_OOB_PERFCOUNTER_ACK;
+ } else {
+ request = GMU_OOB_PERFCOUNTER_REQUEST_NEW;
+ ack = GMU_OOB_PERFCOUNTER_ACK_NEW;
+ }
+ name = "PERFCOUNTER";
+ break;
case GMU_OOB_BOOT_SLUMBER:
request = GMU_OOB_BOOT_SLUMBER_REQUEST;
ack = GMU_OOB_BOOT_SLUMBER_ACK;
@@ -302,9 +312,14 @@ int _a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state, char
void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state)
{
if (!gmu->legacy) {
- WARN_ON(state != GMU_OOB_GPU_SET);
- gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
- 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+ if (state == GMU_OOB_GPU_SET) {
+ gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+ 1 << GMU_OOB_GPU_SET_CLEAR_NEW);
+ } else {
+ WARN_ON(state != GMU_OOB_PERFCOUNTER_SET);
+ gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+ 1 << GMU_OOB_PERFCOUNTER_CLEAR_NEW);
+ }
return;
}
@@ -313,6 +328,10 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum
a6xx_gmu_oob_state state)
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
1 << GMU_OOB_GPU_SET_CLEAR);
break;
+ case GMU_OOB_PERFCOUNTER_SET:
+ gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
+ 1 << GMU_OOB_PERFCOUNTER_CLEAR);
+ break;
case GMU_OOB_BOOT_SLUMBER:
gmu_write(gmu, REG_A6XX_GMU_HOST2GMU_INTR_SET,
1 << GMU_OOB_BOOT_SLUMBER_CLEAR);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index c6d2bced8e5d..9fa278de2106 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -156,6 +156,7 @@ enum a6xx_gmu_oob_state {
GMU_OOB_BOOT_SLUMBER = 0,
GMU_OOB_GPU_SET,
GMU_OOB_DCVS_SET,
+ GMU_OOB_PERFCOUNTER_SET,
};
/* These are the interrupt / ack bits for each OOB request that are set
@@ -190,6 +191,13 @@ enum a6xx_gmu_oob_state {
#define GMU_OOB_GPU_SET_ACK_NEW31
#define GMU_OOB_GPU_SET_CLEAR_NEW 31
+#define GMU_OOB_PERFCOUNTER_REQUEST17
+#define GMU_OOB_PERFCOUNTER_ACK25
+#define GMU_OOB_PERFCOUNTER_CLEAR 25
+
+#define GMU_OOB_PERFCOUNTER_REQUEST_NEW28
+#define GMU_OOB_PERFCOUNTER_ACK_NEW30
+#define GMU_OOB_PERFCOUNTER_CLEAR_NEW 30
void a6xx_hfi_init(struct a6xx_gmu *gmu);
int a6xx_hfi_start(struct a6xx_gmu *gmu, int boot_state);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c8a9010c1a1d..7424a70b9d35 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1177,12 +1177,12 @@ static int a6xx_get_timestamp(struct msm_gpu *gpu,
uint64_t *value)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
/* Force the GPU power on so we can read this register */
- a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_GPU_SET);
+ a6xx_gmu_set_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
*value = gpu_read64(gpu, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
REG_A6XX_RBBM_PERFCTR_CP_0_HI);
- a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_GPU_SET);
+ a6xx_gmu_clear_oob(_gpu->gmu, GMU_OOB_PERFCOUNTER_SET);
return 0;
}
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications
Am 2021-01-27 um 7:16 a.m. schrieb Christian König: > Am 27.01.21 um 13:11 schrieb Maarten Lankhorst: >> Op 27-01-2021 om 01:22 schreef Felix Kuehling: >>> Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7Cbee0aeff80f440bcc52108d8c2bcc11f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637473463245588199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ncr%2Fqv5lw0ONrYxFvfdcFAXAZ%2BXcJJa6UY%2BxGfcKGVM%3Dreserved=0 Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: "Christian König" Cc: Jerome Glisse Cc: Felix Kuehling Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no
Re: [PATCH v5 00/21] Host1x/TegraDRM UAPI
On 1/27/21 11:26 PM, Dmitry Osipenko wrote: 26.01.2021 05:45, Mikko Perttunen пишет: 5. The hardware state of sync points should be reset when sync point is requested, not when host1x driver is initialized. This may be doable, but I don't think it is critical for this UAPI, so let's consider it after this series. The userspace should anyway not be able to assume the initial value of the syncpoint upon allocation. The kernel should set it to some high value to catch any issues related to wraparound. This is critical because min != max when sync point is requested. That I would just consider a bug, and it can be fixed. But it's orthogonal to whether the value gets reset every time the syncpoint is allocated. Also, this makes code more complicated since it now needs to ensure all waits on the syncpoint have completed before freeing the syncpoint, which can be nontrivial e.g. if the waiter is in a different virtual machine or some other device connected via PCIe (a real usecase). It sounds to me that these VM sync points should be treated very separately from a generic sync points, don't you think so? Let's not mix them and get the generic sync points usable first. They are not special in any way, I'm just referring to cases where the waiter (consumer) is remote. The allocator of the syncpoint (producer) doesn't necessarily even need to know about it. The same concern is applicable within a single VM, or single application as well. Just putting out the point that this is something that needs to be taken care of if we were to reset the value. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/21] sync_file API is not very suitable for DRM
On 1/27/21 11:35 PM, Dmitry Osipenko wrote: 26.01.2021 05:45, Mikko Perttunen пишет: 4. Sync file shouldn't be needed for the part of DRM API which doesn't interact with external non-DRM devices. We should use DRM syncobj for everything related to DRM, it's a superior API over sync file, it's suitable for DRM scheduler. Considering the issues with fileno limits, I suppose there is no other choice. Considering the recent NTSYNC proposal by Wine developers, maybe we should also have NTHANDLEs to get rid of restrictions of file descriptors. It's odd to me that you trying to avoid the existing DRM API. This all was solved in DRM long time ago and grate drivers have no problems with using the DRM APIs. Even if something is really missing, then you should add the missing features instead of re-inventing everything from scratch. DRM is only one of many subsystems that will have to deal with syncpoints, so I have wanted to have a central solution instead of reimplementing the same stuff everywhere. sync_files seem like the "missing feature", but they are difficult to use it with the fileno limits. But as has been said many times, they are intended only to transfer fences between the implementations in individual drivers, so I guess I will have to abandon this dream. DRM syncobjs may have some advantages over sync files, but also disadvantages. They cannot be poll()ed, so they cannot be combined with waits for other resources. I'm not sure do you mean by "poll". Sync object supports polling very well. I mean the poll/select etc. series of functions, which wait for file descriptors to become ready. If there's some trick that allows syncobjs to be used for that, then please tell. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-intel-next
On Wed, Jan 27, 2021 at 09:08:22AM -0500, Rodrigo Vivi wrote: > Hi Dave and Daniel, > > Hopefully this is the last pull request towards 5.12. > > Please notice this contains a drm/framebuffer change needed for > supporting clear color support for TGL Render Decompression. > > Here goes drm-intel-next-2021-01-27: > ... > - Async flips for all ilk+ platforms (Ville) Not quite yet. Still missing one rb so couldn't push the full thing. So still limited to skl+ I'm afraid. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: dqm fence memory corruption
Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang:
> Amdgpu driver uses 4-byte data type as DQM fence memory,
> and transmits GPU address of fence memory to microcode
> through query status PM4 message. However, query status
> PM4 message definition and microcode processing are all
> processed according to 8 bytes. Fence memory only allocates
> 4 bytes of memory, but microcode does write 8 bytes of memory,
> so there is a memory corruption.
Thank you for pointing out that discrepancy. That's a good catch!
I'd prefer to fix this properly by making dqm->fence_addr a u64 pointer.
We should probably also fix up the query_status and
amdkfd_fence_wait_timeout function interfaces to use a 64 bit fence
values everywhere to be consistent.
Regards,
Felix
>
> Signed-off-by: Qu Huang
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index e686ce2..8b38d0c 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -1161,7 +1161,7 @@ static int start_cpsch(struct device_queue_manager *dqm)
> pr_debug("Allocating fence memory\n");
>
> /* allocate fence memory on the gart */
> - retval = kfd_gtt_sa_allocate(dqm->dev, sizeof(*dqm->fence_addr),
> + retval = kfd_gtt_sa_allocate(dqm->dev, sizeof(uint64_t),
> >fence_mem);
>
> if (retval)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.10.10 |5.10.11 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 --- Comment #1 from Andreas (icedragon...@web.de) --- Kernel 5.10.11 (mainline) issues still persist: [ 181.977478] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting [ 181.977546] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB34E [ 181.977617] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 [ 181.977689] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! [ 183.536107] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 [ 203.878870] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting [ 203.878937] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B200 (len 3615, WS 8, PS 0) @ 0xB6EA [ 203.879009] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B0F4 (len 268, WS 4, PS 0) @ 0xB147 [ 203.879080] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! [ 206.105584] [drm] perform_link_training_with_retries: Link training attempt 1 of 4 failed [ 206.509404] [drm] perform_link_training_with_retries: Link training attempt 2 of 4 failed -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD
Hi, On Mon, Jan 25, 2021 at 12:28 PM Stephen Boyd wrote: > > > +/* > > + * Some panels simply don't always come up and need to be power cycled to > > + * work properly. We'll allow for a handful of retries. > > + */ > > +#define MAX_PANEL_PREPARE_TRIES5 > > Is this define used anywhere else? Feels like it would be better to > inline the constant and move the comment above the loop, but I guess > this is OK too. Hrm, usually I only add a #define like this when I need to use the same number more than once, but I'm not doing that here. Maybe I did in an earlier version of the code and then didn't go back and remove the #define when I reworked it? Since this is a bit of a style issue, I will leave it to the simple-panel maintainers to decide. I'm happy to spin this and add the comment before the loop and just hardcode "5" in the loop instead of using MAX_PANEL_PREPARE_TRIES, so just let me know. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] linux-next: Tree for Jan 27 (drm/i915)
Quoting Randy Dunlap (2021-01-27 20:28:05) > On 1/27/21 11:30 AM, Randy Dunlap wrote: > > On 1/27/21 11:08 AM, Randy Dunlap wrote: > >> On 1/27/21 6:44 AM, Stephen Rothwell wrote: > >>> Hi all, > >>> > >>> Note: the patch file has failed to upload :-( > >>> > >>> Changes since 20210125: > >>> > >> > >> on x86_64: > >> > >> ../drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_freeze_late’: > >> ../drivers/gpu/drm/i915/i915_gem.c:1182:2: error: implicit declaration of > >> function ‘wbinvd_on_all_cpus’; did you mean ‘wrmsr_on_cpus’? > >> [-Werror=implicit-function-declaration] > >> wbinvd_on_all_cpus(); > >> > > > > My apologies: this was in Andrew's mmotm 2021-01-25. > > Sorry about that. > > > and now I see that it also happens in today's linux-next. The fix is in the tree that should be feeding into linux-next, so I trust it will resolve itself shortly. Along with the WERROR depends snafu. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] ib-drm-gpio-pdx86-rtc-wdt-v5.12-1
Hi, On 1/26/21 9:54 PM, Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 8:33 PM Hans de Goede wrote: >> On 1/26/21 6:14 PM, Andy Shevchenko wrote: >>> On Tue, Jan 26, 2021 at 6:55 PM Patrik Jakobsson >>> wrote: On Tue, Jan 26, 2021 at 4:51 PM Andy Shevchenko wrote: > On Tue, Jan 26, 2021 at 5:25 PM Patrik Jakobsson > wrote: >> On Tue, Jan 26, 2021 at 1:37 PM Andy Shevchenko >> wrote: >>> >>> Hi guys, >>> >>> This is first part of Intel MID outdated platforms removal. It's >>> collected into >>> immutable branch with a given tag, please pull to yours subsystems. >> >> Hi Andy, >> Do you plan on eventually removing X86_INTEL_MID completely? If so, >> then I should probably start looking at removing the corresponding >> parts in GMA500. > > Nope. It is related to only Medfield / Clovertrail platforms. > > There are other (MID) platforms that may / might utilize this driver > in the future. Right, there's still Oaktrail / Moorestown with hardware in the wild. >>> >>> Actually Moorestown had to be removed a few years ago (kernel won't >>> boot on them anyway from that date when Alan removed support under >>> arch/x86 for it). >>> >>> I'm talking about Merrifield and Moorefield that can utilize it and >>> also some other platforms that are not SFI based (Cedar something... >>> IIRC). >> >> Yes at least there are some 64 bit capable SoCs with GMA500 which were >> used in NAS like devices. These NAS-es actually have a VGA output >> (and maybe also DVI?) which is attached to the GMA500. > > Since you are talking about 64-bit, definitely they are *not* > Moorestown, Medfield, Clovertrail since the mentioned never were > 64-bit. But it would be nice to see the CPU model number to be sure. My info on this comes from this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 And the machine that bugreport is about is a "Thecus N5550 NAS box (Intel Atom D2550/Cedarview platform)" Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/lima: add governor data with pre-defined thresholds
This patch adapts the panfrost pre-defined thresholds change [0] to the
lima driver to improve real-world performance. The upthreshold value has
been set to ramp GPU frequency to max freq faster (compared to panfrost)
to compensate for the lower overall performance of utgard devices.
[0]
https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.l...@arm.com/
Signed-off-by: Christian Hewitt
---
Change since v1: increased upthreshold from 20 to 30, with a soft
dependency on Lukasz delayed timer patch [0]
[0] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.l...@arm.com/
drivers/gpu/drm/lima/lima_devfreq.c | 10 +-
drivers/gpu/drm/lima/lima_devfreq.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..c9854315a0b5 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -163,8 +163,16 @@ int lima_devfreq_init(struct lima_device *ldev)
lima_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
+ /*
+* Setup default thresholds for the simple_ondemand governor.
+* The values are chosen based on experiments.
+*/
+ ldevfreq->gov_data.upthreshold = 30;
+ ldevfreq->gov_data.downdifferential = 5;
+
devfreq = devm_devfreq_add_device(dev, _devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ >gov_data);
if (IS_ERR(devfreq)) {
dev_err(dev, "Couldn't initialize GPU devfreq\n");
ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..b0c7c736e81a 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -4,6 +4,7 @@
#ifndef __LIMA_DEVFREQ_H__
#define __LIMA_DEVFREQ_H__
+#include
#include
#include
@@ -18,6 +19,7 @@ struct lima_devfreq {
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
+ struct devfreq_simple_ondemand_data gov_data;
ktime_t busy_time;
ktime_t idle_time;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: add governor data with pre-defined thresholds
> On 27 Jan 2021, at 3:11 pm, Lukasz Luba wrote: > > On 1/27/21 10:24 AM, Lukasz Luba wrote: >> Hi Christian, >> On 1/25/21 8:18 AM, Christian Hewitt wrote: >>> This patch adapts the panfrost pre-defined thresholds change [0] to the >>> lima driver to improve real-world performance. The upthreshold value has >>> been set to ramp GPU frequency to max freq faster (compared to panfrost) >>> to compensate for the lower overall performance of utgard devices. >>> >>> [0] >>> https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.l...@arm.com/ >>> >>> >>> Signed-off-by: Christian Hewitt >>> --- >>> I have been using Kodi as my test application. If you scroll in library >>> views with hundreds of list items and the panfrost values the slow GPU >>> ramp up is quite noticeable and the GUI feels sluggish. As everything >>> lima runs on is inherently slower than panfrost using devices I believe >>> it's better to ramp up to max freq quicker. >> It's quite low value for the upthreshold, but I believe you have >> experimented and observed that a bit higher (30, 40?) don't work well. >> I don't know the Kodi system, though. >> You can check if the other frequencies are also used in statistics for >> devfreq device: >> cat /sys/class/devfreq//trans_stats >> If they are also used, then it OK (better than stuck at min freq). > > I've just realized that your board might suffer a another issue. > Please apply this patch [1] and run your experiments with upthresholds. > > [1] https://lore.kernel.org/lkml/20210127105121.20345-1-lukasz.l...@arm.com/ I’ve included the patch and with unscientific testing it feels snappier with a larger value than before. I did revert back to 45 first, but again this feels sluggish when navigating around the Kodi GUI. My main test is to enter ‘Movies’ in Kodi then start scrolling in a long list. When the GPU ramps up quickly the experience is snappy, but when it ramps more conservatively scrolling feels like it stutters, then (once you hit max freq) it becomes fluid. WP2:~ # cat /sys/class/devfreq/d00c.gpu/trans_stat From : To : 12500 25000 285714285 4 5 6 74400 time(ms) * 12500: 0 0 0 0 0 0 264 52720 25000: 9 0 0 0 0 0 36 3404 285714285: 9 3 0 0 0 0 32 2628 4:182013 0 0 0 191 21140 5:1212 863 0 0 31 10068 6: 179 516 13366 0 24 29360 74400:37 5 74660 423 0 46016 I’ll send v2 with the value set to 30. Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10] staging: fbtft: add tearing signal detect
> Comments are the exception to the "no spaces at the start of a line"
> rule. I was expecting that the kbuild-bot would send a Smatch warning
> for inconsistent indenting, but comments are not counted there either.
>
> I'm sort of surprised that we don't have checkpatch rule about the
> missing space characters. It should be: "/* Tearing Effect Line On */".
Maybe this but the "preceded by a tab" test is pretty noisy.
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4f8494527139..72347e82d384 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3720,6 +3720,22 @@ sub process {
s/(\(\s*$Type\s*\))[ \t]+/$1/;
}
}
+
+# Comment styles
+# Initial comment only lines that have a leading space
+ if ($rawline =~ m{^\+([ \t]+)(?:/\*|//)} && $1 =~ / /) {
+ WARN("COMMENT_STYLE",
+"Initial comment lines should be indented only
with tabs\n" . $herecurr);
+# comments not aligned on tabs
+ } elsif ($rawline !~ m{^\+(?:/\*|//)} &&
+$rawline =~ m{^\+.*[^\t](?:/\*|//)}) {
+ CHK("COMMENT_STYLE",
+ "Comments should generally be preceded by a tab\n"
. $herecurr);
+ }
+
+# comment initiators should generally be followed by a space if using words
+ if ($rawline =~ m{^\+.*(?:/\*|//)\w}) {
+ WARN("COMMENT_STYLE",
+"Comment text should use a space after the comment
initiator\n" . $herecurr);
+ }
# Block comment styles
# Networking with an initial /*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, 2021-01-27 at 17:49 +0300, Dan Carpenter wrote: > On Wed, Jan 27, 2021 at 03:25:20PM +0100, Greg KH wrote: > > Andy and Joe, there's something wrong here that is missing the fact that > > a line is being indented with spaces and not tabs in the patch > > at > > https://lore.kernel.org/r/1611754972-151016-1-git-send-email-zhangxuez...@gmail.com > > > > Any ideas what broke? > > /*Tearing Effect Line On*/ > > Comments are the exception to the "no spaces at the start of a line" > rule. I was expecting that the kbuild-bot would send a Smatch warning > for inconsistent indenting, but comments are not counted there either. > > I'm sort of surprised that we don't have checkpatch rule about the > missing space characters. It should be: "/* Tearing Effect Line On */". You could always write your own rule... checkpatch doesn't care if a comment looks like // or /*foobarfoobarfoobar*/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
NIT: This is the second version of this patch so should have "[PATCH
v2]" in the subject.
On 27/01/2021 12:34, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
Signed-off-by: Carsten Haitzler
---
.../gpu/drm/arm/display/include/malidp_utils.h | 10 --
.../gpu/drm/arm/display/komeda/komeda_pipeline.c | 16 +++-
.../arm/display/komeda/komeda_pipeline_state.c | 13 -
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index 3bc383d5bf73..8d289cd0b5b8 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -12,9 +12,15 @@
#define has_bit(nr, mask) (BIT(nr) & (mask))
#define has_bits(bits, mask) (((bits) & (mask)) == (bits))
-
+/*
+#define dp_for_each_set_bit(bit, mask) \
+ for_each_set_bit((bit), (&((unsigned long)(mask))), sizeof(mask) * 8)
+#define dp_for_each_set_bit(bit, mask) \
+ unsigned long __local_mask = mask; \
+ for_each_set_bit((bit), (&__local_mask), sizeof(mask) * 8)
+*/
Commented out code left in - please remove it.
#define dp_for_each_set_bit(bit, mask) \
- for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
+ for_each_set_bit((bit), &(mask), sizeof(mask) * 8)
I'm not really sure if there's much point in this macro now. In practice
the uses below are now getting the wrong length (because sizeof(mask) ==
sizeof(unsigned long) ) but we actually know the size is smaller in most
cases, so we could pass a more appropriate value in.
Other than that the changes below look correct to me.
Steve
#define dp_wait_cond(__cond, __tries, __min_range, __max_range) \
({\
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 719a79728e24..a85c8a806334 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -46,8 +46,9 @@ void komeda_pipeline_destroy(struct komeda_dev *mdev,
{
struct komeda_component *c;
int i;
+ unsigned long avail_comps = pipe->avail_comps;
- dp_for_each_set_bit(i, pipe->avail_comps) {
+ dp_for_each_set_bit(i, avail_comps) {
c = komeda_pipeline_get_component(pipe, i);
komeda_component_destroy(mdev, c);
}
@@ -247,6 +248,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline
*pipe)
{
struct komeda_component *c;
int id;
+ unsigned long avail_comps = pipe->avail_comps;
DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s.\n",
pipe->id, pipe->n_layers, pipe->n_scalers,
@@ -258,7 +260,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline
*pipe)
pipe->of_output_links[1] ?
pipe->of_output_links[1]->full_name : "none");
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ dp_for_each_set_bit(id, avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
komeda_component_dump(c);
@@ -270,8 +272,9 @@ static void komeda_component_verify_inputs(struct
komeda_component *c)
struct komeda_pipeline *pipe = c->pipeline;
struct komeda_component *input;
int id;
+ unsigned long supported_inputs = c->supported_inputs;
- dp_for_each_set_bit(id, c->supported_inputs) {
+ dp_for_each_set_bit(id, supported_inputs) {
input = komeda_pipeline_get_component(pipe, id);
if (!input) {
c->supported_inputs &= ~(BIT(id));
@@ -302,8 +305,9 @@ static void komeda_pipeline_assemble(struct komeda_pipeline
*pipe)
struct komeda_component *c;
struct komeda_layer *layer;
int i, id;
+ unsigned long avail_comps = pipe->avail_comps;
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ dp_for_each_set_bit(id, avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
komeda_component_verify_inputs(c);
}
@@ -355,13 +359,15 @@ void komeda_pipeline_dump_register(struct komeda_pipeline
*pipe,
{
struct komeda_component *c;
u32 id;
+ unsigned long avail_comps;
seq_printf(sf, "\n Pipeline-%d ==\n", pipe->id);
if (pipe->funcs && pipe->funcs->dump_register)
pipe->funcs->dump_register(pipe, sf);
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ avail_comps = pipe->avail_comps;
+
Re: [PATCH] drm/ttm: stop using GFP_TRANSHUGE_LIGHT
On 2021-01-13 2:13 p.m., Christian König wrote:
The only flag we really need is __GFP_NOMEMALLOC, highmem depends on
dma32 and moveable/compound should never be set in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 8cd776adc592..11e0313db0ea 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -79,12 +79,13 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
*pool, gfp_t gfp_flags,
struct page *p;
void *vaddr;
- if (order) {
- gfp_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
+ /* Don't set the __GFP_COMP flag for higher order allocations.
+* Mapping pages directly into an userspace process and calling
+* put_page() on a TTM allocated page is illegal.
+*/
+ if (order)
+ gfp_flags |= __GFP_NOMEMALLOC | __GFP_NORETRY |
__GFP_KSWAPD_RECLAIM;
- gfp_flags &= ~__GFP_MOVABLE;
- gfp_flags &= ~__GFP_COMP;
- }
if (!pool->use_dma_alloc) {
p = alloc_pages(gfp_flags, order);
I picked up this change today, and got the attached splat while running
piglit.
scripts/faddr2line drivers/gpu/drm/ttm/ttm.ko ttm_pool_alloc+0x2e4/0x5e0
gives:
ttm_pool_alloc+0x2e4/0x5e0:
alloc_pages at /home/daenzer/src/linux-git/linux/./include/linux/gfp.h:547
(inlined by) ttm_pool_alloc_page at
/home/daenzer/src/linux-git/linux/drivers/gpu/drm//ttm/ttm_pool.c:91
(inlined by) ttm_pool_alloc at
/home/daenzer/src/linux-git/linux/drivers/gpu/drm//ttm/ttm_pool.c:398
I suspect we need __GFP_NOWARN as well to avoid these splats.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
[ 9556.710241] clinfo: page allocation failure: order:9,
mode:0x194dc2(GFP_HIGHUSER|__GFP_RETRY_MAYFAIL|__GFP_NORETRY|__GFP_ZERO|__GFP_NOMEMALLOC),
nodemask=(null),cpuset=user.slice,mems_allowed=0
[ 9556.710259] CPU: 1 PID: 470821 Comm: clinfo Tainted: GE
5.10.10+ #4
[ 9556.710264] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350
TOMAHAWK (MS-7A34), BIOS 1.OR 11/29/2019
[ 9556.710268] Call Trace:
[ 9556.710281] dump_stack+0x6b/0x83
[ 9556.710288] warn_alloc.cold+0x7b/0xdf
[ 9556.710297] ? __alloc_pages_direct_compact+0x137/0x150
[ 9556.710303] __alloc_pages_slowpath.constprop.0+0xc1b/0xc50
[ 9556.710312] __alloc_pages_nodemask+0x2ec/0x320
[ 9556.710325] ttm_pool_alloc+0x2e4/0x5e0 [ttm]
[ 9556.710332] ? kvmalloc_node+0x46/0x80
[ 9556.710341] ttm_tt_populate+0x37/0xe0 [ttm]
[ 9556.710350] ttm_bo_handle_move_mem+0x142/0x180 [ttm]
[ 9556.710359] ttm_bo_validate+0x11d/0x190 [ttm]
[ 9556.710391] ? drm_vma_offset_add+0x2f/0x60 [drm]
[ 9556.710399] ttm_bo_init_reserved+0x2a7/0x320 [ttm]
[ 9556.710529] amdgpu_bo_do_create+0x1b8/0x500 [amdgpu]
[ 9556.710657] ? amdgpu_bo_subtract_pin_size+0x60/0x60 [amdgpu]
[ 9556.710663] ? get_page_from_freelist+0x11f9/0x1450
[ 9556.710789] amdgpu_bo_create+0x40/0x270 [amdgpu]
[ 9556.710797] ? _raw_spin_unlock+0x16/0x30
[ 9556.710927] amdgpu_gem_create_ioctl+0x123/0x310 [amdgpu]
[ 9556.711062] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
[ 9556.711098] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 9556.711133] drm_ioctl+0x20f/0x3a0 [drm]
[ 9556.711267] ? amdgpu_gem_force_release+0x150/0x150 [amdgpu]
[ 9556.711276] ? preempt_count_sub+0x9b/0xd0
[ 9556.711404] amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[ 9556.711411] __x64_sys_ioctl+0x83/0xb0
[ 9556.711417] do_syscall_64+0x33/0x80
[ 9556.711421] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 9556.711426] RIP: 0033:0x7f14217bdcc7
[ 9556.711431] Code: 00 00 00 48 8b 05 c9 91 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 99 91 0c 00 f7 d8 64 89 01 48
[ 9556.711434] RSP: 002b:7ffd97bfdc68 EFLAGS: 0246 ORIG_RAX:
0010
[ 9556.711439] RAX: ffda RBX: 7ffd97bfdcc0 RCX: 7f14217bdcc7
[ 9556.711442] RDX: 7ffd97bfdcc0 RSI: c0206440 RDI: 0006
[ 9556.711445] RBP: c0206440 R08: 0008 R09: 7f1421887be0
[ 9556.711448] R10: 7ffd97c9e080 R11: 0246 R12: 564dab762d20
[ 9556.711450] R13: 0006 R14: 0020 R15: 0020
[ 9556.711489] Mem-Info:
[ 9556.711499] active_anon:3253 inactive_anon:141494 isolated_anon:0
active_file:1878780 inactive_file:1558064 isolated_file:32
unevictable:0 dirty:6571 writeback:0
slab_reclaimable:123407 slab_unreclaimable:40992
mapped:62091 shmem:3821 pagetables:3837 bounce:0
free:293596 free_pcp:684 free_cma:0
[ 9556.711510] Node 0
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #17 from bola...@163.com --- (In reply to Alex Deucher from comment #16) > (In reply to bolando from comment #15) > > (In reply to Michel Dänzer from comment #14) > > > > If enable 64bit kernel support,I need to recompile everything on > LFS10.0 > > in > > > > next weeks. > > > > > > You shouldn't. 32-bit user-space works fine with a 64-bit kernel. > > > > Thanks for reply.My LFS-10.0 is built for 32bit,I couldn't select 64bit > > kernel config when recompile the Linux kernel.Only 32bit kernel could > > build.I really want to know that the 32bit arch won't be supported by > AMDGPU > > drivers from now on? > > Anecdotally it works for some people. It may depend on the platform and > device. God from AMDGPU drivers development team?I have reviewed the 5.10.11 kernel changelog and found your name! Anecdotally worked on 32bit system ?It seems a few of people use the 32bit systems .The LFS book don't recommend build x86_64 system,so I built 32bit system. The newer kernel does work better on AMDGPU driver,maybe on one day,I can use Raven APU with new Linux kernel expectantly!Thanks a lot! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #16 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to bolando from comment #15) > (In reply to Michel Dänzer from comment #14) > > > If enable 64bit kernel support,I need to recompile everything on LFS10.0 > in > > > next weeks. > > > > You shouldn't. 32-bit user-space works fine with a 64-bit kernel. > > Thanks for reply.My LFS-10.0 is built for 32bit,I couldn't select 64bit > kernel config when recompile the Linux kernel.Only 32bit kernel could > build.I really want to know that the 32bit arch won't be supported by AMDGPU > drivers from now on? Anecdotally it works for some people. It may depend on the platform and device. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 05:49:46PM +0300, Dan Carpenter wrote: > On Wed, Jan 27, 2021 at 03:25:20PM +0100, Greg KH wrote: > > On Wed, Jan 27, 2021 at 10:17:08PM +0800, carlis wrote: > > > On Wed, 27 Jan 2021 15:13:05 +0100 > > > Greg KH wrote: > > > > > > > On Wed, Jan 27, 2021 at 10:08:09PM +0800, carlis wrote: > > > > > On Wed, 27 Jan 2021 14:51:55 +0100 > > > > > Greg KH wrote: > > > > > > > > > > > On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote: > > > > > > > From: zhangxuezhi > > > > > > > > > > > > > > For st7789v ic,when we need continuous full screen refresh, it > > > > > > > is best to wait for the TE signal arrive to avoid screen tearing > > > > > > > > > > > > > > Signed-off-by: zhangxuezhi > > > > > > > > > > > > Please slow down and wait at least a day between patch > > > > > > submissions, there is no rush here. > > > > > > > > > > > > And also, ALWAYS run scripts/checkpatch.pl on your submissions, so > > > > > > that you don't have a maintainer asking you about basic problems, > > > > > > like are in this current patch :( > > > > > > > > > > > > thanks, > > > > > > > > > > > > greg k-h > > > > > > > > > > hi, > > > > > This is my first patch contribution to Linux, so some of the rules > > > > > are not very clear .In addition, I can confirm that before sending > > > > > patch, I check it with checkPatch.py every time.Thank you very much > > > > > for your help > > > > > > > > Please read Documentation/SubmittingPatches which has a link to the > > > > checklist and other documentation you should read. > > > > > > > > And I doubt you are running checkpatch on your submission, as there is > > > > obvious coding style issues in it. If so, please provide the output > > > > as it must be broken :( > > > > > > > > thanks, > > > > > > > > greg k-h > > > hi, the patch v11 checkpatch.pl output is below: > > > > > > carlis@bf-rmsz-10:~/work/linux-kernel/linux$ ./scripts/checkpatch.pl > > > 0001-staging-fbtft-add-tearing-signal-detect.patch total: 0 errors, 0 > > > warnings, 0 checks, 176 lines checked > > > > > > 0001-staging-fbtft-add-tearing-signal-detect.patch has no obvious style > > > problems and is ready for submission. > > > > Wow, my apologies! > > > > Andy and Joe, there's something wrong here that is missing the fact that > > a line is being indented with spaces and not tabs in the patch > > at > > https://lore.kernel.org/r/1611754972-151016-1-git-send-email-zhangxuez...@gmail.com > > > > Any ideas what broke? > > > > /*Tearing Effect Line On*/ > > Comments are the exception to the "no spaces at the start of a line" > rule. I was expecting that the kbuild-bot would send a Smatch warning > for inconsistent indenting, but comments are not counted there either. > > I'm sort of surprised that we don't have checkpatch rule about the > missing space characters. It should be: "/* Tearing Effect Line On */". That was going to be my next question, lots of comments added in this patch don't have spaces... thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 03:25:20PM +0100, Greg KH wrote: > On Wed, Jan 27, 2021 at 10:17:08PM +0800, carlis wrote: > > On Wed, 27 Jan 2021 15:13:05 +0100 > > Greg KH wrote: > > > > > On Wed, Jan 27, 2021 at 10:08:09PM +0800, carlis wrote: > > > > On Wed, 27 Jan 2021 14:51:55 +0100 > > > > Greg KH wrote: > > > > > > > > > On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote: > > > > > > From: zhangxuezhi > > > > > > > > > > > > For st7789v ic,when we need continuous full screen refresh, it > > > > > > is best to wait for the TE signal arrive to avoid screen tearing > > > > > > > > > > > > Signed-off-by: zhangxuezhi > > > > > > > > > > Please slow down and wait at least a day between patch > > > > > submissions, there is no rush here. > > > > > > > > > > And also, ALWAYS run scripts/checkpatch.pl on your submissions, so > > > > > that you don't have a maintainer asking you about basic problems, > > > > > like are in this current patch :( > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > hi, > > > > This is my first patch contribution to Linux, so some of the rules > > > > are not very clear .In addition, I can confirm that before sending > > > > patch, I check it with checkPatch.py every time.Thank you very much > > > > for your help > > > > > > Please read Documentation/SubmittingPatches which has a link to the > > > checklist and other documentation you should read. > > > > > > And I doubt you are running checkpatch on your submission, as there is > > > obvious coding style issues in it. If so, please provide the output > > > as it must be broken :( > > > > > > thanks, > > > > > > greg k-h > > hi, the patch v11 checkpatch.pl output is below: > > > > carlis@bf-rmsz-10:~/work/linux-kernel/linux$ ./scripts/checkpatch.pl > > 0001-staging-fbtft-add-tearing-signal-detect.patch total: 0 errors, 0 > > warnings, 0 checks, 176 lines checked > > > > 0001-staging-fbtft-add-tearing-signal-detect.patch has no obvious style > > problems and is ready for submission. > > Wow, my apologies! > > Andy and Joe, there's something wrong here that is missing the fact that > a line is being indented with spaces and not tabs in the patch > at > https://lore.kernel.org/r/1611754972-151016-1-git-send-email-zhangxuez...@gmail.com > > Any ideas what broke? > /*Tearing Effect Line On*/ Comments are the exception to the "no spaces at the start of a line" rule. I was expecting that the kbuild-bot would send a Smatch warning for inconsistent indenting, but comments are not counted there either. I'm sort of surprised that we don't have checkpatch rule about the missing space characters. It should be: "/* Tearing Effect Line On */". regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/14] drm/ttm: Remap all page faults to per process dummy page.
Hey Daniel, just a ping.
Andrey
On 1/25/21 10:28 AM, Andrey Grodzovsky wrote:
On 1/19/21 8:56 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
On device removal reroute all CPU mappings to dummy page.
v3:
Remove loop to find DRM file and instead access it
by vma->vm_file->private_data. Move dummy page installation
into a separate function.
v4:
Map the entire BOs VA space into on demand allocated dummy page
on the first fault for that BO.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 82
-
include/drm/ttm/ttm_bo_api.h | 2 +
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 6dc96cf..ed89da3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -380,25 +382,103 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault
*vmf,
}
EXPORT_SYMBOL(ttm_bo_vm_fault_reserved);
+static void ttm_bo_release_dummy_page(struct drm_device *dev, void *res)
+{
+ struct page *dummy_page = (struct page *)res;
+
+ __free_page(dummy_page);
+}
+
+vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct ttm_bo_device *bdev = bo->bdev;
+ struct drm_device *ddev = bo->base.dev;
+ vm_fault_t ret = VM_FAULT_NOPAGE;
+ unsigned long address = vma->vm_start;
+ unsigned long num_prefault = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ unsigned long pfn;
+ struct page *page;
+ int i;
+
+ /*
+ * Wait for buffer data in transit, due to a pipelined
+ * move.
+ */
+ ret = ttm_bo_vm_fault_idle(bo, vmf);
+ if (unlikely(ret != 0))
+ return ret;
+
+ /* Allocate new dummy page to map all the VA range in this VMA to it*/
+ page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!page)
+ return VM_FAULT_OOM;
+
+ pfn = page_to_pfn(page);
+
+ /*
+ * Prefault the entire VMA range right away to avoid further faults
+ */
+ for (i = 0; i < num_prefault; ++i) {
+
+ if (unlikely(address >= vma->vm_end))
+ break;
+
+ if (vma->vm_flags & VM_MIXEDMAP)
+ ret = vmf_insert_mixed_prot(vma, address,
+ __pfn_to_pfn_t(pfn, PFN_DEV),
+ prot);
+ else
+ ret = vmf_insert_pfn_prot(vma, address, pfn, prot);
+
+ /* Never error on prefaulted PTEs */
+ if (unlikely((ret & VM_FAULT_ERROR))) {
+ if (i == 0)
+ return VM_FAULT_NOPAGE;
+ else
+ break;
+ }
+
+ address += PAGE_SIZE;
+ }
+
+ /* Set the page to be freed using drmm release action */
+ if (drmm_add_action_or_reset(ddev, ttm_bo_release_dummy_page, page))
+ return VM_FAULT_OOM;
+
+ return ret;
+}
+EXPORT_SYMBOL(ttm_bo_vm_dummy_page);
I think we can lift this entire thing (once the ttm_bo_vm_fault_idle is
gone) to the drm level, since nothing ttm specific in here. Probably stuff
it into drm_gem.c (but really it's not even gem specific, it's fully
generic "replace this vma with dummy pages pls" function.
Once I started with this I noticed that drmm_add_action_or_reset depends
on struct drm_device *ddev = bo->base.dev and bo is the private data
we embed at the TTM level when setting up the mapping and so this forces
to move drmm_add_action_or_reset out of this function to every client who uses
this function, and then you separate the logic of page allocation from it's
release.
So I suggest we keep it as is.
Andrey
Aside from this nit I think the overall approach you have here is starting
to look good. Lots of work, but imo we're getting there and can
start landing stuff soon.
-Daniel
+
vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
pgprot_t prot;
struct ttm_buffer_object *bo = vma->vm_private_data;
+ struct drm_device *ddev = bo->base.dev;
vm_fault_t ret;
+ int idx;
ret = ttm_bo_vm_reserve(bo, vmf);
if (ret)
return ret;
prot = vma->vm_page_prot;
- ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+ if (drm_dev_enter(ddev, )) {
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT, 1);
+ drm_dev_exit(idx);
+ } else {
+ ret = ttm_bo_vm_dummy_page(vmf, prot);
+ }
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
return ret;
dma_resv_unlock(bo->base.resv);
return ret;
+
+ return ret;
}
EXPORT_SYMBOL(ttm_bo_vm_fault);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index e17be32..12fb240 100644
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 10:17:08PM +0800, carlis wrote: > On Wed, 27 Jan 2021 15:13:05 +0100 > Greg KH wrote: > > > On Wed, Jan 27, 2021 at 10:08:09PM +0800, carlis wrote: > > > On Wed, 27 Jan 2021 14:51:55 +0100 > > > Greg KH wrote: > > > > > > > On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote: > > > > > From: zhangxuezhi > > > > > > > > > > For st7789v ic,when we need continuous full screen refresh, it > > > > > is best to wait for the TE signal arrive to avoid screen tearing > > > > > > > > > > Signed-off-by: zhangxuezhi > > > > > > > > Please slow down and wait at least a day between patch > > > > submissions, there is no rush here. > > > > > > > > And also, ALWAYS run scripts/checkpatch.pl on your submissions, so > > > > that you don't have a maintainer asking you about basic problems, > > > > like are in this current patch :( > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > hi, > > > This is my first patch contribution to Linux, so some of the rules > > > are not very clear .In addition, I can confirm that before sending > > > patch, I check it with checkPatch.py every time.Thank you very much > > > for your help > > > > Please read Documentation/SubmittingPatches which has a link to the > > checklist and other documentation you should read. > > > > And I doubt you are running checkpatch on your submission, as there is > > obvious coding style issues in it. If so, please provide the output > > as it must be broken :( > > > > thanks, > > > > greg k-h > hi, the patch v11 checkpatch.pl output is below: > > carlis@bf-rmsz-10:~/work/linux-kernel/linux$ ./scripts/checkpatch.pl > 0001-staging-fbtft-add-tearing-signal-detect.patch total: 0 errors, 0 > warnings, 0 checks, 176 lines checked > > 0001-staging-fbtft-add-tearing-signal-detect.patch has no obvious style > problems and is ready for submission. Wow, my apologies! Andy and Joe, there's something wrong here that is missing the fact that a line is being indented with spaces and not tabs in the patch at https://lore.kernel.org/r/1611754972-151016-1-git-send-email-zhangxuez...@gmail.com Any ideas what broke? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/omap: dsi: fix unreachable code in dsi_vc_send_short()
On 27/01/2021 03:51, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The 'r' in dsi_vc_send_short() is of type 'unsigned int', so the
> 'r < 0' can't be true.
>
> Fix this by introducing a 'err' of type 'int' insteaded.
>
> Fixes: 1ed6253856cb ("drm/omap: dsi: switch dsi_vc_send_long/short to
> mipi_dsi_msg")
>
> Signed-off-by: Menglong Dong
> Reviewed-by: Sebastian Reichel
> ---
> v2:
> - remove word wrap in 'Fixes' tag
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
> b/drivers/gpu/drm/omapdrm/dss/dsi.c
> index 8e11612f5fe1..febcc87ddfe1 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dsi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
> @@ -2149,11 +2149,12 @@ static int dsi_vc_send_short(struct dsi_data *dsi,
> int vc,
>const struct mipi_dsi_msg *msg)
> {
> struct mipi_dsi_packet pkt;
> + int err;
> u32 r;
>
> - r = mipi_dsi_create_packet(, msg);
> - if (r < 0)
> - return r;
> + err = mipi_dsi_create_packet(, msg);
> + if (err)
> + return err;
>
> WARN_ON(!dsi_bus_is_locked(dsi));
>
Thanks! I'll apply to drm-misc-next.
Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11] staging: fbtft: add tearing signal detect
Hi Carlis,
On Wed, Jan 27, 2021 at 3:07 PM Carlis wrote:
> From: zhangxuezhi
>
> For st7789v ic,when we need continuous full screen refresh, it is best to
> wait for the TE signal arrive to avoid screen tearing
>
> Signed-off-by: zhangxuezhi
> ---
> v11: remove devm_gpio_put and change a dev_err to dev_info
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -82,6 +111,32 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (IS_ERR(par->gpio.te)) {
> + rc = PTR_ERR(par->gpio.te);
> + dev_info(par->info->device, "Failed to request te gpio:
> %d\n", rc);
Please slow down and read the feedback.
I said "dev_err_probe()", not "dev_info()".
> + return rc;
> + }
> + if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> +spi_panel_te_handler,
> IRQF_TRIGGER_RISING,
> +"TE_GPIO", par);
> + if (rc) {
> + dev_err(par->info->device, "TE request_irq
> failed.\n");
Same here.
> + return rc;
> + }
> +
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + } else {
> + dev_info(par->info->device, "%s:%d, TE gpio not specified\n",
> +__func__, __LINE__);
> + }
> /* turn off sleep mode */
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> mdelay(120);
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 10:08:09PM +0800, carlis wrote: > On Wed, 27 Jan 2021 14:51:55 +0100 > Greg KH wrote: > > > On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote: > > > From: zhangxuezhi > > > > > > For st7789v ic,when we need continuous full screen refresh, it is > > > best to wait for the TE signal arrive to avoid screen tearing > > > > > > Signed-off-by: zhangxuezhi > > > > Please slow down and wait at least a day between patch submissions, > > there is no rush here. > > > > And also, ALWAYS run scripts/checkpatch.pl on your submissions, so > > that you don't have a maintainer asking you about basic problems, > > like are in this current patch :( > > > > thanks, > > > > greg k-h > > hi, > This is my first patch contribution to Linux, so some of the rules > are not very clear .In addition, I can confirm that before sending > patch, I check it with checkPatch.py every time.Thank you very much for > your help Please read Documentation/SubmittingPatches which has a link to the checklist and other documentation you should read. And I doubt you are running checkpatch on your submission, as there is obvious coding style issues in it. If so, please provide the output as it must be broken :( thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave and Daniel,
Hopefully this is the last pull request towards 5.12.
Please notice this contains a drm/framebuffer change needed for
supporting clear color support for TGL Render Decompression.
Here goes drm-intel-next-2021-01-27:
- HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman)
- Fix DP vswing settings and handling (Imre, Ville)
- Various display code clean-up (Jani, Ville)
- Various display refactoring, including split out of pps, aux, and fdi (Ja\
ni, Dave)
- Add DG1 missing workarounds (Jose)
- Fix display color conversion (Chris, Ville)
- Try to guess PCH type even without ISA bridge (Zhenyu)
- More backlight refactor (Lyude)
- Support two CSC module on gen11 and later (Lee)
- Async flips for all ilk+ platforms (Ville)
- Clear color support for TGL (RK)
- Add a helper to read data from a GEM object page (Imre)
- VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya)
Thanks,
Rodrigo.
The following changes since commit fb5cfcaa2efbb4c71abb1dfbc8f4da727e0bfd89:
Merge tag 'drm-intel-gt-next-2021-01-14' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-01-15 15:03:36
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-01-27
for you to fetch changes up to 784953a46589276b38d7e6dcb5ebf7e29db72ff1:
drm/i915/display/vrr: Skip the VRR HW state readout on DSI transcoder
(2021-01-26 16:34:53 -0800)
- HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (Anshuman)
- Fix DP vswing settings and handling (Imre, Ville)
- Various display code clean-up (Jani, Ville)
- Various display refactoring, including split out of pps, aux, and fdi (Ja\
ni, Dave)
- Add DG1 missing workarounds (Jose)
- Fix display color conversion (Chris, Ville)
- Try to guess PCH type even without ISA bridge (Zhenyu)
- More backlight refactor (Lyude)
- Support two CSC module on gen11 and later (Lee)
- Async flips for all ilk+ platforms (Ville)
- Clear color support for TGL (RK)
- Add a helper to read data from a GEM object page (Imre)
- VRR/Adaptive Sync Enabling on DP/eDP for TGL+ (Manasi, Ville Aditya)
Aditya Swarup (1):
drm/i915/display/dp: Attach and set drm connector VRR property
Anshuman Gupta (21):
drm/i915/hdcp: Update CP property in update_pipe
drm/i915/hdcp: Get conn while content_type changed
drm/i915/hotplug: Handle CP_IRQ for DP-MST
drm/i915/hdcp: No HDCP when encoder is't initialized
drm/i915/hdcp: DP MST transcoder for link and stream
drm/i915/hdcp: Move HDCP enc status timeout to header
drm/i915/hdcp: HDCP stream encryption support
drm/i915/hdcp: Configure HDCP1.4 MST steram encryption status
drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
drm/i915/hdcp: Pass dig_port to intel_hdcp_init
drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
drm/hdcp: Max MST content streams
drm/i915/hdcp: MST streams support in hdcp port_data
drm/i915/hdcp: Pass connector to check_2_2_link
drm/i915/hdcp: Add HDCP 2.2 stream register
drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
drm/i915/hdcp: Configure HDCP2.2 MST steram encryption status
drm/i915/hdcp: Enable HDCP 2.2 MST support
drm/i915/hdcp: Fix WARN_ON(data->k > INTEL_NUM_PIPES)
drm/i915/hdcp: Fix uninitialized symbol
Chris Wilson (1):
drm/i915/display: Bitwise or the conversion colour specifier together
Dave Airlie (3):
drm/i915: refactor some crtc code out of intel display. (v2)
drm/i915: refactor pll code out into intel_dpll.c
drm/i915: split fdi code out from intel_display.c
Imre Deak (3):
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c
drm/i915/dp: Fix LTTPR vswing/pre-emp setting in non-transparent mode
drm/i915/gem: Add a helper to read data from a GEM object page
Jani Nikula (20):
drm/i915/display: remove useless use of inline
drm/i915/display: fix the uint*_t types that have crept in
drm/i915/pps: abstract panel power sequencer from intel_dp.c
drm/i915/pps: rename pps_{,un}lock -> intel_pps_{,un}lock
drm/i915/pps: rename intel_edp_backlight_* to intel_pps_backlight_*
drm/i915/pps: rename intel_edp_panel_* to intel_pps_*
drm/i915/pps: rename edp_panel_* to intel_pps_*_unlocked
drm/i915/pps: abstract intel_pps_vdd_off_sync
drm/i915/pps: add higher level intel_pps_init() call
drm/i915/pps: abstract intel_pps_encoder_reset()
drm/i915/pps: rename intel_dp_check_edp to intel_pps_check_power_unlocked
drm/i915/pps: rename intel_power_sequencer_reset to intel_pps_reset_all
drm/i915/pps: add locked intel_pps_wait_power_cycle
drm/i915/pps: rename vlv_init_panel_power_sequencer to vlv_pps_init
Re: [PATCH v11] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 10:02:29PM +0800, Carlis wrote: > From: zhangxuezhi > > For st7789v ic,when we need continuous full screen refresh, it is best to > wait for the TE signal arrive to avoid screen tearing > > Signed-off-by: zhangxuezhi Again, slow down, and wait for comments before responding so quickly, as you missed all of my review... greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211349] IB test failed on sdma0 ! AMDGPU driver for Raven APU (ryzen 2400G) hangs!
https://bugzilla.kernel.org/show_bug.cgi?id=211349 --- Comment #15 from bola...@163.com --- (In reply to Michel Dänzer from comment #14) > > If enable 64bit kernel support,I need to recompile everything on LFS10.0 in > > next weeks. > > You shouldn't. 32-bit user-space works fine with a 64-bit kernel. Thanks for reply.My LFS-10.0 is built for 32bit,I couldn't select 64bit kernel config when recompile the Linux kernel.Only 32bit kernel could build.I really want to know that the 32bit arch won't be supported by AMDGPU drivers from now on? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vboxvideo: Vmap/vunmap cursor BO in prepare_fb and cleanup_fb
Functions in the atomic commit tail are not allowed to acquire the
dmabuf's reservation lock. So we cannot legally call the GEM object's
vmap functionality in atomic_update.
Instead vmap the cursor BO in prepare_fb and vunmap it in cleanup_fb.
The cursor plane state stores the mapping's address. The pinning of the
BO is implicitly done by vmap.
As an extra benefit, there's no source of runtime errors left in
atomic_update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 102 +-
1 file changed, 82 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index dbc0dd53c69e..b5625a7d6cef 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -324,6 +324,19 @@ static void vbox_primary_atomic_disable(struct drm_plane
*plane,
old_state->src_y >> 16);
}
+struct vbox_cursor_plane_state {
+ struct drm_plane_state base;
+
+ /* Transitional state - do not export or duplicate */
+
+ struct dma_buf_map map;
+};
+
+static struct vbox_cursor_plane_state *to_vbox_cursor_plane_state(struct
drm_plane_state *state)
+{
+ return container_of(state, struct vbox_cursor_plane_state, base);
+}
+
static int vbox_cursor_atomic_check(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -381,14 +394,13 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
container_of(plane->dev, struct vbox_private, ddev);
struct vbox_crtc *vbox_crtc = to_vbox_crtc(plane->state->crtc);
struct drm_framebuffer *fb = plane->state->fb;
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
u32 width = plane->state->crtc_w;
u32 height = plane->state->crtc_h;
+ struct vbox_cursor_plane_state *vbox_state =
to_vbox_cursor_plane_state(plane->state);
+ struct dma_buf_map map = vbox_state->map;
+ u8 *src = map.vaddr; /* TODO: Use mapping abstraction properly */
size_t data_size, mask_size;
u32 flags;
- struct dma_buf_map map;
- int ret;
- u8 *src;
/*
* VirtualBox uses the host windowing system to draw the cursor so
@@ -401,17 +413,6 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
vbox_crtc->cursor_enabled = true;
- ret = drm_gem_vram_vmap(gbo, );
- if (ret) {
- /*
-* BUG: we should have pinned the BO in prepare_fb().
-*/
- mutex_unlock(>hw_mutex);
- DRM_WARN("Could not map cursor bo, skipping update\n");
- return;
- }
- src = map.vaddr; /* TODO: Use mapping abstraction properly */
-
/*
* The mask must be calculated based on the alpha
* channel, one bit per ARGB word, and must be 32-bit
@@ -421,7 +422,6 @@ static void vbox_cursor_atomic_update(struct drm_plane
*plane,
data_size = width * height * 4 + mask_size;
copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
- drm_gem_vram_vunmap(gbo, );
flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
VBOX_MOUSE_POINTER_ALPHA;
@@ -458,6 +458,43 @@ static void vbox_cursor_atomic_disable(struct drm_plane
*plane,
mutex_unlock(>hw_mutex);
}
+static int vbox_cursor_prepare_fb(struct drm_plane *plane, struct
drm_plane_state *new_state)
+{
+ struct vbox_cursor_plane_state *new_vbox_state =
to_vbox_cursor_plane_state(new_state);
+ struct drm_framebuffer *fb = new_state->fb;
+ struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
+ int ret;
+
+ if (!fb)
+ return 0;
+
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
+
+ ret = drm_gem_vram_vmap(gbo, );
+ if (ret)
+ return ret;
+
+ new_vbox_state->map = map;
+
+ return 0;
+}
+
+static void vbox_cursor_cleanup_fb(struct drm_plane *plane, struct
drm_plane_state *old_state)
+{
+ struct vbox_cursor_plane_state *old_vbox_state =
to_vbox_cursor_plane_state(old_state);
+ struct drm_framebuffer *fb = old_state->fb;
+ struct dma_buf_map map = old_vbox_state->map;
+ struct drm_gem_vram_object *gbo;
+
+ if (!fb)
+ return;
+
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
+
+ drm_gem_vram_vunmap(gbo, );
+}
+
static const u32 vbox_cursor_plane_formats[] = {
DRM_FORMAT_ARGB,
};
@@ -466,17 +503,42 @@ static const struct drm_plane_helper_funcs
vbox_cursor_helper_funcs = {
.atomic_check = vbox_cursor_atomic_check,
.atomic_update = vbox_cursor_atomic_update,
.atomic_disable = vbox_cursor_atomic_disable,
- .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
- .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+
Re: [PATCH v10] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 09:42:52PM +0800, Carlis wrote: > From: zhangxuezhi > > For st7789v ic,when we need continuous full screen refresh, it is best to > wait for the TE signal arrive to avoid screen tearing > > Signed-off-by: zhangxuezhi Please slow down and wait at least a day between patch submissions, there is no rush here. And also, ALWAYS run scripts/checkpatch.pl on your submissions, so that you don't have a maintainer asking you about basic problems, like are in this current patch :( thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/13] module: remove EXPORY_UNUSED_SYMBOL*
+++ Christoph Hellwig [21/01/21 08:49 +0100]: EXPORT_UNUSED_SYMBOL* is not actually used anywhere. Remove the unused functionality as we generally just remove unused code anyway. Signed-off-by: Christoph Hellwig --- arch/arm/configs/bcm2835_defconfig | 1 - arch/arm/configs/mxs_defconfig | 1 - arch/mips/configs/nlm_xlp_defconfig | 1 - arch/mips/configs/nlm_xlr_defconfig | 1 - arch/parisc/configs/generic-32bit_defconfig | 1 - arch/parisc/configs/generic-64bit_defconfig | 1 - arch/powerpc/configs/ppc6xx_defconfig | 1 - arch/s390/configs/debug_defconfig | 1 - arch/s390/configs/defconfig | 1 - arch/sh/configs/edosk7760_defconfig | 1 - arch/sh/configs/sdk7780_defconfig | 1 - arch/x86/configs/i386_defconfig | 1 - arch/x86/configs/x86_64_defconfig | 1 - arch/x86/tools/relocs.c | 4 +- include/asm-generic/vmlinux.lds.h | 28 - include/linux/export.h | 8 --- include/linux/module.h | 13 init/Kconfig| 17 - kernel/module.c | 69 ++--- scripts/checkpatch.pl | 6 +- scripts/mod/modpost.c | 39 +--- scripts/mod/modpost.h | 2 - scripts/module.lds.S| 4 -- tools/include/linux/export.h| 2 - 24 files changed, 13 insertions(+), 192 deletions(-) diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig index 44ff9cd88d8161..d6c6c2e031c43a 100644 --- a/arch/arm/configs/bcm2835_defconfig +++ b/arch/arm/configs/bcm2835_defconfig @@ -177,7 +177,6 @@ CONFIG_BOOT_PRINTK_DELAY=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_INFO=y # CONFIG_ENABLE_MUST_CHECK is not set -CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_LOCKUP_DETECTOR=y CONFIG_SCHED_TRACER=y diff --git a/arch/arm/configs/mxs_defconfig b/arch/arm/configs/mxs_defconfig index a9c6f32a9b1c9d..ca32446b187f5d 100644 --- a/arch/arm/configs/mxs_defconfig +++ b/arch/arm/configs/mxs_defconfig @@ -164,7 +164,6 @@ CONFIG_FONTS=y CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO=y CONFIG_FRAME_WARN=2048 -CONFIG_UNUSED_SYMBOLS=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_SOFTLOCKUP_DETECTOR=y diff --git a/arch/mips/configs/nlm_xlp_defconfig b/arch/mips/configs/nlm_xlp_defconfig index 72a211d2d556fd..32c29061172325 100644 --- a/arch/mips/configs/nlm_xlp_defconfig +++ b/arch/mips/configs/nlm_xlp_defconfig @@ -549,7 +549,6 @@ CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=1024 -CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DETECT_HUNG_TASK=y CONFIG_SCHEDSTATS=y diff --git a/arch/mips/configs/nlm_xlr_defconfig b/arch/mips/configs/nlm_xlr_defconfig index 4ecb157e56d427..bf9b9244929ecd 100644 --- a/arch/mips/configs/nlm_xlr_defconfig +++ b/arch/mips/configs/nlm_xlr_defconfig @@ -500,7 +500,6 @@ CONFIG_CRC7=m CONFIG_PRINTK_TIME=y CONFIG_DEBUG_INFO=y # CONFIG_ENABLE_MUST_CHECK is not set -CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DETECT_HUNG_TASK=y CONFIG_SCHEDSTATS=y diff --git a/arch/parisc/configs/generic-32bit_defconfig b/arch/parisc/configs/generic-32bit_defconfig index 3cbcfad5f7249d..7611d48c599e01 100644 --- a/arch/parisc/configs/generic-32bit_defconfig +++ b/arch/parisc/configs/generic-32bit_defconfig @@ -22,7 +22,6 @@ CONFIG_PCI_LBA=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_UNUSED_SYMBOLS=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_BINFMT_MISC=m diff --git a/arch/parisc/configs/generic-64bit_defconfig b/arch/parisc/configs/generic-64bit_defconfig index 8f81fcbf04c413..53054b81461a10 100644 --- a/arch/parisc/configs/generic-64bit_defconfig +++ b/arch/parisc/configs/generic-64bit_defconfig @@ -31,7 +31,6 @@ CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y -CONFIG_UNUSED_SYMBOLS=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BINFMT_MISC=m # CONFIG_COMPACTION is not set diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig index ef09f3cce1fa85..34c3859040f9f7 100644 --- a/arch/powerpc/configs/ppc6xx_defconfig +++ b/arch/powerpc/configs/ppc6xx_defconfig @@ -1072,7 +1072,6 @@ CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_DEBUG_INFO=y -CONFIG_UNUSED_SYMBOLS=y CONFIG_HEADERS_INSTALL=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y diff --git a/arch/s390/configs/debug_defconfig b/arch/s390/configs/debug_defconfig index c4f6ff98a612cd..58e54d17e3154b 100644 --- a/arch/s390/configs/debug_defconfig +++ b/arch/s390/configs/debug_defconfig @@ -71,7 +71,6 @@ CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_MODULE_SIG_SHA256=y -CONFIG_UNUSED_SYMBOLS=y
Re: [PATCH v9] staging: fbtft: add tearing signal detect
Hi Carlis,
On Wed, Jan 27, 2021 at 2:03 PM Carlis wrote:
> From: zhangxuezhi
>
> For st7789v ic,add tearing signal detect to avoid screen tearing
>
> Signed-off-by: zhangxuezhi
> ---
> v9: change pr_* to dev_*
Thanks for the update!
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -9,9 +9,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> -
> +#include
> #include "fbtft.h"
>
> #define DRVNAME "fb_st7789v"
> @@ -66,6 +69,32 @@ enum st7789v_command {
> #define MADCTL_MX BIT(6) /* bitmask for column address order */
> #define MADCTL_MY BIT(7) /* bitmask for page address order */
>
> +#define SPI_PANEL_TE_TIMEOUT 400
> +static struct mutex te_mutex;/*mutex for tearing line*/
> +static struct completion spi_panel_te;
> +
> +static irqreturn_t spi_panel_te_handler(int irq, void *data)
> +{
> + complete(_panel_te);
> + return IRQ_HANDLED;
> +}
> +
> +static void set_spi_panel_te_irq_status(struct fbtft_par *par, bool enable)
> +{
> + static int te_irq_count;
> +
> + mutex_lock(_mutex);
> +
> + if (enable) {
> + if (++te_irq_count == 1)
> + enable_irq(gpiod_to_irq(par->gpio.te));
> + } else {
> + if (--te_irq_count == 0)
> + disable_irq(gpiod_to_irq(par->gpio.te));
> + }
> + mutex_unlock(_mutex);
> +}
> +
> /**
> * init_display() - initialize the display controller
> *
> @@ -82,6 +111,33 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (IS_ERR(par->gpio.te)) {
> + rc = PTR_ERR(par->gpio.te);
> + dev_err(par->info->device, "Failed to request te gpio: %d\n",
> rc);
This also prints an error in case of -EPROBE_DEFER.
dev_err_probe()?
> + return rc;
> + }
> + if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> +spi_panel_te_handler,
> IRQF_TRIGGER_RISING,
> +"TE_GPIO", par);
> + if (rc) {
> + dev_err(par->info->device, "TE request_irq
> failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
No need to call devm_gpiod_put() here, as it's managed automatically.
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/12] drm/ast: Fix cursor BO pinning and mapping
Am 27.01.21 um 13:03 schrieb Thomas Zimmermann:
GEM vmap operations are not allowed in commit tail. Therefore, we cannot
map the cursor source BO in atomic_update. Instead do this in prepare_fb.
There was no pin operation for the BO, so add this as well.
Reviewing drm_gem_vram_vmap() I saw that is pins implicitly. I'll remove
the pinning from the driver code in the patch's next iteration.
Hence the cursor source BO is now mapped while it's being displayed. The
change will allow us to move all cursor damage handling from prepare_fb
to atomic_update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 37 +++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 199ad9f9c932..192d3d34b9ed 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -751,6 +751,10 @@ static void ast_set_cursor_enabled(struct ast_private
*ast, bool enabled)
struct ast_cursor_plane_state {
struct drm_plane_state base;
+
+ /* Transitional state - do not export or duplicate */
+
+ struct dma_buf_map map;
};
static inline struct ast_cursor_plane_state *
@@ -771,6 +775,7 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct dma_buf_map dst_map =
ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
+ struct ast_cursor_plane_state *new_ast_state =
to_ast_cursor_plane_state(new_state);
struct drm_gem_vram_object *src_gbo;
struct dma_buf_map src_map;
void __iomem *dst;
@@ -782,9 +787,13 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
- ret = drm_gem_vram_vmap(src_gbo, _map);
+ ret = drm_gem_vram_pin(src_gbo, 0);
if (ret)
return ret;
+
+ ret = drm_gem_vram_vmap(src_gbo, _map);
+ if (ret)
+ goto err_drm_gem_vram_unpin;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
@@ -792,9 +801,31 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
/* do data transfer to cursor BO */
ast_update_cursor_image(dst, src, fb->width, fb->height);
- drm_gem_vram_vunmap(src_gbo, _map);
+ new_ast_state->map = src_map;
return 0;
+
+err_drm_gem_vram_unpin:
+ drm_gem_vram_unpin(src_gbo);
+ return ret;
+}
+
+static void ast_cursor_plane_helper_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct ast_cursor_plane_state *old_ast_state =
to_ast_cursor_plane_state(old_state);
+ struct drm_framebuffer *fb = old_state->fb;
+ struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
+
+ if (!fb)
+ return;
+
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ map = old_ast_state->map;
+
+ drm_gem_vram_vunmap(gbo, );
+ drm_gem_vram_unpin(gbo);
}
static int ast_cursor_plane_helper_atomic_check(struct drm_plane *plane,
@@ -899,7 +930,7 @@ ast_cursor_plane_helper_atomic_disable(struct drm_plane
*plane,
static const struct drm_plane_helper_funcs ast_cursor_plane_helper_funcs = {
.prepare_fb = ast_cursor_plane_helper_prepare_fb,
- .cleanup_fb = NULL, /* not required for cursor plane */
+ .cleanup_fb = ast_cursor_plane_helper_cleanup_fb,
.atomic_check = ast_cursor_plane_helper_atomic_check,
.atomic_update = ast_cursor_plane_helper_atomic_update,
.atomic_disable = ast_cursor_plane_helper_atomic_disable,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] drm/i915: Remove references to struct drm_device.pdev
Hi Am 27.01.21 um 13:52 schrieb Chris Wilson: Quoting Thomas Zimmermann (2021-01-27 12:41:31) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index 0188f877cab2..2a07a008de2e 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -146,7 +146,6 @@ struct drm_i915_private *mock_gem_device(void) } pci_set_drvdata(pdev, i915); - i915->drm.pdev = pdev; Strictly this removal is still too early. Though it's a mock device and we shouldn't be touching the pci_dev that often, semantically those accesses are not removed until later. I just didn't notice this instance. I'll add it to the other patch. Sorry. Best regards Thomas dev_pm_domain_set(>dev, _domain); pm_runtime_enable(>dev); diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c b/drivers/gpu/drm/i915/selftests/mock_gtt.c index 7270fc8ca801..5c7ae40bba63 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gtt.c +++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c @@ -74,7 +74,7 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private *i915, const char *name) ppgtt->vm.i915 = i915; ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE); ppgtt->vm.file = ERR_PTR(-ENODEV); - ppgtt->vm.dma = >drm.pdev->dev; + ppgtt->vm.dma = i915->drm.dev; We can remove this shorthand later. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9] staging: fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 08:57:37PM +0800, Carlis wrote:
> From: zhangxuezhi
>
> For st7789v ic,add tearing signal detect to avoid screen tearing
I need a much better changelog description here please.
>
> Signed-off-by: zhangxuezhi
> ---
> v9: change pr_* to dev_*
> ---
What changed in all of your previous versions? All of them should be
listed here, right?
> drivers/staging/fbtft/fb_st7789v.c | 132
> -
> drivers/staging/fbtft/fbtft.h | 1 +
> 2 files changed, 132 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_st7789v.c
> b/drivers/staging/fbtft/fb_st7789v.c
> index 3a280cc..9aa2f36 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -9,9 +9,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> -
> +#include
> #include "fbtft.h"
>
> #define DRVNAME "fb_st7789v"
> @@ -66,6 +69,32 @@ enum st7789v_command {
> #define MADCTL_MX BIT(6) /* bitmask for column address order */
> #define MADCTL_MY BIT(7) /* bitmask for page address order */
>
> +#define SPI_PANEL_TE_TIMEOUT 400
What is the units here? Where did this value come from?
> +static struct mutex te_mutex;/*mutex for tearing line*/
Does that look correct???
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v5 4/5] drm/i915: Don't assign to struct drm_device.pdev
Quoting Thomas Zimmermann (2021-01-27 12:41:34) > Using struct drm_device.pdev is deprecated. Don't assign it. Users > should upcast from struct drm_device.dev. > > Signed-off-by: Thomas Zimmermann > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_drv.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 700aeb923fcd..954ad590089c 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -787,7 +787,6 @@ i915_driver_create(struct pci_dev *pdev, const struct > pci_device_id *ent) > if (IS_ERR(i915)) > return i915; > > - i915->drm.pdev = pdev; > pci_set_drvdata(pdev, i915); > > /* Device parameters start as a copy of module parameters. */ Stick the mock - i915->drm.pdev = pdev; in this patch, and I'm happy. With that, the series is Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/5] drm/i915: Remove references to struct drm_device.pdev
Quoting Thomas Zimmermann (2021-01-27 12:41:31) > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > index 0188f877cab2..2a07a008de2e 100644 > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > @@ -146,7 +146,6 @@ struct drm_i915_private *mock_gem_device(void) > } > > pci_set_drvdata(pdev, i915); > - i915->drm.pdev = pdev; Strictly this removal is still too early. Though it's a mock device and we shouldn't be touching the pci_dev that often, semantically those accesses are not removed until later. > > dev_pm_domain_set(>dev, _domain); > pm_runtime_enable(>dev); > diff --git a/drivers/gpu/drm/i915/selftests/mock_gtt.c > b/drivers/gpu/drm/i915/selftests/mock_gtt.c > index 7270fc8ca801..5c7ae40bba63 100644 > --- a/drivers/gpu/drm/i915/selftests/mock_gtt.c > +++ b/drivers/gpu/drm/i915/selftests/mock_gtt.c > @@ -74,7 +74,7 @@ struct i915_ppgtt *mock_ppgtt(struct drm_i915_private > *i915, const char *name) > ppgtt->vm.i915 = i915; > ppgtt->vm.total = round_down(U64_MAX, PAGE_SIZE); > ppgtt->vm.file = ERR_PTR(-ENODEV); > - ppgtt->vm.dma = >drm.pdev->dev; > + ppgtt->vm.dma = i915->drm.dev; We can remove this shorthand later. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/5] drm/i915: Don't assign to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Don't assign it. Users should upcast from struct drm_device.dev. Signed-off-by: Thomas Zimmermann Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 700aeb923fcd..954ad590089c 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -787,7 +787,6 @@ i915_driver_create(struct pci_dev *pdev, const struct pci_device_id *ent) if (IS_ERR(i915)) return i915; - i915->drm.pdev = pdev; pci_set_drvdata(pdev, i915); /* Device parameters start as a copy of module parameters. */ -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/5] drm/i915/gvt: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++--
drivers/gpu/drm/i915/gvt/firmware.c | 10 +-
drivers/gpu/drm/i915/gvt/gtt.c | 12 ++--
drivers/gpu/drm/i915/gvt/gvt.c | 6 +++---
drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
5 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index ad86c5eb5bba..b490e3db2e38 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -374,6 +374,7 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
bool primary)
{
struct intel_gvt *gvt = vgpu->gvt;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
const struct intel_gvt_device_info *info = >device_info;
u16 *gmch_ctl;
u8 next;
@@ -407,9 +408,9 @@ void intel_vgpu_init_cfg_space(struct intel_vgpu *vgpu,
memset(vgpu_cfg_space(vgpu) + INTEL_GVT_PCI_OPREGION, 0, 4);
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_GTTMMIO].size =
- pci_resource_len(gvt->gt->i915->drm.pdev, 0);
+ pci_resource_len(pdev, 0);
vgpu->cfg_space.bar[INTEL_GVT_PCI_BAR_APERTURE].size =
- pci_resource_len(gvt->gt->i915->drm.pdev, 2);
+ pci_resource_len(pdev, 2);
memset(vgpu_cfg_space(vgpu) + PCI_ROM_ADDRESS, 0, 4);
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index 990a181094e3..1a8274a3f4b1 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -76,7 +76,7 @@ static int mmio_snapshot_handler(struct intel_gvt *gvt, u32
offset, void *data)
static int expose_firmware_sysfs(struct intel_gvt *gvt)
{
struct intel_gvt_device_info *info = >device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
void *firmware;
void *p;
@@ -127,7 +127,7 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
static void clean_firmware_sysfs(struct intel_gvt *gvt)
{
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
device_remove_bin_file(>dev, _attr);
vfree(firmware_attr.private);
@@ -151,7 +151,7 @@ static int verify_firmware(struct intel_gvt *gvt,
const struct firmware *fw)
{
struct intel_gvt_device_info *info = >device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct gvt_firmware_header *h;
unsigned long id, crc32_start;
const void *mem;
@@ -205,7 +205,7 @@ static int verify_firmware(struct intel_gvt *gvt,
int intel_gvt_load_firmware(struct intel_gvt *gvt)
{
struct intel_gvt_device_info *info = >device_info;
- struct pci_dev *pdev = gvt->gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
struct intel_gvt_firmware *firmware = >firmware;
struct gvt_firmware_header *h;
const struct firmware *fw;
@@ -240,7 +240,7 @@ int intel_gvt_load_firmware(struct intel_gvt *gvt)
gvt_dbg_core("request hw state firmware %s...\n", path);
- ret = request_firmware(, path, >gt->i915->drm.pdev->dev);
+ ret = request_firmware(, path, gvt->gt->i915->drm.dev);
kfree(path);
if (ret)
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 897c007ea96a..6d12a5a401f6 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -746,7 +746,7 @@ static int detach_oos_page(struct intel_vgpu *vgpu,
static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt *spt)
{
- struct device *kdev = >vgpu->gvt->gt->i915->drm.pdev->dev;
+ struct device *kdev = spt->vgpu->gvt->gt->i915->drm.dev;
trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
@@ -831,7 +831,7 @@ static int reclaim_one_ppgtt_mm(struct intel_gvt *gvt);
static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
struct intel_vgpu *vgpu, enum intel_gvt_gtt_type type)
{
- struct device *kdev = >gvt->gt->i915->drm.pdev->dev;
+ struct device *kdev = vgpu->gvt->gt->i915->drm.dev;
struct intel_vgpu_ppgtt_spt *spt = NULL;
dma_addr_t daddr;
int ret;
@@ -2402,7 +2402,7 @@ static int alloc_scratch_pages(struct intel_vgpu *vgpu,
vgpu->gvt->device_info.gtt_entry_size_shift;
void *scratch_pt;
int i;
- struct device *dev = >gvt->gt->i915->drm.pdev->dev;
+ struct device *dev =
[PATCH v5 5/5] drm: Move struct drm_device.pdev to legacy section
Struct drm_device.pdev is being moved to legacy status as only legacy
DRM drivers use it. A possible follow-up patchset could remove pdev
entirely.
v4:
* rebased
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
---
include/drm/drm_device.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index d647223e8390..c5a195676e8f 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -279,9 +279,6 @@ struct drm_device {
/** @agp: AGP data */
struct drm_agp_head *agp;
- /** @pdev: PCI device structure */
- struct pci_dev *pdev;
-
/** @num_crtcs: Number of CRTCs on this device */
unsigned int num_crtcs;
@@ -324,6 +321,9 @@ struct drm_device {
/* List of devices per driver for stealth attach cleanup */
struct list_head legacy_dev_list;
+ /* PCI device structure */
+ struct pci_dev *pdev;
+
#ifdef __alpha__
/** @hose: PCI hose, only used on ALPHA platforms. */
struct pci_controller *hose;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/5] drm/i915/gt: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +++---
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index ac9e020dbc9e..9b6b9f60336a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1250,7 +1250,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
/* Waiting to drain ELSP? */
if (execlists_active(>execlists)) {
- synchronize_hardirq(engine->i915->drm.pdev->irq);
+ synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
intel_engine_flush_submission(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index dac07d66f658..9c701e5a00bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -769,7 +769,7 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
int ret;
@@ -839,7 +839,7 @@ static struct resource pci_resource(struct pci_dev *pdev,
int bar)
static int gen8_gmch_probe(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
@@ -983,7 +983,7 @@ static u64 iris_pte_encode(dma_addr_t addr,
static int gen6_gmch_probe(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
- struct pci_dev *pdev = i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int size;
u16 snb_gmch_ctl;
@@ -1046,7 +1046,7 @@ static int i915_gmch_probe(struct i915_ggtt *ggtt)
phys_addr_t gmadr_base;
int ret;
- ret = intel_gmch_probe(i915->bridge_dev, i915->drm.pdev, NULL);
+ ret = intel_gmch_probe(i915->bridge_dev, to_pci_dev(i915->drm.dev),
NULL);
if (!ret) {
drm_err(>drm, "failed to set up gmch\n");
return -EIO;
@@ -1091,7 +1091,7 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
ggtt->vm.gt = gt;
ggtt->vm.i915 = i915;
- ggtt->vm.dma = >drm.pdev->dev;
+ ggtt->vm.dma = i915->drm.dev;
if (INTEL_GEN(i915) <= 5)
ret = i915_gmch_probe(ggtt);
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 96b85a10ef33..3f940ae27028 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -301,7 +301,7 @@ void ppgtt_init(struct i915_ppgtt *ppgtt, struct intel_gt
*gt)
ppgtt->vm.gt = gt;
ppgtt->vm.i915 = i915;
- ppgtt->vm.dma = >drm.pdev->dev;
+ ppgtt->vm.dma = i915->drm.dev;
ppgtt->vm.total = BIT_ULL(INTEL_INFO(i915)->ppgtt_size);
i915_address_space_init(>vm, VM_CLASS_PPGTT);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 91c1f58c1b25..3b7e62debe7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -483,14 +483,14 @@ static bool rc6_supported(struct intel_rc6 *rc6)
static void rpm_get(struct intel_rc6 *rc6)
{
GEM_BUG_ON(rc6->wakeref);
- pm_runtime_get_sync(_to_i915(rc6)->drm.pdev->dev);
+ pm_runtime_get_sync(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = true;
}
static void rpm_put(struct intel_rc6 *rc6)
{
GEM_BUG_ON(!rc6->wakeref);
- pm_runtime_put(_to_i915(rc6)->drm.pdev->dev);
+ pm_runtime_put(rc6_to_i915(rc6)->drm.dev);
rc6->wakeref = false;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 107430e1e864..416415b4bbe3 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -177,7 +177,7 @@ static int i915_do_reset(struct intel_gt *gt,
intel_engine_mask_t engine_mask,
unsigned int retry)
{
- struct pci_dev *pdev = gt->i915->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(gt->i915->drm.dev);
int err;
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
@@ -206,7
[PATCH v5 0/5] drm: Move struct drm_device.pdev to legacy
For v5, I moved the non-assignment of pdev in i915 into a separate patch as suggested by Chris. Hopefully, this will help with merging the patches into the rsp i915 trees. The core and vmwgfx changes have been merged into drm-tip already. The pdev field in struct drm_device points to a PCI device structure and goes back to UMS-only days when all DRM drivers were for PCI devices. Meanwhile we also support USB, SPI and platform devices. Each of those uses the generic device stored in struct drm_device.dev. To reduce duplication and remove the special case of PCI, this patchset converts all modesetting drivers from pdev to dev and makes pdev a field for legacy UMS drivers. For PCI devices, the pointer in struct drm_device.dev can be upcasted to struct pci_device; or tested for PCI with dev_is_pci(). In several places the code can use the dev field directly. After converting all drivers and the DRM core, the pdev fields becomes only relevant for legacy drivers. In a later patchset, we may want to convert these as well and remove pdev entirely. v5: * remove assignment in later patch (Chris) v4: * merged several patches * moved core changes into separate patch * vmwgfx build fix v3: * merged several patches * fix one pdev reference in nouveau (Jeremy) * rebases v2: * move whitespace fixes into separate patches (Alex, Sam) * move i915 gt/ and gvt/ changes into separate patches (Joonas) Thomas Zimmermann (5): drm/i915: Remove references to struct drm_device.pdev drm/i915/gt: Remove references to struct drm_device.pdev drm/i915/gvt: Remove references to struct drm_device.pdev drm/i915: Don't assign to struct drm_device.pdev drm: Move struct drm_device.pdev to legacy section drivers/gpu/drm/i915/display/intel_bios.c | 2 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++--- drivers/gpu/drm/i915/display/intel_csr.c | 2 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +- drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +- drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +- .../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++-- drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++--- drivers/gpu/drm/i915/display/intel_overlay.c | 2 +- drivers/gpu/drm/i915/display/intel_panel.c| 4 ++-- drivers/gpu/drm/i915/display/intel_quirks.c | 2 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- drivers/gpu/drm/i915/display/intel_vga.c | 8 drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++--- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 10 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++-- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 8 drivers/gpu/drm/i915/gt/intel_reset.c | 6 +++--- drivers/gpu/drm/i915/gvt/cfg_space.c | 5 +++-- drivers/gpu/drm/i915/gvt/firmware.c | 10 +- drivers/gpu/drm/i915/gvt/gtt.c| 12 +-- drivers/gpu/drm/i915/gvt/gvt.c| 6 +++--- drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++-- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 20 +-- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++--- drivers/gpu/drm/i915/i915_getparam.c | 5 +++-- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- drivers/gpu/drm/i915/i915_pmu.c | 2 +- drivers/gpu/drm/i915/i915_suspend.c | 4 ++-- drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++-- drivers/gpu/drm/i915/i915_vgpu.c | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 2 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +- drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- .../gpu/drm/i915/selftests/mock_gem_device.c | 1 - drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +- include/drm/drm_device.h | 6 +++--- 43 files changed, 100 insertions(+), 101 deletions(-) base-commit: 3836b7fdfad40e2bac5dc882332f42bed6942cf4 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/5] drm/i915: Remove references to struct drm_device.pdev
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v5:
* remove assignment in later patch (Chris)
v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 14 +++---
drivers/gpu/drm/i915/display/intel_csr.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +-
.../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++--
drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 8
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 8
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 19 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
drivers/gpu/drm/i915/i915_getparam.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_pmu.c | 2 +-
drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++--
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
32 files changed, 66 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 987cf509337f..19b8bf0b8aa2 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2098,7 +2098,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t size)
static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 2e878cc274b7..bf83e9e75227 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private
*dev_priv,
static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 hpllcc = 0;
/*
@@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private
*dev_priv,
static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, );
@@ -162,7 +162,7 @@ static void i915gm_get_cdclk(struct drm_i915_private
*dev_priv,
static void i945gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, );
@@ -256,7 +256,7 @@ static unsigned int intel_hpll_vco(struct drm_i915_private
*dev_priv)
static void g33_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
static const u8 div_3200[] = { 12, 10, 8, 7, 5, 16 };
static const u8 div_4000[] = { 14, 12, 10, 8, 6, 20 };
static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
@@ -305,7 +305,7 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
-
Re: [PATCH] drm/komeda: Fix bit check to import to value of proper type
On 1/20/21 3:44 PM, Steven Price wrote:
Sent a new patch to list with updates as discussed.
On 18/01/2021 14:20, carsten.haitz...@foss.arm.com wrote:
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is bueried inside the
NIT: s/bueried/buried/
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
This seems like an underlying bug/lack of clear documentation for the
underlying find_*_bit() functions. dp_for_each_set_bit() tries to do the
right thing:
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask)
* 8)
i.e. passing the actual size of type. However because of the case to
unsigned long (and subsequent accesses using that type) the compiler is
free to make accesses beyond the size of the variable (and indeed this
is completely broken on big-endian). The implementation actually
requires that the bitmap is really an array of unsigned long - no other
type will work.
So I think the fix should also include fixing the dp_for_each_set_bit()
macro - the cast is bogus as it stands.
Doing that I also get warnings on komeda_pipeline::avail_comps and
komeda_pipeline::supported_inputs - although I note there are other
bitmasks mentioned.
The other option is to fix dp_for_each_set_bit() itself using a little
hack:
- for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask)
* 8)
+ for_each_set_bit((bit), (&((unsigned long){mask})), sizeof(mask)
* 8)
With that I don't think you need any other change as the mask is actually
in a new unsigned long on the stack.
Steve
Signed-off-by: Carsten Haitzler
---
.../drm/arm/display/komeda/komeda_pipeline_state.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
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 e8b1e15312d8..f7dddb9f015d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,7 +1232,8 @@ komeda_pipeline_unbound_components(struct
komeda_pipeline *pipe,
struct komeda_pipeline_state *old =
priv_to_pipe_st(pipe->obj.state);
struct komeda_component_state *c_st;
struct komeda_component *c;
- u32 disabling_comps, id;
+ u32 id;
+ unsigned long disabling_comps;
WARN_ON(!old);
@@ -1262,7 +1263,6 @@ int komeda_release_unclaimed_resources(struct
komeda_pipeline *pipe,
st = komeda_pipeline_get_new_state(pipe, drm_st);
else
st = komeda_pipeline_get_state_and_set_crtc(pipe, drm_st,
NULL);
-
NIT: Random white space change
if (WARN_ON(IS_ERR_OR_NULL(st)))
return -EINVAL;
@@ -1287,7 +1287,8 @@ bool komeda_pipeline_disable(struct
komeda_pipeline *pipe,
struct komeda_pipeline_state *old;
struct komeda_component *c;
struct komeda_component_state *c_st;
- u32 id, disabling_comps = 0;
+ u32 id;
+ unsigned long disabling_comps;
old = komeda_pipeline_get_old_state(pipe, old_state);
@@ -1297,7 +1298,7 @@ bool komeda_pipeline_disable(struct
komeda_pipeline *pipe,
disabling_comps = old->active_comps &
pipe->standalone_disabled_comps;
- DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, disabling_comps:
0x%x.\n",
+ DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, disabling_comps:
0x%lx.\n",
pipe->id, old->active_comps, disabling_comps);
dp_for_each_set_bit(id, disabling_comps) {
@@ -1331,13 +1332,14 @@ void komeda_pipeline_update(struct
komeda_pipeline *pipe,
struct komeda_pipeline_state *new =
priv_to_pipe_st(pipe->obj.state);
struct komeda_pipeline_state *old;
struct komeda_component *c;
- u32 id, changed_comps = 0;
+ u32 id;
+ unsigned long changed_comps;
old = komeda_pipeline_get_old_state(pipe, old_state);
changed_comps = new->active_comps | old->active_comps;
- DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, changed: 0x%x.\n",
+ DRM_DEBUG_ATOMIC("PIPE%d: active_comps: 0x%x, changed: 0x%lx.\n",
pipe->id, new->active_comps, changed_comps);
dp_for_each_set_bit(id, changed_comps) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Fix bit check to import to value of proper type
From: Carsten Haitzler
Another issue found by KASAN. The bit finding is buried inside the
dp_for_each_set_bit() macro (that passes on to for_each_set_bit() that
calls the bit stuff. These bit functions want an unsigned long pointer
as input and just dumbly casting leads to out-of-bounds accesses.
This fixes that.
Signed-off-by: Carsten Haitzler
---
.../gpu/drm/arm/display/include/malidp_utils.h | 10 --
.../gpu/drm/arm/display/komeda/komeda_pipeline.c | 16 +++-
.../arm/display/komeda/komeda_pipeline_state.c | 13 -
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index 3bc383d5bf73..8d289cd0b5b8 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -12,9 +12,15 @@
#define has_bit(nr, mask) (BIT(nr) & (mask))
#define has_bits(bits, mask) (((bits) & (mask)) == (bits))
-
+/*
+#define dp_for_each_set_bit(bit, mask) \
+ for_each_set_bit((bit), (&((unsigned long)(mask))), sizeof(mask) * 8)
+#define dp_for_each_set_bit(bit, mask) \
+ unsigned long __local_mask = mask; \
+ for_each_set_bit((bit), (&__local_mask), sizeof(mask) * 8)
+*/
#define dp_for_each_set_bit(bit, mask) \
- for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
+ for_each_set_bit((bit), &(mask), sizeof(mask) * 8)
#define dp_wait_cond(__cond, __tries, __min_range, __max_range)\
({ \
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index 719a79728e24..a85c8a806334 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -46,8 +46,9 @@ void komeda_pipeline_destroy(struct komeda_dev *mdev,
{
struct komeda_component *c;
int i;
+ unsigned long avail_comps = pipe->avail_comps;
- dp_for_each_set_bit(i, pipe->avail_comps) {
+ dp_for_each_set_bit(i, avail_comps) {
c = komeda_pipeline_get_component(pipe, i);
komeda_component_destroy(mdev, c);
}
@@ -247,6 +248,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline
*pipe)
{
struct komeda_component *c;
int id;
+ unsigned long avail_comps = pipe->avail_comps;
DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s.\n",
pipe->id, pipe->n_layers, pipe->n_scalers,
@@ -258,7 +260,7 @@ static void komeda_pipeline_dump(struct komeda_pipeline
*pipe)
pipe->of_output_links[1] ?
pipe->of_output_links[1]->full_name : "none");
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ dp_for_each_set_bit(id, avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
komeda_component_dump(c);
@@ -270,8 +272,9 @@ static void komeda_component_verify_inputs(struct
komeda_component *c)
struct komeda_pipeline *pipe = c->pipeline;
struct komeda_component *input;
int id;
+ unsigned long supported_inputs = c->supported_inputs;
- dp_for_each_set_bit(id, c->supported_inputs) {
+ dp_for_each_set_bit(id, supported_inputs) {
input = komeda_pipeline_get_component(pipe, id);
if (!input) {
c->supported_inputs &= ~(BIT(id));
@@ -302,8 +305,9 @@ static void komeda_pipeline_assemble(struct komeda_pipeline
*pipe)
struct komeda_component *c;
struct komeda_layer *layer;
int i, id;
+ unsigned long avail_comps = pipe->avail_comps;
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ dp_for_each_set_bit(id, avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
komeda_component_verify_inputs(c);
}
@@ -355,13 +359,15 @@ void komeda_pipeline_dump_register(struct komeda_pipeline
*pipe,
{
struct komeda_component *c;
u32 id;
+ unsigned long avail_comps;
seq_printf(sf, "\n Pipeline-%d ==\n", pipe->id);
if (pipe->funcs && pipe->funcs->dump_register)
pipe->funcs->dump_register(pipe, sf);
- dp_for_each_set_bit(id, pipe->avail_comps) {
+ avail_comps = pipe->avail_comps;
+ dp_for_each_set_bit(id, avail_comps) {
c = komeda_pipeline_get_component(pipe, id);
seq_printf(sf, "\n--%s--\n", c->name);
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 e8b1e15312d8..7640dae7f4bf 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -1232,7 +1232,8 @@
[PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
In order to measure how much memory a process actually consumes, it is necessary to include the DMA buffer sizes for that process in the memory accounting. Since the handle to DMA buffers are raw FDs, it is important to be able to identify which processes have FD references to a DMA buffer. Currently, DMA buffer FDs can be accounted using /proc//fd/* and /proc//fdinfo -- both of which are only root readable, as follows: 1. Do a readlink on each FD. 2. If the target path begins with "/dmabuf", then the FD is a dmabuf FD. 3. stat the file to get the dmabuf inode number. 4. Read/ proc//fdinfo/, to get the DMA buffer size. Android captures per-process system memory state when certain low memory events (e.g a foreground app kill) occur, to identify potential memory hoggers. To include a process’s dmabuf usage as part of its memory state, the data collection needs to be fast enough to reflect the memory state at the time of such events. Since reading /proc//fd/ and /proc//fdinfo/ requires root privileges, this approach is not suitable for production builds. Granting root privileges even to a system process increases the attack surface and is highly undesirable. Additionally this is slow as it requires many context switches for searching and getting the dma-buf info. With the addition of per-buffer dmabuf stats in sysfs [1], the DMA buffer details can be queried using their unique inode numbers. This patch proposes adding a /proc//task//dmabuf_fds interface. /proc//task//dmabuf_fds contains a list of inode numbers for every DMA buffer FD that the task has. Entries with the same inode number can appear more than once, indicating the total FD references for the associated DMA buffer. If a thread shares the same files as the group leader then its dmabuf_fds file will be empty, as these dmabufs are reported by the group leader. The interface requires PTRACE_MODE_READ_FSCRED (same as /proc//maps) and allows the efficient accounting of per-process DMA buffer usage without requiring root privileges. (See data below) Performance Comparison: --- The following data compares the time to capture the sizes of all DMA buffers referenced by FDs for all processes on an arm64 android device. --- | Core 0 (Little) | Core 7 (Big) | --- From /fdinfo | 318 ms | 145 ms| --- Inodes from| 114 ms | 27 ms| dmabuf_fds;|(2.8x ^) | (5.4x ^) | data from sysfs| | | --- It can be inferred that in the worst case there is a 2.8x speedup for determining per-process DMA buffer FD sizes, when using the proposed interfaces. [1] https://lore.kernel.org/dri-devel/20210119225723.33-1-hri...@google.com/ Signed-off-by: Kalesh Singh --- Documentation/filesystems/proc.rst | 30 ++ drivers/dma-buf/dma-buf.c | 7 +- fs/proc/Makefile | 1 + fs/proc/base.c | 1 + fs/proc/dma_bufs.c | 159 + fs/proc/internal.h | 1 + include/linux/dma-buf.h| 5 + 7 files changed, 198 insertions(+), 6 deletions(-) create mode 100644 fs/proc/dma_bufs.c diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 2fa69f710e2a..757dd47ab679 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -47,6 +47,7 @@ fixes/update part 1.1 Stefani Seibold June 9 2009 3.10 /proc//timerslack_ns - Task timerslack value 3.11 /proc//patch_state - Livepatch patch operation state 3.12 /proc//arch_status - Task architecture specific information + 3.13 /proc//task//dmabuf_fds - DMA buffers referenced by an FD 4Configuring procfs 4.1 Mount options @@ -2131,6 +2132,35 @@ AVX512_elapsed_ms the task is unlikely an AVX512 user, but depends on the workload and the scheduling scenario, it also could be a false negative mentioned above. +3.13 /proc//task//dmabuf_fds - DMA buffers referenced by an FD +- +This file exposes a list of the inode numbers for every DMA buffer +FD that the task has. + +The same inode number can appear more than once, indicating the total +FD references for the associated DMA buffer. + +The inode number can be used to lookup the DMA buffer information in +the sysfs interface /sys/kernel/dmabuf/buffers//. + +Example Output +~~ +$ cat /proc/612/task/612/dmabuf_fds +30972 30973 45678 49326 + +Permission to access this file is governed by a ptrace access mode +PTRACE_MODE_READ_FSCREDS. + +Threads can have different files when created without specifying +the CLONE_FILES flag. For this
[PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
This patch allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers//exporter_name /sys/kernel/dmabuf/buffers//size /sys/kernel/dmabuf/buffers//attachments//device /sys/kernel/dmabuf/buffers//attachments//map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Currently, this information is exposed in /sys/kernel/debug/dma_buf/bufinfo. However, since debugfs is considered unsafe to be mounted in production, it is being duplicated in sysfs. This information will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). The patch contains the following improvements over the previous version: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 Signed-off-by: Hridya Valsaraju Reported-by: kernel test robot --- Changes in v3: Fix a warning reported by the kernel test robot. Changes in v2: -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition of other DMA-BUF-related sysfs stats in future. Based on feedback from Daniel Vetter. -Each attachment has its own directory to represent attaching devices as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. Thank you both! -Commit messages updated to point to userspace code in AOSP that will read the DMA-BUF sysfs stats. .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 drivers/dma-buf/Kconfig | 11 + drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-sysfs-stats.c | 285 ++ drivers/dma-buf/dma-buf-sysfs-stats.h | 62 drivers/dma-buf/dma-buf.c | 37 +++ include/linux/dma-buf.h | 20 ++ 7 files changed, 468 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index ..6f7c65209f07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/ will contain the + statistics for the DMA-BUF with the unique inode number + +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers//exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers//attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//attachments/ +Date: January 2021
Re: [PATCH v8] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 06:26:46PM +0800, Carlis wrote:
> From: zhangxuezhi
>
> For st7789v ic,add tearing signal detect to avoid screen tearing
>
> Signed-off-by: zhangxuezhi
> ---
> v8: delete a log line
> ---
> drivers/staging/fbtft/fb_st7789v.c | 132
> -
> drivers/staging/fbtft/fbtft.h | 1 +
> 2 files changed, 132 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fbtft/fb_st7789v.c
> b/drivers/staging/fbtft/fb_st7789v.c
> index 3a280cc..de7460c 100644
> --- a/drivers/staging/fbtft/fb_st7789v.c
> +++ b/drivers/staging/fbtft/fb_st7789v.c
> @@ -9,9 +9,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> -
> +#include
> #include "fbtft.h"
>
> #define DRVNAME "fb_st7789v"
> @@ -66,6 +69,32 @@ enum st7789v_command {
> #define MADCTL_MX BIT(6) /* bitmask for column address order */
> #define MADCTL_MY BIT(7) /* bitmask for page address order */
>
> +#define SPI_PANEL_TE_TIMEOUT 400
> +static struct mutex te_mutex;/*mutex for tearing line*/
> +static struct completion spi_panel_te;
> +
> +static irqreturn_t spi_panel_te_handler(int irq, void *data)
> +{
> + complete(_panel_te);
> + return IRQ_HANDLED;
> +}
> +
> +static void set_spi_panel_te_irq_status(struct fbtft_par *par, bool enable)
> +{
> + static int te_irq_count;
> +
> + mutex_lock(_mutex);
> +
> + if (enable) {
> + if (++te_irq_count == 1)
> + enable_irq(gpiod_to_irq(par->gpio.te));
> + } else {
> + if (--te_irq_count == 0)
> + disable_irq(gpiod_to_irq(par->gpio.te));
> + }
> + mutex_unlock(_mutex);
> +}
> +
> /**
> * init_display() - initialize the display controller
> *
> @@ -82,6 +111,33 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (IS_ERR(par->gpio.te)) {
> + rc = PTR_ERR(par->gpio.te);
> + pr_err("Failed to request te gpio: %d\n", rc);
You are a driver, always use dev_* calls, not pr_*.
This should be dev_err().
same for other pr_ functions you add in this patch.
Also, look at other commits for this file and make your subject: line
match them (i.e. you forgot "staging: ")
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] mm: simplify free_highmem_page() and free_reserved_page()
On 27.01.21 12:51, Oscar Salvador wrote: On Tue, Jan 26, 2021 at 07:21:13PM +0100, David Hildenbrand wrote: adjust_managed_page_count() as called by free_reserved_page() properly handles pages in a highmem zone, so we can reuse it for free_highmem_page(). We can now get rid of totalhigh_pages_inc() and simplify free_reserved_page(). Cc: Andrew Morton Cc: Thomas Gleixner Cc: "Peter Zijlstra (Intel)" Cc: Mike Rapoport Cc: Oscar Salvador Cc: Michal Hocko Cc: Wei Yang Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador +#define free_highmem_page(page) free_reserved_page(page) Should we place that under #ifdef CONFIG_HIGHMEM to make clear that it is only used on that config? Maybe the #ifdefery ugliness does not pay off. Yeah, most probably not worth it. -- Thanks, David / dhildenb ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications
Am 27.01.21 um 13:11 schrieb Maarten Lankhorst: Op 27-01-2021 om 01:22 schreef Felix Kuehling: Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: Recently there was a fairly long thread about recoreable hardware page faults, how they can deadlock, and what to do about that. While the discussion is still fresh I figured good time to try and document the conclusions a bit. References: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20210107030127.20393-1-Felix.Kuehling%40amd.com%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7Cbee0aeff80f440bcc52108d8c2bcc11f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637473463245588199%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ncr%2Fqv5lw0ONrYxFvfdcFAXAZ%2BXcJJa6UY%2BxGfcKGVM%3Dreserved=0 Cc: Maarten Lankhorst Cc: Thomas Hellström Cc: "Christian König" Cc: Jerome Glisse Cc: Felix Kuehling Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org -- I'll be away next week, but figured I'll type this up quickly for some comments and to check whether I got this all roughly right. Critique very much wanted on this, so that we can make sure hw which can't preempt (with pagefaults pending) like gfx10 has a clear path to support page faults in upstream. So anything I missed, got wrong or like that would be good. -Daniel --- Documentation/driver-api/dma-buf.rst | 66 1 file changed, 66 insertions(+) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a2133d69872c..e924c1e4f7a3 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -257,3 +257,69 @@ fences in the kernel. This means: userspace is allowed to use userspace fencing or long running compute workloads. This also means no implicit fencing for shared buffers in these cases. + +Recoverable Hardware Page Faults Implications +~ + +Modern hardware supports recoverable page faults, which has a lot of +implications for DMA fences. + +First, a pending page fault obviously holds up the work that's running on the +accelerator and a memory allocation is usually required to resolve the fault. +But memory allocations are not allowed to gate completion of DMA fences, which +means any workload using recoverable page faults cannot use DMA fences for +synchronization. Synchronization fences controlled by userspace must be used +instead. + +On GPUs this poses a problem, because current desktop compositor protocols on +Linus rely on DMA fences, which means without an entirely new userspace stack +built on top of userspace fences, they cannot benefit from recoverable page +faults. The exception is when page faults are only used as migration hints and +never to on-demand fill a memory request. For now this means recoverable page +faults on GPUs are limited to pure compute workloads. + +Furthermore GPUs usually have shared resources between the 3D rendering and +compute side, like compute units or command submission engines. If both a 3D +job with a DMA fence and a compute workload using recoverable page faults are +pending they could deadlock: + +- The 3D workload might need to wait for the compute job to finish and release + hardware resources first. + +- The compute workload might be stuck in a page fault, because the memory + allocation is waiting for the DMA fence of the 3D workload to complete. + +There are a few ways to prevent this problem: + +- Compute workloads can always be preempted, even when a page fault is pending + and not yet repaired. Not all hardware supports this. + +- DMA fence workloads and workloads which need page fault handling have + independent hardware resources to guarantee forward progress. This could be + achieved through e.g. through dedicated engines and minimal compute unit + reservations for DMA fence workloads. + +- The reservation approach could be further refined by only reserving the + hardware resources for DMA fence workloads when they are in-flight. This must + cover the time from when the DMA fence is visible to other threads up to + moment when fence is completed through dma_fence_signal(). + +- As a last resort, if the hardware provides no useful reservation mechanics, + all workloads must be flushed from the GPU when switching between jobs + requiring DMA fences or jobs requiring page fault handling: This means all DMA + fences must complete before a compute job with page fault handling can be + inserted into the scheduler queue. And vice versa, before a DMA fence can be + made visible anywhere in the system, all compute workloads must be preempted + to guarantee all pending GPU page faults are flushed. I thought of another possible workaround: * Partition the memory. Servicing of page faults will use a separate memory pool that
Re: [PATCH] RFC: dma-fence: Document recoverable page fault implications
Op 27-01-2021 om 01:22 schreef Felix Kuehling: > Am 2021-01-21 um 2:40 p.m. schrieb Daniel Vetter: >> Recently there was a fairly long thread about recoreable hardware page >> faults, how they can deadlock, and what to do about that. >> >> While the discussion is still fresh I figured good time to try and >> document the conclusions a bit. >> >> References: >> https://lore.kernel.org/dri-devel/20210107030127.20393-1-felix.kuehl...@amd.com/ >> Cc: Maarten Lankhorst >> Cc: Thomas Hellström >> Cc: "Christian König" >> Cc: Jerome Glisse >> Cc: Felix Kuehling >> Signed-off-by: Daniel Vetter >> Cc: Sumit Semwal >> Cc: linux-me...@vger.kernel.org >> Cc: linaro-mm-...@lists.linaro.org >> -- >> I'll be away next week, but figured I'll type this up quickly for some >> comments and to check whether I got this all roughly right. >> >> Critique very much wanted on this, so that we can make sure hw which >> can't preempt (with pagefaults pending) like gfx10 has a clear path to >> support page faults in upstream. So anything I missed, got wrong or >> like that would be good. >> -Daniel >> --- >> Documentation/driver-api/dma-buf.rst | 66 >> 1 file changed, 66 insertions(+) >> >> diff --git a/Documentation/driver-api/dma-buf.rst >> b/Documentation/driver-api/dma-buf.rst >> index a2133d69872c..e924c1e4f7a3 100644 >> --- a/Documentation/driver-api/dma-buf.rst >> +++ b/Documentation/driver-api/dma-buf.rst >> @@ -257,3 +257,69 @@ fences in the kernel. This means: >>userspace is allowed to use userspace fencing or long running compute >>workloads. This also means no implicit fencing for shared buffers in these >>cases. >> + >> +Recoverable Hardware Page Faults Implications >> +~ >> + >> +Modern hardware supports recoverable page faults, which has a lot of >> +implications for DMA fences. >> + >> +First, a pending page fault obviously holds up the work that's running on >> the >> +accelerator and a memory allocation is usually required to resolve the >> fault. >> +But memory allocations are not allowed to gate completion of DMA fences, >> which >> +means any workload using recoverable page faults cannot use DMA fences for >> +synchronization. Synchronization fences controlled by userspace must be used >> +instead. >> + >> +On GPUs this poses a problem, because current desktop compositor protocols >> on >> +Linus rely on DMA fences, which means without an entirely new userspace >> stack >> +built on top of userspace fences, they cannot benefit from recoverable page >> +faults. The exception is when page faults are only used as migration hints >> and >> +never to on-demand fill a memory request. For now this means recoverable >> page >> +faults on GPUs are limited to pure compute workloads. >> + >> +Furthermore GPUs usually have shared resources between the 3D rendering and >> +compute side, like compute units or command submission engines. If both a 3D >> +job with a DMA fence and a compute workload using recoverable page faults >> are >> +pending they could deadlock: >> + >> +- The 3D workload might need to wait for the compute job to finish and >> release >> + hardware resources first. >> + >> +- The compute workload might be stuck in a page fault, because the memory >> + allocation is waiting for the DMA fence of the 3D workload to complete. >> + >> +There are a few ways to prevent this problem: >> + >> +- Compute workloads can always be preempted, even when a page fault is >> pending >> + and not yet repaired. Not all hardware supports this. >> + >> +- DMA fence workloads and workloads which need page fault handling have >> + independent hardware resources to guarantee forward progress. This could >> be >> + achieved through e.g. through dedicated engines and minimal compute unit >> + reservations for DMA fence workloads. >> + >> +- The reservation approach could be further refined by only reserving the >> + hardware resources for DMA fence workloads when they are in-flight. This >> must >> + cover the time from when the DMA fence is visible to other threads up to >> + moment when fence is completed through dma_fence_signal(). >> + >> +- As a last resort, if the hardware provides no useful reservation >> mechanics, >> + all workloads must be flushed from the GPU when switching between jobs >> + requiring DMA fences or jobs requiring page fault handling: This means >> all DMA >> + fences must complete before a compute job with page fault handling can be >> + inserted into the scheduler queue. And vice versa, before a DMA fence can >> be >> + made visible anywhere in the system, all compute workloads must be >> preempted >> + to guarantee all pending GPU page faults are flushed. > I thought of another possible workaround: > > * Partition the memory. Servicing of page faults will use a separate > memory pool that can always be allocated from without waiting for > fences. This includes memory
Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings
Hi
Am 11.01.21 um 17:50 schrieb Daniel Vetter:
On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
Implementations of the vmap/vunmap GEM callbacks may perform pinning
of the BO and may acquire the associated reservation object's lock.
Callers that only require a mapping of the contained memory can thus
interfere with other tasks that require exact pinning, such as scanout.
This is less of an issue with private SHMEM buffers, but may happen
with imported ones.
Therefore provide the new interfaces drm_gem_shmem_vmap_local() and
drm_gem_shmem_vunmap_local(), which only perform the vmap/vunmap
operations. Callers have to hold the reservation lock while the mapping
persists.
This patch also connects GEM SHMEM helpers to GEM object functions with
equivalent functionality.
v4:
* call dma_buf_{vmap,vunmap}_local() where necessary (Daniel)
* move driver changes into separate patches (Daniel)
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 90 +++---
include/drm/drm_gem_shmem_helper.h | 2 +
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 9825c378dfa6..298832b2b43b 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -32,6 +32,8 @@ static const struct drm_gem_object_funcs drm_gem_shmem_funcs
= {
.get_sg_table = drm_gem_shmem_get_sg_table,
.vmap = drm_gem_shmem_vmap,
.vunmap = drm_gem_shmem_vunmap,
+ .vmap_local = drm_gem_shmem_vmap_local,
+ .vunmap_local = drm_gem_shmem_vunmap_local,
.mmap = drm_gem_shmem_mmap,
};
@@ -261,7 +263,8 @@ void drm_gem_shmem_unpin(struct drm_gem_object *obj)
}
EXPORT_SYMBOL(drm_gem_shmem_unpin);
-static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem, struct dma_buf_map *map)
+static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map,
+bool local)
This is a bit spaghetti and also has the problem that we're not changing
shmem->vmap_use_count under different locks, depending upon which path
we're taking.
I think the cleanest would be if we pull the if (import_attach) case out
of the _locked() version completely, for all cases, and also outside of
the shmem->vmap_lock. This means no caching of vmaps in the shmem layer
anymore for imported buffers, but this is no longer a problem: We cache
them in the exporters instead (I think at least, if not maybe need to fix
that where it's expensive).
There's no vmap refcounting in amdgpu AFAICT. So importing pages from
there into an SHMEM object has the potential of breaking. IIRC same fro
radeon and nouveau.
So I'm somewhat reluctant to making this change. I guess I'll look
elsewhere first to fix some of the locking issues (e.g., my recent ast
cursor patches).
Best regards
Thomas
Other option would be to unly pull it out for the _vmap_local case, but
that's a bit ugly because no longer symmetrical in the various paths.
{
struct drm_gem_object *obj = >base;
int ret = 0;
@@ -272,7 +275,10 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
}
if (obj->import_attach) {
- ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
+ if (local)
+ ret = dma_buf_vmap_local(obj->import_attach->dmabuf,
map);
+ else
+ ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
if (!ret) {
if (WARN_ON(map->is_iomem)) {
ret = -EIO;
@@ -313,7 +319,7 @@ static int drm_gem_shmem_vmap_locked(struct
drm_gem_shmem_object *shmem, struct
return ret;
}
-/*
+/**
* drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
* @shmem: shmem GEM object
* @map: Returns the kernel virtual address of the SHMEM GEM object's backing
@@ -339,15 +345,53 @@ int drm_gem_shmem_vmap(struct drm_gem_object *obj, struct
dma_buf_map *map)
ret = mutex_lock_interruptible(>vmap_lock);
if (ret)
return ret;
- ret = drm_gem_shmem_vmap_locked(shmem, map);
+ ret = drm_gem_shmem_vmap_locked(shmem, map, false);
mutex_unlock(>vmap_lock);
return ret;
}
EXPORT_SYMBOL(drm_gem_shmem_vmap);
+/**
+ * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
+ * store.
+ *
+ * This function makes sure that a contiguous kernel virtual address mapping
+ * exists for the buffer backing the shmem GEM object.
+ *
+ * The function is called with the BO's reservation object locked. Callers must
+ * hold the lock until after unmapping the buffer.
+ *
+ * This function can
Re: [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > This patch allows statistics to be enabled for each DMA-BUF in > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > The following stats will be exposed by the interface: > > /sys/kernel/dmabuf/buffers//exporter_name > /sys/kernel/dmabuf/buffers//size > /sys/kernel/dmabuf/buffers//attachments//device > /sys/kernel/dmabuf/buffers//attachments//map_counter > > The inode_number is unique for each DMA-BUF and was added earlier [1] > in order to allow userspace to track DMA-BUF usage across different > processes. > > Currently, this information is exposed in > /sys/kernel/debug/dma_buf/bufinfo. > However, since debugfs is considered unsafe to be mounted in production, > it is being duplicated in sysfs. > > This information will be used to derive DMA-BUF > per-exporter stats and per-device usage stats for Android Bug reports. > The corresponding userspace changes can be found at [2]. > Telemetry tools will also capture this information(along with other > memory metrics) periodically as well as on important events like a > foreground app kill (which might have been triggered by Low Memory > Killer). It will also contribute to provide a snapshot of the system > memory usage on other events such as OOM kills and Application Not > Responding events. > > A shell script that can be run on a classic Linux environment to read > out the DMA-BUF statistics can be found at [3](suggested by John > Stultz). > > The patch contains the following improvements over the previous version: > 1) Each attachment is represented by its own directory to allow creating > a symlink to the importing device and to also provide room for future > expansion. > 2) The number of distinct mappings of each attachment is exposed in a > separate file. > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > inorder to make the interface expandable in future. > > All of the improvements above are based on suggestions/feedback from > Daniel Vetter and Christian König. > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > [2]: > https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > [3]: > https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > Signed-off-by: Hridya Valsaraju > Reported-by: kernel test robot > --- > Changes in v3: > Fix a warning reported by the kernel test robot. > > Changes in v2: > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > of other DMA-BUF-related sysfs stats in future. Based on feedback from > Daniel Vetter. > -Each attachment has its own directory to represent attaching devices as > symlinks and to introduce map_count as a separate file. Based on > feedback from Daniel Vetter and Christian König. Thank you both! > -Commit messages updated to point to userspace code in AOSP that will > read the DMA-BUF sysfs stats. > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 > drivers/dma-buf/Kconfig | 11 + > drivers/dma-buf/Makefile | 1 + > drivers/dma-buf/dma-buf-sysfs-stats.c | 285 ++ > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 > drivers/dma-buf/dma-buf.c | 37 +++ > include/linux/dma-buf.h | 20 ++ > 7 files changed, 468 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h I don't know the dma-buf code at all, but from a sysfs/kobject point of view, this patch looks good to me: Reviewed-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] drm/ast: Store cursor BOs in cursor plane
The cursor uses two BOs in video RAM to implement double buffering. Store
both in struct ast_cursor_plane.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 11 ++-
drivers/gpu/drm/ast/ast_mode.c | 27 +++
2 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9eefd3f01f4c..4117c49096d4 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -104,6 +104,12 @@ enum ast_tx_chip {
struct ast_cursor_plane {
struct drm_plane base;
+
+ struct {
+ struct drm_gem_vram_object *gbo;
+ } hwc[AST_DEFAULT_HWC_NUM];
+
+ unsigned int next_hwc_index;
};
static inline struct ast_cursor_plane *
@@ -151,11 +157,6 @@ struct ast_private {
int fb_mtrr;
- struct {
- struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
- unsigned int next_index;
- } cursor;
-
struct drm_plane primary_plane;
struct ast_cursor_plane cursor_plane;
struct drm_crtc crtc;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 9dc70aa62fef..dfff30e3d411 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -757,9 +757,10 @@ static int
ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
+ struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
struct drm_framebuffer *fb = new_state->fb;
- struct ast_private *ast = to_ast_private(plane->dev);
- struct drm_gem_vram_object *dst_gbo =
ast->cursor.gbo[ast->cursor.next_index];
+ struct drm_gem_vram_object *dst_gbo =
+ ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
struct drm_gem_vram_object *src_gbo;
struct dma_buf_map src_map, dst_map;
void __iomem *dst;
@@ -826,11 +827,13 @@ static void
ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
+ struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
struct drm_plane_state *state = plane->state;
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = to_ast_private(plane->dev);
struct drm_device *dev = >base;
- struct drm_gem_vram_object *gbo =
ast->cursor.gbo[ast->cursor.next_index];
+ struct drm_gem_vram_object *gbo =
+ ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
unsigned int offset_x, offset_y;
s64 off;
struct dma_buf_map map;
@@ -840,7 +843,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
u8 __iomem *sig;
int ret;
- gbo = ast->cursor.gbo[ast->cursor.next_index];
+ gbo = ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
@@ -849,8 +852,8 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
return; /* Bug: we didn't pin the cursor HW BO to VRAM.
*/
ast_set_cursor_base(ast, off);
- ++ast->cursor.next_index;
- ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
+ ++ast_cursor_plane->next_hwc_index;
+ ast_cursor_plane->next_hwc_index %=
ARRAY_SIZE(ast_cursor_plane->hwc);
}
ret = drm_gem_vram_vmap(gbo, );
@@ -907,12 +910,12 @@ static const struct drm_plane_helper_funcs
ast_cursor_plane_helper_funcs = {
static void ast_cursor_plane_destroy(struct drm_plane *plane)
{
- struct ast_private *ast = to_ast_private(plane->dev);
+ struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
size_t i;
struct drm_gem_vram_object *gbo;
- for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
- gbo = ast->cursor.gbo[i];
+ for (i = 0; i < ARRAY_SIZE(ast_cursor_plane->hwc); ++i) {
+ gbo = ast_cursor_plane->hwc[i].gbo;
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -945,7 +948,7 @@ static int ast_cursor_plane_init(struct ast_private *ast)
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
- for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ for (i = 0; i < ARRAY_SIZE(ast_cursor_plane->hwc); ++i) {
gbo = drm_gem_vram_create(dev, size, 0);
if (IS_ERR(gbo)) {
ret = PTR_ERR(gbo);
@@ -955,7 +958,7 @@ static int ast_cursor_plane_init(struct ast_private *ast)
DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
if (ret)
goto err_drm_gem_vram_put;
- ast->cursor.gbo[i] =
[PATCH 12/12] drm/ast: Store each HW cursor offset after pinning the rsp BO
As HW cursor BOs never move, we can store the offset in VRAM in the
cursor-plane's HWC state. This removes the last possible source of
runtime errors from atomic_update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_mode.c | 19 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 22193cfde255..e82ab8628770 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -108,6 +108,7 @@ struct ast_cursor_plane {
struct {
struct drm_gem_vram_object *gbo;
struct dma_buf_map map;
+ u64 off;
} hwc[AST_DEFAULT_HWC_NUM];
unsigned int next_hwc_index;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 716ed7025b41..6388e6364e8e 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -853,14 +853,12 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
struct ast_cursor_plane_state *ast_state =
to_ast_cursor_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = to_ast_private(plane->dev);
- struct drm_device *dev = >base;
- struct drm_gem_vram_object *dst_gbo =
- ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
struct dma_buf_map dst_map =
ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
+ u64 dst_off =
+ ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].off;
struct dma_buf_map src_map = ast_state->map;
unsigned int offset_x, offset_y;
- s64 off;
u16 x, y;
u8 x_offset, y_offset;
u8 __iomem *dst;
@@ -879,10 +877,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
ast_update_cursor_image(dst, src, fb->width, fb->height);
if (state->fb != old_state->fb) {
- off = drm_gem_vram_offset(dst_gbo);
- if (drm_WARN_ON_ONCE(dev, off < 0))
- return; /* Bug: we didn't pin the cursor HW BO to VRAM.
*/
- ast_set_cursor_base(ast, off);
+ ast_set_cursor_base(ast, dst_off);
++ast_cursor_plane->next_hwc_index;
ast_cursor_plane->next_hwc_index %=
ARRAY_SIZE(ast_cursor_plane->hwc);
@@ -998,6 +993,7 @@ static int ast_cursor_plane_init(struct ast_private *ast)
struct drm_gem_vram_object *gbo;
struct dma_buf_map map;
int ret;
+ s64 off;
/*
* Allocate backing storage for cursors. The BOs are permanently
@@ -1019,8 +1015,14 @@ static int ast_cursor_plane_init(struct ast_private *ast)
ret = drm_gem_vram_vmap(gbo, );
if (ret)
goto err_drm_gem_vram_unpin;
+ off = drm_gem_vram_offset(gbo);
+ if (off < 0) {
+ ret = off;
+ goto err_drm_gem_vram_vunmap;
+ }
ast_cursor_plane->hwc[i].gbo = gbo;
ast_cursor_plane->hwc[i].map = map;
+ ast_cursor_plane->hwc[i].off = off;
}
/*
@@ -1046,6 +1048,7 @@ static int ast_cursor_plane_init(struct ast_private *ast)
--i;
gbo = ast_cursor_plane->hwc[i].gbo;
map = ast_cursor_plane->hwc[i].map;
+err_drm_gem_vram_vunmap:
drm_gem_vram_vunmap(gbo, );
err_drm_gem_vram_unpin:
drm_gem_vram_unpin(gbo);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] drm/ast: Add cursor-plane data structure
Cursor state is currently located throughout struct ast_private. Having
struct ast_cursor_plane as dedicated data structure for cursors helps to
organize the modesetting code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 23 ++-
drivers/gpu/drm/ast/ast_mode.c | 5 +++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 2761fa547c35..9eefd3f01f4c 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -81,6 +81,9 @@ enum ast_tx_chip {
#define AST_DRAM_4Gx16 7
#define AST_DRAM_8Gx16 8
+/*
+ * Cursor plane
+ */
#define AST_MAX_HWC_WIDTH 64
#define AST_MAX_HWC_HEIGHT 64
@@ -99,6 +102,20 @@ enum ast_tx_chip {
#define AST_HWC_SIGNATURE_HOTSPOTX 0x14
#define AST_HWC_SIGNATURE_HOTSPOTY 0x18
+struct ast_cursor_plane {
+ struct drm_plane base;
+};
+
+static inline struct ast_cursor_plane *
+to_ast_cursor_plane(struct drm_plane *plane)
+{
+ return container_of(plane, struct ast_cursor_plane, base);
+}
+
+/*
+ * Connector with i2c channel
+ */
+
struct ast_i2c_chan {
struct i2c_adapter adapter;
struct drm_device *dev;
@@ -116,6 +133,10 @@ to_ast_connector(struct drm_connector *connector)
return container_of(connector, struct ast_connector, base);
}
+/*
+ * Device
+ */
+
struct ast_private {
struct drm_device base;
@@ -136,7 +157,7 @@ struct ast_private {
} cursor;
struct drm_plane primary_plane;
- struct drm_plane cursor_plane;
+ struct ast_cursor_plane cursor_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
struct ast_connector connector;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 968ee0c69ec3..9dc70aa62fef 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -932,7 +932,8 @@ static const struct drm_plane_funcs ast_cursor_plane_funcs
= {
static int ast_cursor_plane_init(struct ast_private *ast)
{
struct drm_device *dev = >base;
- struct drm_plane *cursor_plane = >cursor_plane;
+ struct ast_cursor_plane *ast_cursor_plane = >cursor_plane;
+ struct drm_plane *cursor_plane = _cursor_plane->base;
size_t size, i;
struct drm_gem_vram_object *gbo;
int ret;
@@ -1178,7 +1179,7 @@ static int ast_crtc_init(struct drm_device *dev)
int ret;
ret = drm_crtc_init_with_planes(dev, crtc, >primary_plane,
- >cursor_plane, _crtc_funcs,
+ >cursor_plane.base,
_crtc_funcs,
NULL);
if (ret)
return ret;
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/12] drm/ast: Fix cursor BO pinning and mapping
GEM vmap operations are not allowed in commit tail. Therefore, we cannot
map the cursor source BO in atomic_update. Instead do this in prepare_fb.
There was no pin operation for the BO, so add this as well.
Hence the cursor source BO is now mapped while it's being displayed. The
change will allow us to move all cursor damage handling from prepare_fb
to atomic_update.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 37 +++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 199ad9f9c932..192d3d34b9ed 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -751,6 +751,10 @@ static void ast_set_cursor_enabled(struct ast_private
*ast, bool enabled)
struct ast_cursor_plane_state {
struct drm_plane_state base;
+
+ /* Transitional state - do not export or duplicate */
+
+ struct dma_buf_map map;
};
static inline struct ast_cursor_plane_state *
@@ -771,6 +775,7 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
struct drm_framebuffer *fb = new_state->fb;
struct dma_buf_map dst_map =
ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
+ struct ast_cursor_plane_state *new_ast_state =
to_ast_cursor_plane_state(new_state);
struct drm_gem_vram_object *src_gbo;
struct dma_buf_map src_map;
void __iomem *dst;
@@ -782,9 +787,13 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
- ret = drm_gem_vram_vmap(src_gbo, _map);
+ ret = drm_gem_vram_pin(src_gbo, 0);
if (ret)
return ret;
+
+ ret = drm_gem_vram_vmap(src_gbo, _map);
+ if (ret)
+ goto err_drm_gem_vram_unpin;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
@@ -792,9 +801,31 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
/* do data transfer to cursor BO */
ast_update_cursor_image(dst, src, fb->width, fb->height);
- drm_gem_vram_vunmap(src_gbo, _map);
+ new_ast_state->map = src_map;
return 0;
+
+err_drm_gem_vram_unpin:
+ drm_gem_vram_unpin(src_gbo);
+ return ret;
+}
+
+static void ast_cursor_plane_helper_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state
*old_state)
+{
+ struct ast_cursor_plane_state *old_ast_state =
to_ast_cursor_plane_state(old_state);
+ struct drm_framebuffer *fb = old_state->fb;
+ struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
+
+ if (!fb)
+ return;
+
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ map = old_ast_state->map;
+
+ drm_gem_vram_vunmap(gbo, );
+ drm_gem_vram_unpin(gbo);
}
static int ast_cursor_plane_helper_atomic_check(struct drm_plane *plane,
@@ -899,7 +930,7 @@ ast_cursor_plane_helper_atomic_disable(struct drm_plane
*plane,
static const struct drm_plane_helper_funcs ast_cursor_plane_helper_funcs = {
.prepare_fb = ast_cursor_plane_helper_prepare_fb,
- .cleanup_fb = NULL, /* not required for cursor plane */
+ .cleanup_fb = ast_cursor_plane_helper_cleanup_fb,
.atomic_check = ast_cursor_plane_helper_atomic_check,
.atomic_update = ast_cursor_plane_helper_atomic_update,
.atomic_disable = ast_cursor_plane_helper_atomic_disable,
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 05:58:34PM +0100, Uwe Kleine-König wrote: > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König Acked-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm/ast: Add constants for VGACRCB register bits
Set the bits in VGACRCB with constants. Alo move the rsp code into a
helper function.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 21 +++--
drivers/gpu/drm/ast/ast_drv.h| 3 +++
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index fac1ee79c372..024858371f64 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -236,6 +236,19 @@ static void ast_cursor_set_location(struct ast_private
*ast, u16 x, u16 y,
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
}
+static void ast_set_cursor_enabled(struct ast_private *ast, bool enabled)
+{
+ static const u8 mask = (u8)~(AST_IO_VGACRCB_HWC_16BPP |
+AST_IO_VGACRCB_HWC_ENABLED);
+
+ u8 vgacrcb = AST_IO_VGACRCB_HWC_16BPP;
+
+ if (enabled)
+ vgacrcb |= AST_IO_VGACRCB_HWC_ENABLED;
+
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, mask, vgacrcb);
+}
+
void ast_cursor_show(struct ast_private *ast, int x, int y,
unsigned int offset_x, unsigned int offset_y)
{
@@ -245,7 +258,6 @@ void ast_cursor_show(struct ast_private *ast, int x, int y,
u8 x_offset, y_offset;
u8 __iomem *dst;
u8 __iomem *sig;
- u8 jreg;
int ret;
ret = drm_gem_vram_vmap(gbo, );
@@ -274,13 +286,10 @@ void ast_cursor_show(struct ast_private *ast, int x, int
y,
ast_cursor_set_location(ast, x, y, x_offset, y_offset);
- /* dummy write to fire HWC */
- jreg = 0x02 |
- 0x01; /* enable ARGB cursor */
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg);
+ ast_set_cursor_enabled(ast, true); /* dummy write to fire HWC */
}
void ast_cursor_hide(struct ast_private *ast)
{
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, 0x00);
+ ast_set_cursor_enabled(ast, false);
}
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index f871fc36c2f7..1575e8e636d7 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -179,6 +179,9 @@ struct ast_private *ast_device_create(const struct
drm_driver *drv,
#define AST_IO_VGAIR1_VREFRESH BIT(3)
+#define AST_IO_VGACRCB_HWC_ENABLED BIT(1)
+#define AST_IO_VGACRCB_HWC_16BPP BIT(0) /* set: ARGB, cleared: 2bpp
palette */
+
#define __ast_read(x) \
static inline u##x ast_read##x(struct ast_private *ast, u32 reg) { \
u##x val = 0;\
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] drm/ast: Inline ast cursor-update functions into modesetting code
The logic for cursor updates is now located in the cursor plane's
modesetting code. A number of helper functions remain to modify the
rsp registers and image.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/Makefile | 3 +-
drivers/gpu/drm/ast/ast_cursor.c | 237 ---
drivers/gpu/drm/ast/ast_drv.h| 7 -
drivers/gpu/drm/ast/ast_mode.c | 191 +++--
4 files changed, 181 insertions(+), 257 deletions(-)
delete mode 100644 drivers/gpu/drm/ast/ast_cursor.c
diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 2265a8a624dd..438a2d05b115 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,7 +3,6 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o \
-ast_dp501.o
+ast-y := ast_drv.o ast_main.o ast_mm.o ast_mode.o ast_post.o ast_dp501.o
obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
deleted file mode 100644
index 31c35296a107..
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ /dev/null
@@ -1,237 +0,0 @@
-/*
- * Copyright 2012 Red Hat Inc.
- * Parts based on xf86-video-ast
- * Copyright (c) 2005 ASPEED Technology Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- */
-/*
- * Authors: Dave Airlie
- */
-
-#include
-#include
-
-#include "ast_drv.h"
-
-static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int
height)
-{
- union {
- u32 ul;
- u8 b[4];
- } srcdata32[2], data32;
- union {
- u16 us;
- u8 b[2];
- } data16;
- u32 csum = 0;
- s32 alpha_dst_delta, last_alpha_dst_delta;
- u8 __iomem *dstxor;
- const u8 *srcxor;
- int i, j;
- u32 per_pixel_copy, two_pixel_copy;
-
- alpha_dst_delta = AST_MAX_HWC_WIDTH << 1;
- last_alpha_dst_delta = alpha_dst_delta - (width << 1);
-
- srcxor = src;
- dstxor = (u8 *)dst + last_alpha_dst_delta + (AST_MAX_HWC_HEIGHT -
height) * alpha_dst_delta;
- per_pixel_copy = width & 1;
- two_pixel_copy = width >> 1;
-
- for (j = 0; j < height; j++) {
- for (i = 0; i < two_pixel_copy; i++) {
- srcdata32[0].ul = *((u32 *)srcxor) & 0xf0f0f0f0;
- srcdata32[1].ul = *((u32 *)(srcxor + 4)) & 0xf0f0f0f0;
- data32.b[0] = srcdata32[0].b[1] | (srcdata32[0].b[0] >>
4);
- data32.b[1] = srcdata32[0].b[3] | (srcdata32[0].b[2] >>
4);
- data32.b[2] = srcdata32[1].b[1] | (srcdata32[1].b[0] >>
4);
- data32.b[3] = srcdata32[1].b[3] | (srcdata32[1].b[2] >>
4);
-
- writel(data32.ul, dstxor);
- csum += data32.ul;
-
- dstxor += 4;
- srcxor += 8;
-
- }
-
- for (i = 0; i < per_pixel_copy; i++) {
- srcdata32[0].ul = *((u32 *)srcxor) & 0xf0f0f0f0;
- data16.b[0] = srcdata32[0].b[1] | (srcdata32[0].b[0] >>
4);
- data16.b[1] = srcdata32[0].b[3] | (srcdata32[0].b[2] >>
4);
- writew(data16.us, dstxor);
- csum += (u32)data16.us;
-
- dstxor += 2;
- srcxor += 4;
- }
- dstxor += last_alpha_dst_delta;
- }
-
- /* write checksum + signature */
- dst += AST_HWC_SIZE;
- writel(csum, dst);
- writel(width, dst + AST_HWC_SIGNATURE_SizeX);
- writel(height, dst + AST_HWC_SIGNATURE_SizeY);
- writel(0, dst +
[PATCH 08/12] drm/ast: Map HW cursor BOs permanently
The BOs of the hardware cursor are now mapped permanently while the
cursor plane is being used. This reduces the CPU overhead of the cursor
plane's atomic_update function.
The change also resolves a problem with the vmap call in the commit tail.
The vmap implementation could acquire the DMA reservation lock on the
BO, which is not allowed that late in the atomic update. Removing the
vmap call from atomic_update fixes the issue.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/ast_mode.c | 32 +++-
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 4117c49096d4..22193cfde255 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -107,6 +107,7 @@ struct ast_cursor_plane {
struct {
struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
} hwc[AST_DEFAULT_HWC_NUM];
unsigned int next_hwc_index;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index dfff30e3d411..b9b9badcee00 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -759,10 +759,10 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane
*plane,
{
struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
struct drm_framebuffer *fb = new_state->fb;
- struct drm_gem_vram_object *dst_gbo =
- ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
+ struct dma_buf_map dst_map =
+ ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
struct drm_gem_vram_object *src_gbo;
- struct dma_buf_map src_map, dst_map;
+ struct dma_buf_map src_map;
void __iomem *dst;
void *src;
int ret;
@@ -777,22 +777,14 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane
*plane,
return ret;
src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
- ret = drm_gem_vram_vmap(dst_gbo, _map);
- if (ret)
- goto err_drm_gem_vram_vunmap;
dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
/* do data transfer to cursor BO */
ast_update_cursor_image(dst, src, fb->width, fb->height);
- drm_gem_vram_vunmap(dst_gbo, _map);
drm_gem_vram_vunmap(src_gbo, _map);
return 0;
-
-err_drm_gem_vram_vunmap:
- drm_gem_vram_vunmap(src_gbo, _map);
- return ret;
}
static int ast_cursor_plane_helper_atomic_check(struct drm_plane *plane,
@@ -841,9 +833,9 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
u8 x_offset, y_offset;
u8 __iomem *dst;
u8 __iomem *sig;
- int ret;
gbo = ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
+ map = ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
@@ -856,17 +848,12 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
ast_cursor_plane->next_hwc_index %=
ARRAY_SIZE(ast_cursor_plane->hwc);
}
- ret = drm_gem_vram_vmap(gbo, );
- if (drm_WARN_ONCE(dev, ret, "drm_gem_vram_vmap() failed, ret=%d\n",
ret))
- return;
dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
sig = dst + AST_HWC_SIZE;
writel(state->crtc_x, sig + AST_HWC_SIGNATURE_X);
writel(state->crtc_y, sig + AST_HWC_SIGNATURE_Y);
- drm_gem_vram_vunmap(gbo, );
-
offset_x = AST_MAX_HWC_WIDTH - fb->width;
offset_y = AST_MAX_HWC_HEIGHT - fb->height;
@@ -913,9 +900,12 @@ static void ast_cursor_plane_destroy(struct drm_plane
*plane)
struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
size_t i;
struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
for (i = 0; i < ARRAY_SIZE(ast_cursor_plane->hwc); ++i) {
gbo = ast_cursor_plane->hwc[i].gbo;
+ map = ast_cursor_plane->hwc[i].map;
+ drm_gem_vram_vunmap(gbo, );
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -939,6 +929,7 @@ static int ast_cursor_plane_init(struct ast_private *ast)
struct drm_plane *cursor_plane = _cursor_plane->base;
size_t size, i;
struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
int ret;
/*
@@ -958,7 +949,11 @@ static int ast_cursor_plane_init(struct ast_private *ast)
DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
if (ret)
goto err_drm_gem_vram_put;
+ ret = drm_gem_vram_vmap(gbo, );
+ if (ret)
+ goto err_drm_gem_vram_unpin;
[PATCH 02/12] drm/ast: Fix invalid usage of AST_MAX_HWC_WIDTH in cursor atomic_check
Use AST_MAX_HWC_HEIGHT for setting offset_y in the cursor plane's
atomic_check. The code used AST_MAX_HWC_WIDTH instead. This worked
because both constants has the same value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 988b270fea5e..758c69aa7232 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -688,7 +688,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
unsigned int offset_x, offset_y;
offset_x = AST_MAX_HWC_WIDTH - fb->width;
- offset_y = AST_MAX_HWC_WIDTH - fb->height;
+ offset_y = AST_MAX_HWC_HEIGHT - fb->height;
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/ast: Initialize planes in helper functions
This change will help with inlining cursor functions into modesetting
code. The primary plane's field used to be cleared with memset(). This
has been dropped as the memory is always allocated with kzalloc().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 66 +++---
1 file changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 758c69aa7232..f86773a869f0 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -621,6 +621,26 @@ static const struct drm_plane_funcs
ast_primary_plane_funcs = {
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
+static int ast_primary_plane_init(struct ast_private *ast)
+{
+ struct drm_device *dev = >base;
+ struct drm_plane *primary_plane = >primary_plane;
+ int ret;
+
+ ret = drm_universal_plane_init(dev, primary_plane, 0x01,
+ _primary_plane_funcs,
+ ast_primary_plane_formats,
+ ARRAY_SIZE(ast_primary_plane_formats),
+ NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
+ if (ret) {
+ drm_err(dev, "drm_universal_plane_init() failed: %d\n", ret);
+ return ret;
+ }
+ drm_plane_helper_add(primary_plane, _primary_plane_helper_funcs);
+
+ return 0;
+}
+
/*
* Cursor plane
*/
@@ -725,6 +745,26 @@ static const struct drm_plane_funcs ast_cursor_plane_funcs
= {
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
+static int ast_cursor_plane_init(struct ast_private *ast)
+{
+ struct drm_device *dev = >base;
+ struct drm_plane *cursor_plane = >cursor_plane;
+ int ret;
+
+ ret = drm_universal_plane_init(dev, cursor_plane, 0x01,
+ _cursor_plane_funcs,
+ ast_cursor_plane_formats,
+ ARRAY_SIZE(ast_cursor_plane_formats),
+ NULL, DRM_PLANE_TYPE_CURSOR, NULL);
+ if (ret) {
+ drm_err(dev, "drm_universal_plane_failed(): %d\n", ret);
+ return ret;
+ }
+ drm_plane_helper_add(cursor_plane, _cursor_plane_helper_funcs);
+
+ return 0;
+}
+
/*
* CRTC
*/
@@ -1138,30 +1178,14 @@ int ast_mode_config_init(struct ast_private *ast)
dev->mode_config.helper_private = _mode_config_helper_funcs;
- memset(>primary_plane, 0, sizeof(ast->primary_plane));
- ret = drm_universal_plane_init(dev, >primary_plane, 0x01,
- _primary_plane_funcs,
- ast_primary_plane_formats,
- ARRAY_SIZE(ast_primary_plane_formats),
- NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
- if (ret) {
- drm_err(dev, "ast: drm_universal_plane_init() failed: %d\n",
ret);
+
+ ret = ast_primary_plane_init(ast);
+ if (ret)
return ret;
- }
- drm_plane_helper_add(>primary_plane,
-_primary_plane_helper_funcs);
- ret = drm_universal_plane_init(dev, >cursor_plane, 0x01,
- _cursor_plane_funcs,
- ast_cursor_plane_formats,
- ARRAY_SIZE(ast_cursor_plane_formats),
- NULL, DRM_PLANE_TYPE_CURSOR, NULL);
- if (ret) {
- drm_err(dev, "drm_universal_plane_failed(): %d\n", ret);
+ ret = ast_cursor_plane_init(ast);
+ if (ret)
return ret;
- }
- drm_plane_helper_add(>cursor_plane,
-_cursor_plane_helper_funcs);
ast_crtc_init(dev);
ast_encoder_init(dev);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] drm/ast: Allocate HW cursor BOs during cursor-plane initialization
The BOs are eventually released by the cursor plane's destroy callback.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_cursor.c | 58 --
drivers/gpu/drm/ast/ast_drv.h| 1 -
drivers/gpu/drm/ast/ast_mode.c | 62
3 files changed, 55 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 024858371f64..31c35296a107 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -32,64 +32,6 @@
#include "ast_drv.h"
-static void ast_cursor_fini(struct ast_private *ast)
-{
- size_t i;
- struct drm_gem_vram_object *gbo;
-
- for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
- gbo = ast->cursor.gbo[i];
- drm_gem_vram_unpin(gbo);
- drm_gem_vram_put(gbo);
- }
-}
-
-static void ast_cursor_release(struct drm_device *dev, void *ptr)
-{
- struct ast_private *ast = to_ast_private(dev);
-
- ast_cursor_fini(ast);
-}
-
-/*
- * Allocate cursor BOs and pin them at the end of VRAM.
- */
-int ast_cursor_init(struct ast_private *ast)
-{
- struct drm_device *dev = >base;
- size_t size, i;
- struct drm_gem_vram_object *gbo;
- int ret;
-
- size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
-
- for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
- gbo = drm_gem_vram_create(dev, size, 0);
- if (IS_ERR(gbo)) {
- ret = PTR_ERR(gbo);
- goto err_drm_gem_vram_put;
- }
- ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
- DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
- if (ret) {
- drm_gem_vram_put(gbo);
- goto err_drm_gem_vram_put;
- }
- ast->cursor.gbo[i] = gbo;
- }
-
- return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
-
-err_drm_gem_vram_put:
- while (i) {
- --i;
- gbo = ast->cursor.gbo[i];
- drm_gem_vram_unpin(gbo);
- drm_gem_vram_put(gbo);
- }
- return ret;
-}
-
static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int
height)
{
union {
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 1575e8e636d7..c9c3950449b5 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -318,7 +318,6 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev);
void ast_init_3rdtx(struct drm_device *dev);
/* ast_cursor.c */
-int ast_cursor_init(struct ast_private *ast);
int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
void ast_cursor_page_flip(struct ast_private *ast);
void ast_cursor_show(struct ast_private *ast, int x, int y,
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index f86773a869f0..99b6f7c5cb2f 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -736,10 +736,25 @@ static const struct drm_plane_helper_funcs
ast_cursor_plane_helper_funcs = {
.atomic_disable = ast_cursor_plane_helper_atomic_disable,
};
+static void ast_cursor_plane_destroy(struct drm_plane *plane)
+{
+ struct ast_private *ast = to_ast_private(plane->dev);
+ size_t i;
+ struct drm_gem_vram_object *gbo;
+
+ for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ gbo = ast->cursor.gbo[i];
+ drm_gem_vram_unpin(gbo);
+ drm_gem_vram_put(gbo);
+ }
+
+ drm_plane_cleanup(plane);
+}
+
static const struct drm_plane_funcs ast_cursor_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = drm_plane_cleanup,
+ .destroy = ast_cursor_plane_destroy,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
@@ -749,20 +764,57 @@ static int ast_cursor_plane_init(struct ast_private *ast)
{
struct drm_device *dev = >base;
struct drm_plane *cursor_plane = >cursor_plane;
+ size_t size, i;
+ struct drm_gem_vram_object *gbo;
int ret;
+ /*
+* Allocate backing storage for cursors. The BOs are permanently
+* pinned to the top end of the VRAM.
+*/
+
+ size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
+
+ for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+ gbo = drm_gem_vram_create(dev, size, 0);
+ if (IS_ERR(gbo)) {
+ ret = PTR_ERR(gbo);
+ goto err_hwc;
+ }
+ ret = drm_gem_vram_pin(gbo,
[PATCH 11/12] drm/ast: Move all of the cursor-update functionality to atomic_update
We used to update the cursor image in prepare_fb. Move all this code to
atomic_update (were it belongs). Prepare_fb only prepares the source BO.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 56 +-
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 192d3d34b9ed..716ed7025b41 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -771,42 +771,30 @@ static int
ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
- struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
struct drm_framebuffer *fb = new_state->fb;
- struct dma_buf_map dst_map =
- ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
struct ast_cursor_plane_state *new_ast_state =
to_ast_cursor_plane_state(new_state);
- struct drm_gem_vram_object *src_gbo;
- struct dma_buf_map src_map;
- void __iomem *dst;
- void *src;
+ struct drm_gem_vram_object *gbo;
+ struct dma_buf_map map;
int ret;
if (!fb)
return 0;
- src_gbo = drm_gem_vram_of_gem(fb->obj[0]);
+ gbo = drm_gem_vram_of_gem(fb->obj[0]);
- ret = drm_gem_vram_pin(src_gbo, 0);
+ ret = drm_gem_vram_pin(gbo, 0);
if (ret)
return ret;
- ret = drm_gem_vram_vmap(src_gbo, _map);
+ ret = drm_gem_vram_vmap(gbo, );
if (ret)
goto err_drm_gem_vram_unpin;
- src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
-
- dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
-
- /* do data transfer to cursor BO */
- ast_update_cursor_image(dst, src, fb->width, fb->height);
-
- new_ast_state->map = src_map;
+ new_ast_state->map = map;
return 0;
err_drm_gem_vram_unpin:
- drm_gem_vram_unpin(src_gbo);
+ drm_gem_vram_unpin(gbo);
return ret;
}
@@ -862,25 +850,36 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
{
struct ast_cursor_plane *ast_cursor_plane = to_ast_cursor_plane(plane);
struct drm_plane_state *state = plane->state;
+ struct ast_cursor_plane_state *ast_state =
to_ast_cursor_plane_state(state);
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = to_ast_private(plane->dev);
struct drm_device *dev = >base;
- struct drm_gem_vram_object *gbo =
+ struct drm_gem_vram_object *dst_gbo =
ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
+ struct dma_buf_map dst_map =
+ ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
+ struct dma_buf_map src_map = ast_state->map;
unsigned int offset_x, offset_y;
s64 off;
- struct dma_buf_map map;
u16 x, y;
u8 x_offset, y_offset;
u8 __iomem *dst;
u8 __iomem *sig;
+ const u8 *src;
- gbo = ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].gbo;
- map = ast_cursor_plane->hwc[ast_cursor_plane->next_hwc_index].map;
+ src = src_map.vaddr; /* TODO: Use mapping abstraction properly */
+ dst = dst_map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
+ sig = dst + AST_HWC_SIZE; /* TODO: Use mapping abstraction properly */
+
+ /*
+* Do data transfer to HW cursor BO. If a new cursor image was
installed,
+* point the scanout engine to dst_gbo's offset and page-flip the HWC
buffers.
+*/
+
+ ast_update_cursor_image(dst, src, fb->width, fb->height);
if (state->fb != old_state->fb) {
- /* A new cursor image was installed. */
- off = drm_gem_vram_offset(gbo);
+ off = drm_gem_vram_offset(dst_gbo);
if (drm_WARN_ON_ONCE(dev, off < 0))
return; /* Bug: we didn't pin the cursor HW BO to VRAM.
*/
ast_set_cursor_base(ast, off);
@@ -889,9 +888,10 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
ast_cursor_plane->next_hwc_index %=
ARRAY_SIZE(ast_cursor_plane->hwc);
}
- dst = map.vaddr_iomem; /* TODO: Use mapping abstraction properly */
+ /*
+* Update location in HWC signature and registers.
+*/
- sig = dst + AST_HWC_SIZE;
writel(state->crtc_x, sig + AST_HWC_SIGNATURE_X);
writel(state->crtc_y, sig + AST_HWC_SIGNATURE_Y);
@@ -915,7 +915,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane
*plane,
ast_set_cursor_location(ast, x, y, x_offset, y_offset);
- /* dummy write to fire HWC */
+ /* Dummy write to enable HWC and make the HW pick-up the changes. */
ast_set_cursor_enabled(ast, true);
}
--
2.30.0
[PATCH 09/12] drm/ast: Introduce dedicated cursor-plane state
The cursor-plane state struct ast_cursor_plane_state will store the
involved cursor source BO's mapping into kernel address space.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 40 --
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index b9b9badcee00..199ad9f9c932 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -749,6 +749,16 @@ static void ast_set_cursor_enabled(struct ast_private
*ast, bool enabled)
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, mask, vgacrcb);
}
+struct ast_cursor_plane_state {
+ struct drm_plane_state base;
+};
+
+static inline struct ast_cursor_plane_state *
+to_ast_cursor_plane_state(struct drm_plane_state *state)
+{
+ return container_of(state, struct ast_cursor_plane_state, base);
+}
+
static const uint32_t ast_cursor_plane_formats[] = {
DRM_FORMAT_ARGB,
};
@@ -913,13 +923,39 @@ static void ast_cursor_plane_destroy(struct drm_plane
*plane)
drm_plane_cleanup(plane);
}
+static struct drm_plane_state *
+ast_cursor_plane_atomic_duplicate_state(struct drm_plane *plane)
+{
+ struct ast_cursor_plane_state *new_ast_state;
+ struct drm_device *dev = plane->dev;
+
+ if (drm_WARN_ON(dev, !plane->state))
+ return NULL;
+
+ new_ast_state = kmalloc(sizeof(*new_ast_state), GFP_KERNEL);
+ if (!new_ast_state)
+ return NULL;
+ __drm_atomic_helper_plane_duplicate_state(plane, _ast_state->base);
+
+ return _ast_state->base;
+}
+
+static void ast_cursor_plane_atomic_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct ast_cursor_plane_state *ast_state =
to_ast_cursor_plane_state(state);
+
+ __drm_atomic_helper_plane_destroy_state(_state->base);
+ kfree(ast_state);
+}
+
static const struct drm_plane_funcs ast_cursor_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = ast_cursor_plane_destroy,
.reset = drm_atomic_helper_plane_reset,
- .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+ .atomic_duplicate_state = ast_cursor_plane_atomic_duplicate_state,
+ .atomic_destroy_state = ast_cursor_plane_atomic_destroy_state,
};
static int ast_cursor_plane_init(struct ast_private *ast)
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] drm/ast: Move cursor vmap calls out of commit tail
Ast has vmap calls in its cursor's atomic_update function. This is not supported as vmap might aquire the dma reservation lock. While at it, cleanup the whole cursor code: the patchset removes all possible runtime errors from the atomic_update function and reduces the overhead from vmap calls on the HW cursor BOs to a minimum. Patches 1 to 3 update the cursor code and prepare before the refactoring. Patch 4 and 5 inline the cursor update logic into the rsp cursor-plane functions. This is mostly about moving code around. Patches 6 to 8 and 12 add a dedicated cursor plane that maintains the two BOs for HW cursors. The HW cursor BOs are permanently pinned and vmapped while the cursor plane is initialized. Thus removing the related vmap operations from atomic_update. Patches 9 to 11 moves more vmap code out of atomic_update. BOs with cursor image data from userspace are vmapped and vunmapped in prepare_fb and cleanup_fb. Instead the actual update of the cursor image is moved from prepare_fb to atomic_update. With the patchset applied, all cursor preparation is performed before the commit-tail functions; while the actual update is performed within. Tested by running X11 and Weston on ast hardware. Thomas Zimmermann (12): drm/ast: Add constants for VGACRCB register bits drm/ast: Fix invalid usage of AST_MAX_HWC_WIDTH in cursor atomic_check drm/ast: Initialize planes in helper functions drm/ast: Allocate HW cursor BOs during cursor-plane initialization drm/ast: Inline ast cursor-update functions into modesetting code drm/ast: Add cursor-plane data structure drm/ast: Store cursor BOs in cursor plane drm/ast: Map HW cursor BOs permanently drm/ast: Introduce dedicated cursor-plane state drm/ast: Fix cursor BO pinning and mapping drm/ast: Move all of the cursor-update functionality to atomic_update drm/ast: Store each HW cursor offset after pinning the rsp BO drivers/gpu/drm/ast/Makefile | 3 +- drivers/gpu/drm/ast/ast_cursor.c | 286 -- drivers/gpu/drm/ast/ast_drv.h| 47 ++-- drivers/gpu/drm/ast/ast_mode.c | 397 +++ 4 files changed, 389 insertions(+), 344 deletions(-) delete mode 100644 drivers/gpu/drm/ast/ast_cursor.c base-commit: 3836b7fdfad40e2bac5dc882332f42bed6942cf4 prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d -- 2.30.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] procfs/dmabuf: Add /proc//task//dmabuf_fds
Am 27.01.21 um 12:02 schrieb Michal Hocko:
On Wed 27-01-21 11:53:55, Christian König wrote:
[...]
In general processes are currently not held accountable for memory they
reference through their file descriptors. DMA-buf is just one special case.
True
In other words you can currently do something like this
fd = memfd_create("test", 0);
while (1)
write(fd, buf, 1024);
and the OOM killer will terminate random processes, but never the one
holding the memfd reference.
memfd is just shmem under cover, no? And that means that the memory gets
accounted to MM_SHMEMPAGES. But you are right that this in its own
doesn't help much if the fd is shared and the memory stays behind a
killed victim.
I think so, yes. But I just tested this and it doesn't seem to work
correctly.
When I run the few lines above the OOM killer starts to terminate
processes, but since my small test program uses very very little memory
basically everything else gets terminated (including X, desktop, sshd
etc..) before it is terminated as well.
Regards,
Christian.
But I do agree with you that there are resources which are bound to a
process life time but the oom killer has no idea about those as they are
not accounted on a per process level and/or oom_badness doesn't take
them into consideration.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
