date:20201124

On Mon, Nov 23, 2020 at 12:56:44PM +0100, Thomas Zimmermann wrote:
> This patchset moves CMA's mmap into a GEM object function. This change
> allows for removing CMA's mmap and gem_prime_mmap callbacks in favor of
> the default implementation.
> 
> Tested with vc4 on RPi3.

For both patches,
Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/fb/gp102-: use flexible-array member instead of zero-length array

2020-11-24 Thread Tian Tao

fixed the coccicheck:
drivers/gpu/drm/nouveau/include/nvfw/hs.h:26:5-9: WARNING use
flexible-array member instead.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/nouveau/include/nvfw/hs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvfw/hs.h 
b/drivers/gpu/drm/nouveau/include/nvfw/hs.h
index 64d0d32..b53bbc4 100644
--- a/drivers/gpu/drm/nouveau/include/nvfw/hs.h
+++ b/drivers/gpu/drm/nouveau/include/nvfw/hs.h
@@ -23,7 +23,7 @@ struct nvfw_hs_load_header {
u32 data_dma_base;
u32 data_size;
u32 num_apps;
-   u32 apps[0];
+   u32 apps[];
 };
 
 const struct nvfw_hs_load_header *
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 9/9] misc: xilinx-ai-engine: Add support for servicing error interrupts

2020-11-24 Thread Wendy Liang





On 11/19/20 12:36 AM, Hillf Danton wrote:

On Wed, 18 Nov 2020 15:48:09 -0800 Wendy Liang wrote:

+/**
+ * aie_interrupt() - interrupt handler for AIE.
+ * @irq: Interrupt number.
+ * @data: AI engine device structure.
+ * @return: IRQ_HANDLED.
+ *
+ * This thread function disables level 2 interrupt controllers and schedules a
+ * task in workqueue to backtrack the source of error interrupt. Disabled
+ * interrupts are re-enabled after successful completion of bottom half.
+ */
+irqreturn_t aie_interrupt(int irq, void *data)
+{
+   struct aie_device *adev = data;
+   struct aie_partition *apart;
+   int ret;
+   bool sched_work = false;
+
+   ret = mutex_lock_interruptible(&adev->mlock);
+   if (ret) {
+   dev_err(&adev->dev,
+   "Failed to acquire lock. Process was interrupted by fatal 
signals\n");
+   return IRQ_NONE;
+   }
+
+   list_for_each_entry(apart, &adev->partitions, node) {
+   struct aie_location loc;
+   u32 ttype, l2_mask, l2_status, l2_bitmap_offset  = 0;
+
+   ret = mutex_lock_interruptible(&apart->mlock);
+   if (ret) {
+   dev_err(&apart->dev,
+   "Failed to acquire lock. Process was interrupted by 
fatal signals\n");
+   return IRQ_NONE;


Though quite unlikely, you need to release adev->mlock before
going home.

Thanks to point it out, I will change in next version

Thanks,
Wendy



+   }
+
+   for (loc.col = apart->range.start.col, loc.row = 0;
+loc.col < apart->range.start.col + apart->range.size.col;
+loc.col++) {
+   ttype = apart->adev->ops->get_tile_type(&loc);
+   if (ttype != AIE_TILE_TYPE_SHIMNOC)
+   continue;
+
+   l2_mask = aie_get_l2_mask(apart, &loc);
+   if (l2_mask) {
+   aie_resource_cpy_from_arr32(&apart->l2_mask,
+   l2_bitmap_offset  *
+   32, &l2_mask, 32);
+   aie_disable_l2_ctrl(apart, &loc, l2_mask);
+   }
+   l2_bitmap_offset++;
+
+   l2_status = aie_get_l2_status(apart, &loc);
+   if (l2_status) {
+   aie_clear_l2_intr(apart, &loc, l2_status);
+   sched_work = true;
+   } else {
+   aie_enable_l2_ctrl(apart, &loc, l2_mask);
+   }
+   }
+   mutex_unlock(&apart->mlock);
+   }
+
+   /* For ES1 silicon, interrupts are latched in NPI */
+   if (adev->version == VERSAL_ES1_REV_ID) {
+   ret = zynqmp_pm_clear_aie_npi_isr(adev->pm_node_id,
+ AIE_NPI_ERROR_ID);
+   if (ret < 0)
+   dev_err(&adev->dev, "Failed to clear NPI ISR\n");
+   }
+
+   mutex_unlock(&adev->mlock);
+
+   if (sched_work)
+   schedule_work(&adev->backtrack);
+
+   return IRQ_HANDLED;
+}

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/9] misc: Add Xilinx AI engine device driver

2020-11-24 Thread Wendy Liang

On Fri, Nov 20, 2020 at 06:12:10AM +1000, Dave Airlie wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5cc595a..40e3351 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19283,6 +19283,14 @@ T: git https://github.com/Xilinx/linux-xlnx.git
> >  F: Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml
> >  F: drivers/phy/xilinx/phy-zynqmp.c
> >
> > +XILINX AI ENGINE DRIVER
> > +M: Wendy Liang 
> > +S: Supported
> > +F: Documentation/devicetree/bindings/soc/xilinx/xlnx,ai-engine.yaml
> > +F: drivers/misc/xilinx-ai-engine/
> > +F: include/linux/xlnx-ai-engine.h
> > +F: include/uapi/linux/xlnx-ai-engine.h
> > +
> >  XILLYBUS DRIVER
> >  M: Eli Billauer 
> >  L: linux-ker...@vger.kernel.org
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index fafa8b0..0b8ce4d 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -444,6 +444,18 @@ config XILINX_SDFEC
> >
> >   If unsure, say N.
> >
> > +config XILINX_AIE
> > +   tristate "Xilinx AI engine"
> > +   depends on ARM64 || COMPILE_TEST
> > +   help
> > + This option enables support for the Xilinx AI engine driver.
> > + One Xilinx AI engine device can have multiple partitions (groups 
> > of
> > + AI engine tiles). Xilinx AI engine device driver instance manages
> > + AI engine partitions. User application access its partitions 
> > through
> > + AI engine partition instance file operations.
> > +
> > + If unsure, say N
> > +
> >  config MISC_RTSX
> > tristate
> > default MISC_RTSX_PCI || MISC_RTSX_USB
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index d23231e..2176b18 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI)   += habanalabs/
> >  obj-$(CONFIG_UACCE)+= uacce/
> >  obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
> >  obj-$(CONFIG_HISI_HIKEY_USB)   += hisi_hikey_usb.o
> > +obj-$(CONFIG_XILINX_AIE)   += xilinx-ai-engine/
> > diff --git a/drivers/misc/xilinx-ai-engine/Makefile 
> > b/drivers/misc/xilinx-ai-engine/Makefile
> > new file mode 100644
> > index 000..7827a0a
> > --- /dev/null
> > +++ b/drivers/misc/xilinx-ai-engine/Makefile
> > @@ -0,0 +1,11 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# Makefile for Xilinx AI engine device driver
> > +#
> > +
> > +obj-$(CONFIG_XILINX_AIE)   += xilinx-aie.o
> > +
> > +xilinx-aie-$(CONFIG_XILINX_AIE) := ai-engine-aie.o \
> > +  ai-engine-dev.o \
> > +  ai-engine-part.o \
> > +  ai-engine-res.o
> > diff --git a/drivers/misc/xilinx-ai-engine/ai-engine-aie.c 
> > b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
> > new file mode 100644
> > index 000..319260f
> > --- /dev/null
> > +++ b/drivers/misc/xilinx-ai-engine/ai-engine-aie.c
> > @@ -0,0 +1,115 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx AI Engine driver AIE device specific implementation
> > + *
> > + * Copyright (C) 2020 Xilinx, Inc.
> > + */
> > +
> > +#include 
> > +
> > +#include "ai-engine-internal.h"
> > +
> > +#define AIE_ARRAY_SHIFT30U
> > +#define AIE_COL_SHIFT  23U
> > +#define AIE_ROW_SHIFT  18U
> > +
> > +/*
> > + * Registers offsets
> > + */
> > +#define AIE_SHIMNOC_L2INTR_MASK_REGOFF 0x00015000U
> > +#define AIE_SHIMNOC_L2INTR_INTR_REGOFF 0x00015010U
> > +#define AIE_SHIMNOC_DMA_BD0_ADDRLOW_REGOFF 0x0001d000U
> > +#define AIE_SHIMNOC_DMA_BD15_PACKET_REGOFF 0x0001d13cU
> > +#define AIE_SHIMNOC_AXIMM_REGOFF   0x0001e020U
> > +#define AIE_SHIMPL_L1INTR_MASK_A_REGOFF0x00035000U
> > +#define AIE_SHIMPL_L1INTR_BLOCK_NORTH_B_REGOFF 0x00035050U
> > +#define AIE_SHIMPL_CLKCNTR_REGOFF  0x00036040U
> > +#define AIE_SHIMPL_RESET_REGOFF0x0003604cU
> > +#define AIE_TILE_CORE_CLKCNTR_REGOFF   0x00036040U
> > +
> > +static const struct aie_tile_regs aie_kernel_regs[] = {
> > +   /* SHIM AXI MM Config */
> > +   {.attribute = AIE_TILE_TYPE_SHIMNOC << 
> > AIE_REGS_ATTR_TILE_TYPE_SHIFT,
> > +.soff = AIE_SHIMNOC_AXIMM_REGOFF,
> > +.eoff = AIE_SHIMNOC_AXIMM_REGOFF,
> > +   },
> > +   /* SHIM DMA ADDRESS range */
> > +   {.attribute = AIE_TILE_TYPE_SHIMNOC << 
> > AIE_REGS_ATTR_TILE_TYPE_SHIFT,
> > +.soff = AIE_SHIMNOC_DMA_BD0_ADDRLOW_REGOFF,
> > +.eoff = AIE_SHIMNOC_DMA_BD15_PACKET_REGOFF,
> > +   },
> > +   /* SHIM 2nd level interrupt controller */
> > +   {.attribute = AIE_TILE_TYPE_SHIMNOC << 
> > AIE_REGS_ATTR_TILE_TYPE_SHIFT,
> > +.soff = AIE_SHIMNOC_L2INTR_MASK_REGOFF,
> > +.eoff = AIE_SHIMNOC_L2INTR_INTR_REGOFF,
> > +   },
> > +   /* SHIM 1st level interrupt controller */
> > +   {.attribute = (AIE_TIL

Re: [PATCH rdma-core 2/5] mlx5: Support dma-buf based memory region

On Mon, Nov 23, 2020 at 09:53:01AM -0800, Jianxin Xiong wrote:

> +struct ibv_mr *mlx5_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t 
> length,
> +   uint64_t iova, int fd, int acc)
> +{
> + struct mlx5_mr *mr;
> + int ret;
> + enum ibv_access_flags access = (enum ibv_access_flags)acc;

Why?

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 1/8] iommu/io-pgtable-arm: Add support to use system cache

Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
the outer-cacheability attributes set in the TCR for a
non-coherent page table walker when using system cache.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/io-pgtable-arm.c | 10 --
 include/linux/io-pgtable.h |  4 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..7c9ea9d7874a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, 
void *cookie)
 
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
-   IO_PGTABLE_QUIRK_ARM_TTBR1))
+   IO_PGTABLE_QUIRK_ARM_TTBR1 |
+   IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
return NULL;
 
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,10 +774,15 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg, 
void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+   if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+   goto out_free_data;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
-   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
+   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   else
+   tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
}
 
tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..6b8bb4f4afef 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
 *
 * IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
 *  for use in the upper half of a split address space.
+*
+* IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the outer-cacheability
+*  attributes set in the TCR for a non-coherent page-table walker.
 */
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS   BIT(1)
@@ -93,6 +96,7 @@ struct io_pgtable_cfg {
#define IO_PGTABLE_QUIRK_ARM_MTK_EXTBIT(3)
#define IO_PGTABLE_QUIRK_NON_STRICT BIT(4)
#define IO_PGTABLE_QUIRK_ARM_TTBR1  BIT(5)
+   #define IO_PGTABLE_QUIRK_ARM_OUTER_WBWA BIT(6)
unsigned long   quirks;
unsigned long   pgsize_bitmap;
unsigned intias;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 2/8] iommu/arm-smmu: Add domain attribute for pagetable configuration


On 2020-11-23 20:48, Will Deacon wrote:

On Tue, Nov 17, 2020 at 08:00:41PM +0530, Sai Prakash Ranjan wrote:

Add iommu domain attribute for pagetable configuration which
initially will be used to set quirks like for system cache aka
last level cache to be used by client drivers like GPU to set
right attributes for caching the hardware pagetables into the
system cache and later can be extended to include other page
table configuration data.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 25 +
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 include/linux/io-pgtable.h|  4 
 include/linux/iommu.h |  1 +
 4 files changed, 31 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c

index 0f28a8614da3..7b05782738e2 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,

if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;

+   if (smmu_domain->pgtbl_cfg.quirks)
+   pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1511,6 +1514,12 @@ static int arm_smmu_domain_get_attr(struct 
iommu_domain *domain,

case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == 
ARM_SMMU_DOMAIN_NESTED);
return 0;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
+   *pgtbl_cfg = smmu_domain->pgtbl_cfg;
+
+   return 0;
+   }
default:
return -ENODEV;
}
@@ -1551,6 +1560,22 @@ static int arm_smmu_domain_set_attr(struct 
iommu_domain *domain,

else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct domain_attr_io_pgtbl_cfg *pgtbl_cfg = data;
+
+   if (smmu_domain->smmu) {
+   ret = -EPERM;
+   goto out_unlock;
+   }
+
+   if (!pgtbl_cfg) {


Do we really need to check this? If somebody passed us a NULL pointer 
then
they have a bug and we don't check this for other domain attributes 
afaict.




True, I'll drop it.


+   ret = -ENODEV;
+   goto out_unlock;
+   }
+
+   smmu_domain->pgtbl_cfg = *pgtbl_cfg;
+   break;
+   }
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h

index 04288b6fc619..18fbed376afb 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -364,6 +364,7 @@ enum arm_smmu_domain_stage {
 struct arm_smmu_domain {
struct arm_smmu_device  *smmu;
struct io_pgtable_ops   *pgtbl_ops;
+   struct domain_attr_io_pgtbl_cfg pgtbl_cfg;
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage  stage;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a9a2c59fab37..686b37d48743 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -212,6 +212,10 @@ struct io_pgtable {

 #define io_pgtable_ops_to_pgtable(x) container_of((x), struct 
io_pgtable, ops)


+struct domain_attr_io_pgtbl_cfg {
+   unsigned long quirks;
+};


nit: Can you rename this to 'struct io_pgtable_domain_attr' please?



Done, thanks.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1] drm/bridge: lt9611: Fix handling of 4k panels

2020-11-24 Thread Anibal Limon

I just tested on non 4k display. Looks good to me.

On Mon, 23 Nov 2020 at 04:46, Robert Foss  wrote:

> 4k requires two dsi pipes, so don't report MODE_OK when only a
> single pipe is configured. But rather report MODE_PANEL to
> signal that requirements of the panel are not being met.
>
> Reported-by: Peter Collingbourne 
> Suggested-by: Peter Collingbourne 
> Signed-off-by: Robert Foss 
> Tested-by: John Stultz 
>
Tested-by: Anibal Limon 

> ---
>  drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
> b/drivers/gpu/drm/bridge/lontium-lt9611.c
> index d734d9402c35..e8eb8deb444b 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
> @@ -867,8 +867,14 @@ static enum drm_mode_status
> lt9611_bridge_mode_valid(struct drm_bridge *bridge,
>  const struct
> drm_display_mode *mode)
>  {
> struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
> +   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
>
> -   return lt9611_mode ? MODE_OK : MODE_BAD;
> +   if (!lt9611_mode)
> +   return MODE_BAD;
> +   else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
> +   return MODE_PANEL;
> +   else
> +   return MODE_OK;
>  }
>
>  static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
> --
> 2.27.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/bridge: lt9611: Fix handling of 4k panels

2020-11-24 Thread Robert Foss

4k requires two dsi pipes, so don't report MODE_OK when only a
single pipe is configured. But rather report MODE_PANEL to
signal that requirements of the panel are not being met.

Reported-by: Peter Collingbourne 
Suggested-by: Peter Collingbourne 
Signed-off-by: Robert Foss 
Tested-by: John Stultz 
---
 drivers/gpu/drm/bridge/lontium-lt9611.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c 
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index d734d9402c35..e8eb8deb444b 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -867,8 +867,14 @@ static enum drm_mode_status 
lt9611_bridge_mode_valid(struct drm_bridge *bridge,
 const struct 
drm_display_mode *mode)
 {
struct lt9611_mode *lt9611_mode = lt9611_find_mode(mode);
+   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
 
-   return lt9611_mode ? MODE_OK : MODE_BAD;
+   if (!lt9611_mode)
+   return MODE_BAD;
+   else if (lt9611_mode->intfs > 1 && !lt9611->dsi1)
+   return MODE_PANEL;
+   else
+   return MODE_OK;
 }
 
 static void lt9611_bridge_pre_enable(struct drm_bridge *bridge)
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 03/19] memory: tegra30: Support interconnect framework

2020-11-24 Thread Dmitry Osipenko

23.11.2020 09:32, Georgi Djakov пишет:
> Hi Dmitry,
> 
> On 23.11.20 2:27, Dmitry Osipenko wrote:
>> Now Internal and External memory controllers are memory interconnection
>> providers. This allows us to use interconnect API for tuning of memory
>> configuration. EMC driver now supports OPPs and DVFS. MC driver now
>> supports tuning of memory arbitration latency, which needs to be done
>> for ISO memory clients, like a Display client for example.
>>
>> Tested-by: Peter Geis 
>> Signed-off-by: Dmitry Osipenko 
> 
> Acked-by: Georgi Djakov 
> 
> Thank you for the continuous work on this patchset!

Hello Georgi,

Thank you for reviewing the patches!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] MAINTAINERS tag for cleanup robot

2020-11-24 Thread Lukas Bulwahn

On Mon, Nov 23, 2020 at 4:52 PM Jani Nikula  wrote:
>
> On Sat, 21 Nov 2020, James Bottomley  
> wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> >> A difficult part of automating commits is composing the subsystem
> >> preamble in the commit log.  For the ongoing effort of a fixer
> >> producing
> >> one or two fixes a release the use of 'treewide:' does not seem
> >> appropriate.
> >>
> >> It would be better if the normal prefix was used.  Unfortunately
> >> normal is
> >> not consistent across the tree.
> >>
> >>
> >>  D: Commit subsystem prefix
> >>
> >> ex/ for FPGA DFL DRIVERS
> >>
> >>  D: fpga: dfl:
> >>
> >
> > I've got to bet this is going to cause more issues than it solves.
>
> Agreed.
>

Tom, this a problem only kernel janitors encounter; all other
developers really do not have that issue. The time spent on creating
the patch is much larger than the amount saved if the commit log
header line prefix would be derived automatically. I believe Julia
Lawall, Arnd Bergmann and Nathan Chancellor as long-term
high-frequency janitors do have already scripted approaches to that
issue. Maybe they simply need to share these scripts with you and you
consolidate them and share with everyone?

Also, making clean-up patches cumbersome has a positive side as well;
maintainers are not swamped with fully automated patch submissions.
There have been some bad experiences with some submitters on that in
the past...

> > SCSI uses scsi: : for drivers but not every driver has a
> > MAINTAINERS entry.  We use either scsi: or scsi: core: for mid layer
> > things, but we're not consistent.  Block uses blk-: for all
> > of it's stuff but almost no s have a MAINTAINERS entry.  So
> > the next thing you're going to cause is an explosion of suggested
> > MAINTAINERs entries.
>
> On the one hand, adoption of new MAINTAINERS entries has been really
> slow. Look at B, C, or P, for instance. On the other hand, if this were
> to get adopted, you'll potentially get conflicting prefixes for patches
> touching multiple files. Then what?
>
> I'm guessing a script looking at git log could come up with better
> suggestions for prefixes via popularity contest than manually maintained
> MAINTAINERS entries. It might not always get it right, but then human
> outsiders aren't going to always get it right either.
>
> Now you'll only need Someone(tm) to write the script. ;)
>
> Something quick like this:
>
> git log --since={1year} --pretty=format:%s --  |\
> grep -v "^\(Merge\|Revert\)" |\
> sed 's/:[^:]*$//' |\
> sort | uniq -c | sort -rn | head -5
>
> already gives me results that really aren't worse than some of the
> prefixes invented by drive-by contributors.
>

I agree I do not see the need to introduce something in MAINTAINERS;
from my observations maintaining MAINTAINERS, there is sufficient work
on adoption and maintenance of the existing entries already without
such an yet another additional entry. Some entries are outdated or
wrong and the janitor task of cleaning those up is already enough work
for involved janitors and enough churn for involved maintainers. So a
machine-learned approach as above is probably good enough, but if you
think you need more complex rules try to learn them from the data at
hand... certainly a nice task to do with machine learning on commit
message prefixes.

Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 2/8] iommu/arm-smmu: Add domain attribute for pagetable configuration

Add iommu domain attribute for pagetable configuration which
initially will be used to set quirks like for system cache aka
last level cache to be used by client drivers like GPU to set
right attributes for caching the hardware pagetables into the
system cache and later can be extended to include other page
table configuration data.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 20 
 drivers/iommu/arm/arm-smmu/arm-smmu.h |  1 +
 include/linux/io-pgtable.h|  4 
 include/linux/iommu.h |  1 +
 4 files changed, 26 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 0f28a8614da3..4b9b10fe50ed 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
 
+   if (smmu_domain->pgtbl_cfg.quirks)
+   pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1511,6 +1514,12 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
case DOMAIN_ATTR_NESTING:
*(int *)data = (smmu_domain->stage == 
ARM_SMMU_DOMAIN_NESTED);
return 0;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct io_pgtable_domain_attr *pgtbl_cfg = data;
+   *pgtbl_cfg = smmu_domain->pgtbl_cfg;
+
+   return 0;
+   }
default:
return -ENODEV;
}
@@ -1551,6 +1560,17 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+   case DOMAIN_ATTR_IO_PGTABLE_CFG: {
+   struct io_pgtable_domain_attr *pgtbl_cfg = data;
+
+   if (smmu_domain->smmu) {
+   ret = -EPERM;
+   goto out_unlock;
+   }
+
+   smmu_domain->pgtbl_cfg = *pgtbl_cfg;
+   break;
+   }
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 04288b6fc619..bb5a419f240f 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -364,6 +364,7 @@ enum arm_smmu_domain_stage {
 struct arm_smmu_domain {
struct arm_smmu_device  *smmu;
struct io_pgtable_ops   *pgtbl_ops;
+   struct io_pgtable_domain_attr   pgtbl_cfg;
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage  stage;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 6b8bb4f4afef..fb4d5a763e0c 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -212,6 +212,10 @@ struct io_pgtable {
 
 #define io_pgtable_ops_to_pgtable(x) container_of((x), struct io_pgtable, ops)
 
+struct io_pgtable_domain_attr {
+   unsigned long quirks;
+};
+
 static inline void io_pgtable_tlb_flush_all(struct io_pgtable *iop)
 {
iop->cfg.tlb->tlb_flush_all(iop->cookie);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..ffaa389ea128 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+   DOMAIN_ATTR_IO_PGTABLE_CFG,
DOMAIN_ATTR_MAX,
 };
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Finn Thain

On Mon, 23 Nov 2020, Miguel Ojeda wrote:

> On Mon, 23 Nov 2020, Finn Thain wrote:
> 
> > On Sun, 22 Nov 2020, Miguel Ojeda wrote:
> > 
> > > 
> > > It isn't that much effort, isn't it? Plus we need to take into 
> > > account the future mistakes that it might prevent, too.
> > 
> > We should also take into account optimisim about future improvements 
> > in tooling.
> > 
> Not sure what you mean here. There is no reliable way to guess what the 
> intention was with a missing fallthrough, even if you parsed whitespace 
> and indentation.
> 

What I meant was that you've used pessimism as if it was fact.

For example, "There is no way to guess what the effect would be if the 
compiler trained programmers to add a knee-jerk 'break' statement to avoid 
a warning".

Moreover, what I meant was that preventing programmer mistakes is a 
problem to be solved by development tools. The idea that retro-fitting new 
language constructs onto mature code is somehow necessary to "prevent 
future mistakes" is entirely questionable.

> > > So even if there were zero problems found so far, it is still a 
> > > positive change.
> > > 
> > 
> > It is if you want to spin it that way.
> > 
> How is that a "spin"? It is a fact that we won't get *implicit* 
> fallthrough mistakes anymore (in particular if we make it a hard error).
> 

Perhaps "handwaving" is a better term?

> > > I would agree if these changes were high risk, though; but they are 
> > > almost trivial.
> > > 
> > 
> > This is trivial:
> > 
> >  case 1:
> > this();
> > +   fallthrough;
> >  case 2:
> > that();
> > 
> > But what we inevitably get is changes like this:
> > 
> >  case 3:
> > this();
> > +   break;
> >  case 4:
> > hmmm();
> > 
> > Why? Mainly to silence the compiler. Also because the patch author 
> > argued successfully that they had found a theoretical bug, often in 
> > mature code.
> > 
> If someone changes control flow, that is on them. Every kernel developer 
> knows what `break` does.
> 

Sure. And if you put -Wimplicit-fallthrough into the Makefile and if that 
leads to well-intentioned patches that cause regressions, it is partly on 
you.

Have you ever considered the overall cost of the countless 
-Wpresume-incompetence flags?

Perhaps you pay the power bill for a build farm that produces logs that 
no-one reads? Perhaps you've run git bisect, knowing that the compiler 
messages are not interesting? Or compiled software in using a language 
that generates impenetrable messages? If so, here's a tip:

# grep CFLAGS /etc/portage/make.conf 
CFLAGS="... -Wno-all -Wno-extra ..."
CXXFLAGS="${CFLAGS}"

Now allow me some pessimism: the hardware upgrades, gigawatt hours and 
wait time attributable to obligatory static analyses are a net loss.

> > But is anyone keeping score of the regressions? If unreported bugs 
> > count, what about unreported regressions?
> > 
> Introducing `fallthrough` does not change semantics. If you are really 
> keen, you can always compare the objects because the generated code 
> shouldn't change.
> 

No, it's not for me to prove that such patches don't affect code 
generation. That's for the patch author and (unfortunately) for reviewers.

> Cheers,
> Miguel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 8/8] iommu: arm-smmu-impl: Add a space before open parenthesis

Fix the checkpatch warning for space required before the open
parenthesis.

Signed-off-by: Sai Prakash Ranjan 
Acked-by: Will Deacon 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 26e2734eb4d7..136872e77195 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -12,7 +12,7 @@
 
 static int arm_smmu_gr0_ns(int offset)
 {
-   switch(offset) {
+   switch (offset) {
case ARM_SMMU_GR0_sCR0:
case ARM_SMMU_GR0_sACR:
case ARM_SMMU_GR0_sGFSR:
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 0/8] System Cache support for GPU and required SMMU support

Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the SMMU pagetables.
This helps with improved render performance as well as lower power
consumption by reducing the bus traffic to the system memory.

The system cache architecture allows the cache to be split into slices
which then be used by multiple SOC clients. This patch series is an
effort to enable and use two of those slices preallocated for the GPU,
one for the GPU data buffers and another for the GPU SMMU hardware
pagetables.

Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver.
Patch 7 and 8 are minor cleanups for arm-smmu impl.

Changes in v9:
 * Change name from domain_attr_io_pgtbl_cfg to io_pgtable_domain_attr (Will)
 * Modify comment for the quirk as suggested (Will)
 * Compare with IO_PGTABLE_QUIRK_NON_STRICT for non-strict mode (Will)

Changes in v8:
 * Introduce a generic domain attribute for pagetable config (Will)
 * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will)
 * Move non-strict mode to use new struct domain_attr_io_pgtbl_config (Will)

Changes in v7:
 * Squash Jordan's patch to support MMU500 targets
 * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for 
adreno-smmu impl

Changes in v6:
 * Move table to arm-smmu-qcom (Robin)

Changes in v5:
 * Drop cleanup of blank lines since it was intentional (Robin)
 * Rebase again on top of msm-next-pgtables as it moves pretty fast

Changes in v4:
 * Drop IOMMU_SYS_CACHE prot flag
 * Rebase on top of 
https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables

Changes in v3:
 * Fix domain attribute setting to before iommu_attach_device()
 * Fix few code style and checkpatch warnings
 * Rebase on top of Jordan's latest split pagetables and per-instance
   pagetables support

Changes in v2:
 * Addressed review comments and rebased on top of Jordan's split
   pagetables series

Jordan Crouse (1):
  drm/msm/a6xx: Add support for using system cache on MMU500 based
targets

Sai Prakash Ranjan (5):
  iommu/io-pgtable-arm: Add support to use system cache
  iommu/arm-smmu: Add domain attribute for pagetable configuration
  iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr
  iommu: arm-smmu-impl: Use table to list QCOM implementations
  iommu: arm-smmu-impl: Add a space before open parenthesis

Sharat Masetty (2):
  drm/msm: rearrange the gpu_rmw() function
  drm/msm/a6xx: Add support for using system cache(LLC)

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 109 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   5 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|  17 
 drivers/gpu/drm/msm/msm_drv.c  |   8 ++
 drivers/gpu/drm/msm/msm_drv.h  |   1 +
 drivers/gpu/drm/msm/msm_gpu.h  |   5 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  11 +--
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c |  21 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.c  |  26 -
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |   3 +-
 drivers/iommu/io-pgtable-arm.c |  10 +-
 include/linux/io-pgtable.h |   8 ++
 include/linux/iommu.h  |   1 +
 13 files changed, 199 insertions(+), 26 deletions(-)


base-commit: a29bbb0861f487a5e144dc997a9f71a36c7a2404
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm/vc4: kms: Don't disable the muxing of an active CRTC

On Mon, Nov 23, 2020 at 08:50:49AM +0100, Thomas Zimmermann wrote:
> 
> 
> Am 20.11.20 um 15:42 schrieb Maxime Ripard:
> > The current HVS muxing code will consider the CRTCs in a given state to
> > setup their muxing in the HVS, and disable the other CRTCs muxes.
> > 
> > However, it's valid to only update a single CRTC with a state, and in this
> > situation we would mux out a CRTC that was enabled but left untouched by
> > the new state.
> > 
> > Fix this by setting a flag on the CRTC state when the muxing has been
> > changed, and only change the muxing configuration when that flag is there.
> > 
> > Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel 
> > automatically")
> > Reviewed-by: Hoegeun Kwon 
> > Tested-by: Hoegeun Kwon 
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Thomas Zimmermann 

Applied both, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:

>   IB/hfi1: Fix fall-through warnings for Clang
>   IB/mlx4: Fix fall-through warnings for Clang
>   IB/qedr: Fix fall-through warnings for Clang
>   RDMA/mlx5: Fix fall-through warnings for Clang

I picked these four to the rdma tree, thanks

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support


On 2020-11-24 00:52, Rob Clark wrote:

On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan
 wrote:


On 2020-11-23 20:51, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:
>> Some hardware variants contain a system cache or the last level
>> cache(llc). This cache is typically a large block which is shared
>> by multiple clients on the SOC. GPU uses the system cache to cache
>> both the GPU data buffers(like textures) as well the SMMU pagetables.
>> This helps with improved render performance as well as lower power
>> consumption by reducing the bus traffic to the system memory.
>>
>> The system cache architecture allows the cache to be split into slices
>> which then be used by multiple SOC clients. This patch series is an
>> effort to enable and use two of those slices preallocated for the GPU,
>> one for the GPU data buffers and another for the GPU SMMU hardware
>> pagetables.
>>
>> Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver.
>> Patch 7 and 8 are minor cleanups for arm-smmu impl.
>>
>> Changes in v8:
>>  * Introduce a generic domain attribute for pagetable config (Will)
>>  * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will)
>>  * Move non-strict mode to use new struct domain_attr_io_pgtbl_config
>> (Will)
>
> Modulo some minor comments I've made, this looks good to me. What is
> the
> plan for merging it? I can take the IOMMU parts, but patches 4-6 touch
> the
> MSM GPU driver and I'd like to avoid conflicts with that.
>

SMMU bits are pretty much independent and GPU relies on the domain
attribute
and the quirk exposed, so as long as SMMU changes go in first it 
should

be good.
Rob?


I suppose one option would be to split out the patch that adds the
attribute into it's own patch, and merge that both thru drm and iommu?



Ok I can split out domain attr and quirk into its own patch if Will is
fine with that approach.


If Will/Robin dislike that approach, I'll pick up the parts of the drm
patches which don't depend on the new attribute for v5.11 and the rest
for v5.12.. or possibly a second late v5.11 pull req if airlied
doesn't hate me too much for it.

Going forward, I think we will have one or two more co-dependent
series, like the smmu iova fault handler improvements that Jordan
posted.  So I would like to hear how Will and Robin prefer to handle
those.

BR,
-R



Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support


On 2020-11-23 20:51, Will Deacon wrote:

On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:

Some hardware variants contain a system cache or the last level
cache(llc). This cache is typically a large block which is shared
by multiple clients on the SOC. GPU uses the system cache to cache
both the GPU data buffers(like textures) as well the SMMU pagetables.
This helps with improved render performance as well as lower power
consumption by reducing the bus traffic to the system memory.

The system cache architecture allows the cache to be split into slices
which then be used by multiple SOC clients. This patch series is an
effort to enable and use two of those slices preallocated for the GPU,
one for the GPU data buffers and another for the GPU SMMU hardware
pagetables.

Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver.
Patch 7 and 8 are minor cleanups for arm-smmu impl.

Changes in v8:
 * Introduce a generic domain attribute for pagetable config (Will)
 * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will)
 * Move non-strict mode to use new struct domain_attr_io_pgtbl_config 
(Will)


Modulo some minor comments I've made, this looks good to me. What is 
the
plan for merging it? I can take the IOMMU parts, but patches 4-6 touch 
the

MSM GPU driver and I'd like to avoid conflicts with that.



SMMU bits are pretty much independent and GPU relies on the domain 
attribute
and the quirk exposed, so as long as SMMU changes go in first it should 
be good.

Rob?

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 9/9] misc: xilinx-ai-engine: Add support for servicing error interrupts

2020-11-24 Thread Wendy Liang

On Thu, Nov 19, 2020 at 04:36:45PM +0800, Hillf Danton wrote:
> On Wed, 18 Nov 2020 15:48:09 -0800 Wendy Liang wrote:
> > +/**
> > + * aie_interrupt() - interrupt handler for AIE.
> > + * @irq: Interrupt number.
> > + * @data: AI engine device structure.
> > + * @return: IRQ_HANDLED.
> > + *
> > + * This thread function disables level 2 interrupt controllers and 
> > schedules a
> > + * task in workqueue to backtrack the source of error interrupt. Disabled
> > + * interrupts are re-enabled after successful completion of bottom half.
> > + */
> > +irqreturn_t aie_interrupt(int irq, void *data)
> > +{
> > +   struct aie_device *adev = data;
> > +   struct aie_partition *apart;
> > +   int ret;
> > +   bool sched_work = false;
> > +
> > +   ret = mutex_lock_interruptible(&adev->mlock);
> > +   if (ret) {
> > +   dev_err(&adev->dev,
> > +   "Failed to acquire lock. Process was interrupted by 
> > fatal signals\n");
> > +   return IRQ_NONE;
> > +   }
> > +
> > +   list_for_each_entry(apart, &adev->partitions, node) {
> > +   struct aie_location loc;
> > +   u32 ttype, l2_mask, l2_status, l2_bitmap_offset  = 0;
> > +
> > +   ret = mutex_lock_interruptible(&apart->mlock);
> > +   if (ret) {
> > +   dev_err(&apart->dev,
> > +   "Failed to acquire lock. Process was 
> > interrupted by fatal signals\n");
> > +   return IRQ_NONE;
> 
> Though quite unlikely, you need to release adev->mlock before
> going home.
Thanks for pointing it out. I will change in the next version.

Best Regards,
Wendy
> 
> > +   }
> > +
> > +   for (loc.col = apart->range.start.col, loc.row = 0;
> > +loc.col < apart->range.start.col + apart->range.size.col;
> > +loc.col++) {
> > +   ttype = apart->adev->ops->get_tile_type(&loc);
> > +   if (ttype != AIE_TILE_TYPE_SHIMNOC)
> > +   continue;
> > +
> > +   l2_mask = aie_get_l2_mask(apart, &loc);
> > +   if (l2_mask) {
> > +   aie_resource_cpy_from_arr32(&apart->l2_mask,
> > +   l2_bitmap_offset  *
> > +   32, &l2_mask, 32);
> > +   aie_disable_l2_ctrl(apart, &loc, l2_mask);
> > +   }
> > +   l2_bitmap_offset++;
> > +
> > +   l2_status = aie_get_l2_status(apart, &loc);
> > +   if (l2_status) {
> > +   aie_clear_l2_intr(apart, &loc, l2_status);
> > +   sched_work = true;
> > +   } else {
> > +   aie_enable_l2_ctrl(apart, &loc, l2_mask);
> > +   }
> > +   }
> > +   mutex_unlock(&apart->mlock);
> > +   }
> > +
> > +   /* For ES1 silicon, interrupts are latched in NPI */
> > +   if (adev->version == VERSAL_ES1_REV_ID) {
> > +   ret = zynqmp_pm_clear_aie_npi_isr(adev->pm_node_id,
> > + AIE_NPI_ERROR_ID);
> > +   if (ret < 0)
> > +   dev_err(&adev->dev, "Failed to clear NPI ISR\n");
> > +   }
> > +
> > +   mutex_unlock(&adev->mlock);
> > +
> > +   if (sched_work)
> > +   schedule_work(&adev->backtrack);
> > +
> > +   return IRQ_HANDLED;
> > +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/10] drm/fb-helper: Various fixes and cleanups

On Fri, Nov 20, 2020 at 11:25:35AM +0100, Thomas Zimmermann wrote:
> Here's a number of fb-helper patches that have been piling up recently.
> 
> Patches 1 to 3 fix bugs that I spotted while going through the code.
> Because of the way the fbdev code works, they have been avoided so far.
> 
> Patches 4 to 10 cleanup damage handling for fbdev's shadow buffer and
> fix a few issues.
> 
> Specifically, the final patch adds locking to the code that flushes the
> shadow framebuffer into BO memory. During the conversion of radeon to
> generic fbdev, the question came up about interference with concurrent
> modesets. If fbdev has the BO pinned in system memory for flushing while
> the modeset wants to pin it to VRAM for scanout, the modeset would
> most likely fail. We haven't seen that so far, but it's possible at
> least. Acquiring the fb-helper lock during the flush operation prevents
> concurrent modesets from taking place.
> 
> The code has been tested with SHMEM and TTM BOs; with atomic and non-
> atomic modesetting.

For the whole series
Acked-by: Maxime Ripard 

Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 3/8] iommu/arm-smmu: Move non-strict mode to use domain_attr_io_pgtbl_cfg


On 2020-11-23 20:49, Will Deacon wrote:

On Tue, Nov 17, 2020 at 08:00:42PM +0530, Sai Prakash Ranjan wrote:

Now that we have a struct domain_attr_io_pgtbl_cfg with quirks,
use that for non_strict mode as well thereby removing the need
for more members of arm_smmu_domain in the future.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 7 ++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c

index 7b05782738e2..5f066a1b7221 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,

goto out_clear_smmu;
}

-   if (smmu_domain->non_strict)
-   pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-
if (smmu_domain->pgtbl_cfg.quirks)
pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;

@@ -1527,7 +1524,7 @@ static int arm_smmu_domain_get_attr(struct 
iommu_domain *domain,

case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   *(int *)data = smmu_domain->non_strict;
+   *(int *)data = smmu_domain->pgtbl_cfg.quirks;


Probably better to compare with IO_PGTABLE_QUIRK_NON_STRICT here even 
though

we only support this one quirk for DMA domains atm.



Ok will do, thanks.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 7/8] iommu: arm-smmu-impl: Use table to list QCOM implementations

Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.

Signed-off-by: Sai Prakash Ranjan 
Acked-by: Will Deacon 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  9 +
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
 drivers/iommu/arm/arm-smmu/arm-smmu.h  |  1 -
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 7fed89c9d18a..26e2734eb4d7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -214,14 +214,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct 
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
return nvidia_smmu_impl_init(smmu);
 
-   if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
-   of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
-   return qcom_smmu_impl_init(smmu);
-
-   if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
-   return qcom_adreno_smmu_impl_init(smmu);
+   smmu = qcom_smmu_impl_init(smmu);
 
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = &mrvl_mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d0636c803a36..add1859b2899 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -318,12 +318,23 @@ static struct arm_smmu_device *qcom_smmu_create(struct 
arm_smmu_device *smmu,
return &qsmmu->smmu;
 }
 
+static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
+   { .compatible = "qcom,sc7180-smmu-500" },
+   { .compatible = "qcom,sdm845-smmu-500" },
+   { .compatible = "qcom,sm8150-smmu-500" },
+   { .compatible = "qcom,sm8250-smmu-500" },
+   { }
+};
+
 struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
 {
-   return qcom_smmu_create(smmu, &qcom_smmu_impl);
-}
+   const struct device_node *np = smmu->dev->of_node;
 
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device 
*smmu)
-{
-   return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+   if (of_match_node(qcom_smmu_impl_of_match, np))
+   return qcom_smmu_create(smmu, &qcom_smmu_impl);
+
+   if (of_device_is_compatible(np, "qcom,adreno-smmu"))
+   return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+
+   return smmu;
 }
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index cb7ca3a444c9..d2a2d1bc58ba 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -523,7 +523,6 @@ static inline void arm_smmu_writeq(struct arm_smmu_device 
*smmu, int page,
 struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
 struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
 struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device 
*smmu);
 
 void arm_smmu_write_context_bank(struct arm_smmu_device *smmu, int idx);
 int arm_mmu500_reset(struct arm_smmu_device *smmu);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 00/19] Introduce memory interconnect for NVIDIA Tegra SoCs

2020-11-24 Thread Dmitry Osipenko

23.11.2020 09:17, Viresh Kumar пишет:
> On 23-11-20, 03:27, Dmitry Osipenko wrote:
>> This series brings initial support for memory interconnect to Tegra20,
>> Tegra30 and Tegra124 SoCs.
>>
>> For the starter only display controllers and devfreq devices are getting
>> interconnect API support, others could be supported later on. The display
>> controllers have the biggest demand for interconnect API right now because
>> dynamic memory frequency scaling can't be done safely without taking into
>> account bandwidth requirement from the displays. In particular this series
>> fixes distorted display output on T30 Ouya and T124 TK1 devices.
>>
>> Changelog:
>>
>> v10 - In a longer run it will be much nicer if we could support EMC
>>   hardware versioning on Tegra20 and it's not late to support it now.
>>   Hence I added these new patches:
>>
>> dt-bindings: memory: tegra20: emc: Document opp-supported-hw property
>> memory: tegra20: Support hardware versioning and clean up OPP table 
>> initialization
>>
>> - Removed error message from tegra30-devfreq driver about missing OPP
>>   properties in a device-tree because EMC driver already prints that
>>   message and it uses OPP API error code instead of checking DT directly,
>>   which is a more correct way of doing that.
> 
> Looks good to me (from OPP APIs usage perspective). Thanks for
> continuing with this and fixing all the issues Dmitry.
> 

Hello Viresh,

Thank you for all the clarifications and for reviewing of the patches!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Miguel Ojeda

On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
 wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches.  Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about 5-10 minutes per patch to review, merge and for
> others to rework existing series.  So let's say it's cost a person year
> of a relatively junior engineer producing the patches and say 100h of
> review and application time.  The latter is likely the big ticket item
> because it's what we have in least supply in the kernel (even though
> it's 20x vs the producer time).

How are you arriving at such numbers? It is a total of ~200 trivial lines.

> It's not about the risk of the changes it's about the cost of
> implementing them.  Even if you discount the producer time (which
> someone gets to pay for, and if I were the engineering manager, I'd be
> unhappy about), the review/merge/rework time is pretty significant in
> exchange for six minor bug fixes.  Fine, when a new compiler warning
> comes along it's certainly reasonable to see if we can benefit from it
> and the fact that the compiler people think it's worthwhile is enough
> evidence to assume this initially.  But at some point you have to ask
> whether that assumption is supported by the evidence we've accumulated
> over the time we've been using it.  And if the evidence doesn't support
> it perhaps it is time to stop the experiment.

Maintainers routinely review 1-line trivial patches, not to mention
internal API changes, etc.

If some company does not want to pay for that, that's fine, but they
don't get to be maintainers and claim `Supported`.

Cheers,
Miguel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 5/8] drm/msm/a6xx: Add support for using system cache(LLC)

From: Sharat Masetty 

The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices upon
GPU power collapse and restore.

Some support from the IOMMU driver is also needed to make use
of the system cache to set the right TCR attributes. GPU then
has the ability to override a few cacheability parameters which
it does to override write-allocate to write-no-allocate as the
GPU hardware does not benefit much from it.

DOMAIN_ATTR_IO_PGTABLE_CFG is another domain level attribute used
by the IOMMU driver for pagetable configuration which will be used
to set a quirk initially to set the right attributes to cache the
hardware pagetables into the system cache.

Signed-off-by: Sharat Masetty 
[saiprakash.ranjan: fix to set attr before device attach to iommu and rebase]
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 83 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h   |  4 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +
 3 files changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 948f3656c20c..95c98c642876 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -8,7 +8,9 @@
 #include "a6xx_gpu.h"
 #include "a6xx_gmu.xml.h"
 
+#include 
 #include 
+#include 
 
 #define GPU_PAS_ID 13
 
@@ -1022,6 +1024,79 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
 }
 
+static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
+{
+   return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
+{
+   return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+}
+
+static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
+{
+   llcc_slice_deactivate(a6xx_gpu->llc_slice);
+   llcc_slice_deactivate(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
+{
+   u32 cntl1_regval = 0;
+
+   if (IS_ERR(a6xx_gpu->llc_mmio))
+   return;
+
+   if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
+   u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+
+   gpu_scid &= 0x1f;
+   cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid << 
10) |
+  (gpu_scid << 15) | (gpu_scid << 20);
+   }
+
+   if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
+   u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+
+   gpuhtw_scid &= 0x1f;
+   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+   }
+
+   if (cntl1_regval) {
+   /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+   a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
+
+   /*
+* Program cacheability overrides to not allocate cache lines on
+* a write miss
+*/
+   a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 
0xF, 0x03);
+   }
+}
+
+static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
+{
+   llcc_slice_putd(a6xx_gpu->llc_slice);
+   llcc_slice_putd(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_slices_init(struct platform_device *pdev,
+   struct a6xx_gpu *a6xx_gpu)
+{
+   a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
+   if (IS_ERR(a6xx_gpu->llc_mmio))
+   return;
+
+   a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
+   a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
+
+   if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+   a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
+}
+
 static int a6xx_pm_resume(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1038,6 +1113,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
 
msm_gpu_resume_devfreq(gpu);
 
+   a6xx_llc_activate(a6xx_gpu);
+
return 0;
 }
 
@@ -1048,6 +1125,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
 
trace_msm_gpu_suspend(0);
 
+   a6xx_llc_deactivate(a6xx_gpu);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
 
return a6xx_gmu_stop(a6xx_gpu);
@@ -1091,6 +1170,8 @@ static void a6xx_destroy(struct msm_gpu *gpu)
drm_gem_object_put(a6xx_gpu->shadow_bo);
}
 
+   a6xx_llc_slices_destroy(a6xx_gpu);
+
a6xx_gmu_remove(a6xx_gpu);
 
adreno_gpu_cleanup(adreno_

Re: [PATCH] Properly check tee_shm buffer mmap offset

2020-11-24 Thread Jens Wiklander

Hi,

On Mon, Nov 23, 2020 at 8:10 AM gaoyusong  wrote:
>
> The memmap options in tee_shm_op_mmap were not being checked for all
> sets of possible crazy values. Fix this up by properly check tee_shm
> buffer offsets.
>
> Signed-off-by: gaoyusong 
> ---
>  drivers/tee/tee_shm.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 827ac3d..3f762c8 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -75,6 +75,16 @@ static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct 
> vm_area_struct *vma)
>  {
> struct tee_shm *shm = dmabuf->priv;
> size_t size = vma->vm_end - vma->vm_start;
> +   unsigned long offset;
> +
> +   /* Check dmabuffer mmap offset */
> +   if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
> +   return -EINVAL;
> +
> +   offset = vma->vm_pgoff << PAGE_SHIFT;
> +
> +   if (offset > shm->size || size > shm->size - offset)
> +   return -EINVAL;

If we would have used vm_pgoff below to offset into the shm buffer
these checks would be needed.
Currently we're ignoring this field though. That might be a bit
inconsistent with the mmap() API, but on the other hand this buffer
has just been carved out of the shared memory pool for the purpose of
mapping it in user space. To carve out more than we're going to map
would be wasteful so I guess that in the end it makes sense to ignore
vm_pgoff.

Thanks,
Jens

>
> /* Refuse sharing shared memory provided by application */
> if (shm->flags & TEE_SHM_USER_MAPPED)
> --
> 1.8.3.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 6/8] drm/msm/a6xx: Add support for using system cache on MMU500 based targets

From: Jordan Crouse 

GPU targets with an MMU-500 attached have a slightly different process for
enabling system cache. Use the compatible string on the IOMMU phandle
to see if an MMU-500 is attached and modify the programming sequence
accordingly.

Signed-off-by: Jordan Crouse 
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 +--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  1 +
 2 files changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 95c98c642876..3f8b92da8cba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1042,6 +1042,8 @@ static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
 
 static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
 {
+   struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+   struct msm_gpu *gpu = &adreno_gpu->base;
u32 cntl1_regval = 0;
 
if (IS_ERR(a6xx_gpu->llc_mmio))
@@ -1055,11 +1057,17 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
   (gpu_scid << 15) | (gpu_scid << 20);
}
 
+   /*
+* For targets with a MMU500, activate the slice but don't program the
+* register.  The XBL will take care of that.
+*/
if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
-   u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+   if (!a6xx_gpu->have_mmu500) {
+   u32 gpuhtw_scid = 
llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
 
-   gpuhtw_scid &= 0x1f;
-   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+   gpuhtw_scid &= 0x1f;
+   cntl1_regval |= FIELD_PREP(GENMASK(29, 25), 
gpuhtw_scid);
+   }
}
 
if (cntl1_regval) {
@@ -1067,13 +1075,20 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
 * Program the slice IDs for the various GPU blocks and GPU MMU
 * pagetables
 */
-   a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
-
-   /*
-* Program cacheability overrides to not allocate cache lines on
-* a write miss
-*/
-   a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 
0xF, 0x03);
+   if (a6xx_gpu->have_mmu500)
+   gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
+   cntl1_regval);
+   else {
+   a6xx_llc_write(a6xx_gpu,
+   REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, 
cntl1_regval);
+
+   /*
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
+*/
+   a6xx_llc_rmw(a6xx_gpu,
+   REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF, 
0x03);
+   }
}
 }
 
@@ -1086,10 +1101,21 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu 
*a6xx_gpu)
 static void a6xx_llc_slices_init(struct platform_device *pdev,
struct a6xx_gpu *a6xx_gpu)
 {
+   struct device_node *phandle;
+
a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
 
+   /*
+* There is a different programming path for targets with an mmu500
+* attached, so detect if that is the case
+*/
+   phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+   a6xx_gpu->have_mmu500 = (phandle &&
+   of_device_is_compatible(phandle, "arm,mmu-500"));
+   of_node_put(phandle);
+
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 9e6079af679c..e793d329e77b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -32,6 +32,7 @@ struct a6xx_gpu {
void __iomem *llc_mmio;
void *llc_slice;
void *htw_llc_slice;
+   bool have_mmu500;
 };
 
 #define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH rdma-core 1/5] verbs: Support dma-buf based memory region

On Mon, Nov 23, 2020 at 09:53:00AM -0800, Jianxin Xiong wrote:
> Add new API function and new provider method for registering dma-buf
> based memory region. Update the man page and bump the API version.
> 
> Signed-off-by: Jianxin Xiong 
>  kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 
>  libibverbs/cmd_mr.c  | 38 
> 
>  libibverbs/driver.h  |  7 ++
>  libibverbs/dummy_ops.c   | 11 +
>  libibverbs/libibverbs.map.in |  6 +
>  libibverbs/man/ibv_reg_mr.3  | 21 --
>  libibverbs/verbs.c   | 19 
>  libibverbs/verbs.h   | 10 +
>  8 files changed, 124 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h 
> b/kernel-headers/rdma/ib_user_ioctl_cmds.h
> index 7968a18..dafc7eb 100644
> +++ b/kernel-headers/rdma/ib_user_ioctl_cmds.h
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (c) 2018, Mellanox Technologies inc.  All rights reserved.
> + * Copyright (c) 2020, Intel Corporation. All rights reserved.
>   *
>   * This software is available to you under a choice of one of two
>   * licenses.  You may choose to be licensed under the terms of the GNU
> @@ -251,6 +252,7 @@ enum uverbs_methods_mr {
>   UVERBS_METHOD_MR_DESTROY,
>   UVERBS_METHOD_ADVISE_MR,
>   UVERBS_METHOD_QUERY_MR,
> + UVERBS_METHOD_REG_DMABUF_MR,
>  };
>  
>  enum uverbs_attrs_mr_destroy_ids {
> @@ -272,6 +274,18 @@ enum uverbs_attrs_query_mr_cmd_attr_ids {
>   UVERBS_ATTR_QUERY_MR_RESP_IOVA,
>  };
>  
> +enum uverbs_attrs_reg_dmabuf_mr_cmd_attr_ids {
> + UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
> + UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
> + UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
> + UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
> + UVERBS_ATTR_REG_DMABUF_MR_IOVA,
> + UVERBS_ATTR_REG_DMABUF_MR_FD,
> + UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
> + UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
> + UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
> +};
> +
>  enum uverbs_attrs_create_counters_cmd_attr_ids {
>   UVERBS_ATTR_CREATE_COUNTERS_HANDLE,
>  };

Please put changes to kernel-headers/ into their own patch

There is a script to make that commit in kernel-headers/update

> diff --git a/libibverbs/cmd_mr.c b/libibverbs/cmd_mr.c
> index 42dbe42..91ce2ef 100644
> +++ b/libibverbs/cmd_mr.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (c) 2018 Mellanox Technologies, Ltd.  All rights reserved.
> + * Copyright (c) 2020 Intel Corporation.  All rights reserved.
>   *
>   * This software is available to you under a choice of one of two
>   * licenses.  You may choose to be licensed under the terms of the GNU
> @@ -116,3 +117,40 @@ int ibv_cmd_query_mr(struct ibv_pd *pd, struct verbs_mr 
> *vmr,
>   return 0;
>  }
>  
> +int ibv_cmd_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t offset, size_t length,
> +   uint64_t iova, int fd, int access,
> +   struct verbs_mr *vmr)
> +{
> + DECLARE_COMMAND_BUFFER(cmdb, UVERBS_OBJECT_MR,
> +UVERBS_METHOD_REG_DMABUF_MR,
> +9);
> + struct ib_uverbs_attr *handle;
> + uint32_t lkey, rkey;
> + int ret;
> +
> + handle = fill_attr_out_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
> + fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY, &lkey);
> + fill_attr_out_ptr(cmdb, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY, &rkey);
> +
> + fill_attr_in_obj(cmdb, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE, pd->handle);
> + fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_OFFSET, offset);
> + fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_LENGTH, length);
> + fill_attr_in_uint64(cmdb, UVERBS_ATTR_REG_DMABUF_MR_IOVA, iova);
> + fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_FD, fd);
> + fill_attr_in_uint32(cmdb, UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS, 
> access);
> +
> + ret = execute_ioctl(pd->context, cmdb);
> + if (ret)
> + return errno;
> +
> + vmr->ibv_mr.handle =
> + read_attr_obj(UVERBS_ATTR_REG_DMABUF_MR_HANDLE, handle);
> + vmr->ibv_mr.context = pd->context;
> + vmr->ibv_mr.lkey= lkey;
> + vmr->ibv_mr.rkey= rkey;
> + vmr->ibv_mr.pd  = pd;
> + vmr->ibv_mr.addr= (void *)offset;
> + vmr->ibv_mr.length  = length;
> + vmr->mr_type= IBV_MR_TYPE_MR;

Remove the extra spaces around the = please

> diff --git a/libibverbs/libibverbs.map.in b/libibverbs/libibverbs.map.in
> index b5ccaca..f67e1ef 100644
> +++ b/libibverbs/libibverbs.map.in
> @@ -148,6 +148,11 @@ IBVERBS_1.11 {
>   _ibv_query_gid_table;
>  } IBVERBS_1.10;
>  
> +IBVERBS_1.12 {
> + global:
> + ibv_reg_dmabuf_mr;
> +} IBVERBS_1.11;

There are a few things missing for this, the github CI should throw
some errors, please check it and fix everything

After this you need to

Re: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support

On Mon, Nov 23, 2020 at 09:53:02AM -0800, Jianxin Xiong wrote:

> +cdef class DmaBuf:
> +def __init__(self, size, unit=0):
> +"""
> +Allocate DmaBuf object from a GPU device. This is done through the
> +DRI device interface (/dev/dri/card*). Usually this requires the
> +effective user id being root or being a member of the 'video' group.
> +:param size: The size (in number of bytes) of the buffer.
> +:param unit: The unit number of the GPU to allocate the buffer from.
> +:return: The newly created DmaBuf object on success.
> +"""
> +self.dmabuf_mrs = weakref.WeakSet()
> +self.dri_fd = open('/dev/dri/card'+str(unit), O_RDWR)
> +
> +args = bytearray(32)
> +pack_into('=iiq', args, 0, 1, size, 8, 0, 0, 0, 0)
> +ioctl(self.dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, args)
> +a, b, c, d, self.handle, e, self.size = unpack('=iiq', args)
> +
> +args = bytearray(12)
> +pack_into('=iii', args, 0, self.handle, O_RDWR, 0)
> +ioctl(self.dri_fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, args)
> +a, b, self.fd = unpack('=iii', args)
> +
> +args = bytearray(16)
> +pack_into('=iiq', args, 0, self.handle, 0, 0)
> +ioctl(self.dri_fd, DRM_IOCTL_MODE_MAP_DUMB, args);
> +a, b, self.map_offset = unpack('=iiq', args);

Wow, OK

Is it worth using ctypes here instead? Can you at least add a comment
before each pack specifying the 'struct XXX' this is following?

Does this work with normal Intel GPUs, like in a Laptop? AMD too?

Christian, I would be very happy to hear from you that this entire
work is good for AMD as well

Edward should look through this, but I'm glad to see something like
this

Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

2020-11-24 Thread Miguel Ojeda

On Sun, Nov 22, 2020 at 11:54 PM Finn Thain  wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.

Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and indentation.

> It is if you want to spin it that way.

How is that a "spin"? It is a fact that we won't get *implicit*
fallthrough mistakes anymore (in particular if we make it a hard
error).

> But what we inevitably get is changes like this:
>
>  case 3:
> this();
> +   break;
>  case 4:
> hmmm();
>
> Why? Mainly to silence the compiler. Also because the patch author argued
> successfully that they had found a theoretical bug, often in mature code.

If someone changes control flow, that is on them. Every kernel
developer knows what `break` does.

> But is anyone keeping score of the regressions? If unreported bugs count,
> what about unreported regressions?

Introducing `fallthrough` does not change semantics. If you are really
keen, you can always compare the objects because the generated code
shouldn't change.

Cheers,
Miguel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 3/8] iommu/arm-smmu: Move non-strict mode to use io_pgtable_domain_attr

Now that we have a struct io_pgtable_domain_attr with quirks,
use that for non_strict mode as well thereby removing the need
for more members of arm_smmu_domain in the future.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/arm/arm-smmu/arm-smmu.c | 8 +++-
 drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 4b9b10fe50ed..f56f266ebdf7 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -786,9 +786,6 @@ static int arm_smmu_init_domain_context(struct iommu_domain 
*domain,
goto out_clear_smmu;
}
 
-   if (smmu_domain->non_strict)
-   pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
-
if (smmu_domain->pgtbl_cfg.quirks)
pgtbl_cfg.quirks |= smmu_domain->pgtbl_cfg.quirks;
 
@@ -1527,7 +1524,8 @@ static int arm_smmu_domain_get_attr(struct iommu_domain 
*domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   *(int *)data = smmu_domain->non_strict;
+   if (smmu_domain->pgtbl_cfg.quirks & 
IO_PGTABLE_QUIRK_NON_STRICT)
+   *(int *)data = smmu_domain->pgtbl_cfg.quirks;
return 0;
default:
return -ENODEV;
@@ -1578,7 +1576,7 @@ static int arm_smmu_domain_set_attr(struct iommu_domain 
*domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
-   smmu_domain->non_strict = *(int *)data;
+   smmu_domain->pgtbl_cfg.quirks |= 
IO_PGTABLE_QUIRK_NON_STRICT;
break;
default:
ret = -ENODEV;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h 
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index bb5a419f240f..cb7ca3a444c9 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -368,7 +368,6 @@ struct arm_smmu_domain {
const struct iommu_flush_ops*flush_ops;
struct arm_smmu_cfg cfg;
enum arm_smmu_domain_stage  stage;
-   boolnon_strict;
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t  cb_lock; /* Serialises ATS1* ops and 
TLB syncs */
struct iommu_domain domain;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv9 4/8] drm/msm: rearrange the gpu_rmw() function

From: Sharat Masetty 

The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.

Signed-off-by: Sharat Masetty 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sai Prakash Ranjan 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 
 drivers/gpu/drm/msm/msm_drv.h | 1 +
 drivers/gpu/drm/msm/msm_gpu.h | 5 +
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..a1e22b974b77 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -180,6 +180,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
 }
 
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+   u32 val = msm_readl(addr);
+
+   val &= ~mask;
+   msm_writel(val | or, addr);
+}
+
 struct msm_vblank_work {
struct work_struct work;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..655b3b0424a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -478,6 +478,7 @@ void __iomem *msm_ioremap_quiet(struct platform_device 
*pdev, const char *name,
const char *dbgname);
 void msm_writel(u32 data, void __iomem *addr);
 u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
 
 struct msm_gpu_submitqueue;
 int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fdc1a76..b2b419277953 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -246,10 +246,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
 
 static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
 {
-   uint32_t val = gpu_read(gpu, reg);
-
-   val &= ~mask;
-   gpu_write(gpu, reg, val | or);
+   msm_rmw(gpu->mmio + (reg << 2), mask, or);
 }
 
 static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 1/8] iommu/io-pgtable-arm: Add support to use system cache


On 2020-11-23 20:36, Will Deacon wrote:

On Tue, Nov 17, 2020 at 08:00:40PM +0530, Sai Prakash Ranjan wrote:

Add a quirk IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to override
the attributes set in TCR for the page table walker when
using system cache.

Signed-off-by: Sai Prakash Ranjan 
---
 drivers/iommu/io-pgtable-arm.c | 10 --
 include/linux/io-pgtable.h |  4 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c 
b/drivers/iommu/io-pgtable-arm.c

index a7a9bc08dcd1..7c9ea9d7874a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg 
*cfg, void *cookie)


if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
-   IO_PGTABLE_QUIRK_ARM_TTBR1))
+   IO_PGTABLE_QUIRK_ARM_TTBR1 |
+   IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
return NULL;

data = arm_lpae_alloc_pgtable(cfg);
@@ -773,10 +774,15 @@ arm_64_lpae_alloc_pgtable_s1(struct 
io_pgtable_cfg *cfg, void *cookie)

tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+   if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA)
+   goto out_free_data;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
-   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   if (!(cfg->quirks & IO_PGTABLE_QUIRK_ARM_OUTER_WBWA))
+   tcr->orgn = ARM_LPAE_TCR_RGN_NC;
+   else
+   tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
}

tg1 = cfg->quirks & IO_PGTABLE_QUIRK_ARM_TTBR1;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..a9a2c59fab37 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
 *
 * IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
 *  for use in the upper half of a split address space.
+*
+	 * IO_PGTABLE_QUIRK_ARM_OUTER_WBWA: Override the attributes set in 
TCR for

+*  the page table walker when using system cache.


Please can you reword this to say:

  "Override the outer-cacheability attributes set in the TCR for a 
non-coherent

   page-table walker."



Sure, thanks.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/2] Default to cachable mappings for GEM SHMEM

On Tue, Nov 17, 2020 at 02:31:54PM +0100, Thomas Zimmermann wrote:
> By default, SHMEM GEM helpers map pages using writecombine. Only a few
> drivers require this setting. Others revert it to default mappings
> flags. Some could benefit from caching, but don't care.
> 
> Unify the behaviour by switching the SHMEM GEM code to use cached
> mappings (i.e., PAGE_KERNEL actually); just like regular shmem memory
> does. The 3 drivers that require write combining explicitly select it
> during GEM object creation.
> 
> The exception is dma-buf imported pages, which are always mapped
> using writecombine mode.


For the whole series:
Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v10 09/19] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree

2020-11-24 Thread Dmitry Osipenko

23.11.2020 10:02, Chanwoo Choi пишет:
> Hi Dmitry,
> 
> On 11/23/20 9:27 AM, Dmitry Osipenko wrote:
>> This patch moves ACTMON driver away from generating OPP table by itself,
>> transitioning it to use the table which comes from device-tree. This
>> change breaks compatibility with older device-trees and brings support
>> for the interconnect framework to the driver. This is a mandatory change
>> which needs to be done in order to implement interconnect-based memory
>> DVFS, i.e. device-trees need to be updated. Now ACTMON issues a memory
>> bandwidth requests using dev_pm_opp_set_bw() instead of driving EMC clock
>> rate directly.
>>
>> Tested-by: Peter Geis 
>> Tested-by: Nicolas Chauvet 
>> Acked-by: Chanwoo Choi 
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/devfreq/tegra30-devfreq.c | 79 +++
>>  1 file changed, 37 insertions(+), 42 deletions(-)
>>
> 
> (snip)

Hello Chanwoo,

> When the patches related to icc are merged, I'll merge patch9/10.
> Thanks for your work.
> 

Alright, thank you!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/6] drm/panel: mantix and st7703 fixes and additions

2020-11-24 Thread Guido Günther

Hi,
On Mon, Nov 23, 2020 at 10:48:26PM +0100, Sam Ravnborg wrote:
> Hi Guido,
> 
> On Wed, Nov 18, 2020 at 09:29:47AM +0100, Guido Günther wrote:
> > This adds new panel type to the mantix driver as found on the Librem 5 and
> > fixes a glitch in the init sequence (affecting both panels). The fix is at 
> > the
> > start of the series to make backporting simpler.
> > It also adds a patch to make st7703 use dev_err_probe().
> > 
> > changes from v1
> > - as per review comments by Linus Walleij
> >   - fix alphabetical ordering in 
> > Documentation/devicetree/bindings/vendor-prefixes.yaml
> > 
> > https://lore.kernel.org/dri-devel/CACRpkdao_TMcpRsdK=7k5fnkjse0bqwk58iwu0xsxddndcf...@mail.gmail.com/
> >   - add reviewed by to all except 5/6, thanks
> > 
> > Guido Günther (6):
> >   drm/panel: st7703: Use dev_err_probe
> >   drm/panel: mantix: Tweak init sequence
> >   drm/panel: mantix: Allow to specify default mode for different panels
> >   drm/panel: mantix: Support panel from Shenzhen Yashi Changhua
> > Intelligent Technology Co
> >   dt-bindings: vendor-prefixes: Add ys vendor prefix
> The above are all:
> Reviewed-by: Sam Ravnborg 
> 
> >   dt-binding: display: mantix: Add compatible for panel from YS
> Please fix the subjects to read "dt-bindings" - just to be consistent.
> With that:
> Reviewed-by: Sam Ravnborg 

Fixed locally, thanks!
 -- Guido

> 
> 
>   Sam
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence

2020-11-24 Thread Hans de Goede

Hi,

On 11/18/20 1:40 PM, Hans de Goede wrote:
> Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
> added an intel_dsi_msleep() helper which skips sleeping if the
> MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
> and it moved a bunch of msleep-s over to this new helper.
> 
> This was based on my reading of the big comment around line 730 which
> starts with "Panel enable/disable sequences from the VBT spec.",
> where the "v3 video mode seq" column does not have any wait t# entries.
> 
> Given that this code has been used on a lot of different devices without
> issues until now, it seems that my interpretation of the spec here is
> mostly correct.
> 
> But now I have encountered one device, an Acer Aspire Switch 10 E
> SW3-016, where the panel will not light up unless we do actually honor the
> panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
> 
> What seems to set this model apart is that it is lacking a
> MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
> delay usually happens.
> 
> Fix the panel not lighting up on this model by using an unconditional
> msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
> no MIPI_SEQ_DEASSERT_RESET sequence.
> 
> Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
> Signed-off-by: Hans de Goede 

Ping can I get a review/ack for this please?

Regards,

Hans


> ---
>  drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c 
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index 194c239ab6b1..ef673277b36d 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -816,10 +816,14 @@ static void intel_dsi_pre_enable(struct 
> intel_atomic_state *state,
>   intel_dsi_prepare(encoder, pipe_config);
>  
>   intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>  
> - /* Deassert reset */
> - intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> + if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
> + intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> + /* Deassert reset */
> + intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> + } else {
> + msleep(intel_dsi->panel_on_delay);
> + }
>  
>   if (IS_GEMINILAKE(dev_priv)) {
>   glk_cold_boot = glk_dsi_enable_io(encoder);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm: panel: add Khadas TS050 panel driver

2020-11-24 Thread Neil Armstrong

Hi Sam,

On 23/11/2020 22:05, Sam Ravnborg wrote:
> Hi Neil.
> 
> Looks good but a few comments in the following that needs some attention.
> 
>   Sam
> 
> On Mon, Nov 23, 2020 at 03:33:54PM +0100, Neil Armstrong wrote:
>> This add support for the Khadas TS050 1080x1920 5" LCD DSI panel designed to 
>> work
>> with the Khadas Edge-V, Captain, VIM3 and VIM3L Single Board Computers.
>> It provides a MIPI DSI interface to the host, a built-in LED backlight
>> and touch controller.
>>
>> The init values was taken from the vendor source tree, comments were added 
>> to the
>> know values but most of the init table is undocumented.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/panel/Kconfig  |  11 +
>>  drivers/gpu/drm/panel/Makefile |   1 +
>>  drivers/gpu/drm/panel/panel-khadas-ts050.c | 876 +
>>  3 files changed, 888 insertions(+)
>>  create mode 100644 drivers/gpu/drm/panel/panel-khadas-ts050.c
>>
>> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
>> index b4e021ea30f9..8fec45b2ce02 100644
>> --- a/drivers/gpu/drm/panel/Kconfig
>> +++ b/drivers/gpu/drm/panel/Kconfig
>> @@ -145,6 +145,17 @@ config DRM_PANEL_JDI_LT070ME05000
>>The panel has a 1200(RGB)×1920 (WUXGA) resolution and uses
>>24 bit per pixel.
>>  
>> +config DRM_PANEL_KHADAS_TS050
>> +tristate "Khadas TS050 panel"
>> +depends on OF
>> +depends on DRM_MIPI_DSI
>> +depends on BACKLIGHT_CLASS_DEVICE
>> +help
>> +  Say Y here if you want to enable support for Khadas TS050 TFT-LCD
>> +  panel module. The panel has a 1080x1920 resolution and uses
>> +  24 bit RGB per pixel. It provides a MIPI DSI interface to
>> +  the host, a built-in LED backlight and touch controller.
>> +
>>  config DRM_PANEL_KINGDISPLAY_KD097D04
>>  tristate "Kingdisplay kd097d04 panel"
>>  depends on OF
>> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
>> index ebbf488c7eac..03496695e03f 100644
>> --- a/drivers/gpu/drm/panel/Makefile
>> +++ b/drivers/gpu/drm/panel/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += 
>> panel-ilitek-ili9322.o
>>  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
>>  obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
>>  obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
>> +obj-$(CONFIG_DRM_PANEL_KHADAS_TS050) += panel-khadas-ts050.o
>>  obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
>>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK050H3146W) += panel-leadtek-ltk050h3146w.o
>>  obj-$(CONFIG_DRM_PANEL_LEADTEK_LTK500HD1829) += panel-leadtek-ltk500hd1829.o
>> diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c 
>> b/drivers/gpu/drm/panel/panel-khadas-ts050.c
>> new file mode 100644
>> index ..856fcad69306
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
>> @@ -0,0 +1,876 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 BayLibre, SAS
>> + * Author: Neil Armstrong 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> Panels do not use DRM_ or drm_ for logging, so this include is not
> needed.

Ok forgot to remove this

> 
>> +
>> +struct khadas_ts050_panel {
>> +struct drm_panel base;
>> +struct mipi_dsi_device *link;
>> +
>> +struct regulator *supply;
>> +struct gpio_desc *reset_gpio;
>> +struct gpio_desc *enable_gpio;
>> +
>> +bool prepared;
>> +bool enabled;
>> +};
>> +
>> +struct khadas_ts050_panel_cmd {
>> +u8 cmd;
>> +u8 data;
>> +};
>> +
>> +/* Only the CMD1 User Command set is documented */
>> +static const struct khadas_ts050_panel_cmd init_code[] = {
>> +/* Select Unknown CMD Page (Undocumented) */
>> +{0xff, 0xee},
> ...
>> +{0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
>> +};
>> +
>> +static inline
>> +struct khadas_ts050_panel *to_khadas_ts050_panel(struct drm_panel *panel)
>> +{
>> +return container_of(panel, struct khadas_ts050_panel, base);
>> +}
>> +
>> +static int khadas_ts050_panel_prepare(struct drm_panel *panel)
>> +{
>> +struct khadas_ts050_panel *khadas_ts050 = to_khadas_ts050_panel(panel);
>> +int err, regulator_err;
>> +unsigned int i;
>> +
>> +if (khadas_ts050->prepared)
>> +return 0;
>> +
>> +gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 0);
>> +
>> +err = regulator_enable(khadas_ts050->supply);
>> +if (err < 0)
>> +return err;
>> +
>> +gpiod_set_value_cansleep(khadas_ts050->enable_gpio, 1);
>> +
>> +msleep(60);
>> +
>> +gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 1);
>> +
>> +usleep_range(1, 11000);
>> +
>> +gpiod_set_value_cansleep(khadas_ts050->reset_gpio, 0);
>> +
>> +/* Select CMD2 page 4 (Undocumented) */

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Hi Christian

Am 16.11.20 um 12:28 schrieb Christian König:

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:

In order to avoid eviction of vmap'ed buffers, pin them in their GEM
object's vmap implementation. Unpin them in the vunmap implementation.
This is needed to make generic fbdev support work reliably. Without,
the buffer object could be evicted while fbdev flushed its shadow 
buffer.


In difference to the PRIME pin/unpin functions, the vmap code does not
modify the BOs prime_shared_count, so a vmap-pinned BO does not 
count as

shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.


Ok in this case that should work.


If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into the
BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.


The problem is what happens when it is prepared for scanout, but can't 
be moved to VRAM because it is vmapped?


When the shadow is never scanned out that isn't a problem, but we need 
to keep that in mind.




I'd like ask for your suggestions before sending an update for this patch.

After the discussion about locking in fbdev, [1] I intended to replace 
the pin call with code that acquires the reservation lock.


First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but then 
wondered why ttm_bo_vmap() doe not acquire the lock internally? I'd 
expect that vmap/vunmap are close together and do not overlap for the 
same BO. Otherwise, acquiring the reservation lock would require another 
ref-counting variable or per-driver code.


Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/401088/?series=83918&rev=1


Regards,
Christian.



For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432&data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3D&reserved=0 




Regards,
Christian.


Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/radeon/radeon_gem.c | 51 
+++--

   1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d2876ce3bc9e..eaf7fc9a7b07 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
radeon_device *rdev, int r)
   return r;
   }
   +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
+   RADEON_GEM_DOMAIN_GTT |
+   RADEON_GEM_DOMAIN_CPU;
+
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return ret;
+
+    /* pin buffer at its current location */
+    ret = radeon_bo_pin(bo, any_domain, NULL);
+    if (ret)
+    goto err_radeon_bo_unreserve;
+
+    ret = drm_gem_ttm_vmap(obj, map);
+    if (ret)
+    goto err_radeon_bo_unpin;
+
+    radeon_bo_unreserve(bo);
+
+    return 0;
+
+err_radeon_bo_unpin:
+    radeon_bo_unpin(bo);
+err_radeon_bo_unreserve:
+    radeon_bo_unreserve(bo);
+    return ret;
+}
+
+static void radeon_gem_object_vunmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return;
+
+    drm_gem_ttm_vunmap(obj, map);
+    radeon_bo_unpin(bo);
+    radeon_bo_unreserve(bo);
+}
+
   static const struct drm_gem_object_funcs radeon_gem_object_funcs = {
   .free = radeon_gem_object_free,
   .open = radeon_gem_object_open,
@@ -234,8 +281,8 @@ static const struct drm_gem_object_funcs
radeon_gem_object_funcs = {
   .pin = radeon_gem_prime_pin,
   .unpin = radeon_gem_prime_unpin,
   .get_sg_table = radeon_gem_prime_get_sg

Re: [PATCH v2 05/10] drm/fb-helper: Return early in dirty worker


Hi

Am 23.11.20 um 20:23 schrieb Sam Ravnborg:

On Fri, Nov 20, 2020 at 11:25:40AM +0100, Thomas Zimmermann wrote:

Returning early in the dirty worker if no update is required makes the
code more readable. No functional changes are made.

Signed-off-by: Thomas Zimmermann 


It is a damage worker (both subject and changelog).


I changed this before pushing the branches. Thanks!

Best regards
Thomas



Reviewed-by: Sam Ravnborg 


---
  drivers/gpu/drm/drm_fb_helper.c | 31 +++
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 87d4759de04a..c90185f9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -407,24 +407,23 @@ static void drm_fb_helper_damage_work(struct work_struct 
*work)
clip->x2 = clip->y2 = 0;
spin_unlock_irqrestore(&helper->damage_lock, flags);
  
-	/* call dirty callback only when it has been really touched */

-   if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
-
-   /* Generic fbdev uses a shadow buffer */
-   if (helper->buffer) {
-   ret = drm_client_buffer_vmap(helper->buffer, &map);
-   if (ret)
-   return;
-   drm_fb_helper_damage_blit_real(helper, &clip_copy, 
&map);
-   }
-
-   if (helper->fb->funcs->dirty)
-   helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
-&clip_copy, 1);
+   /* Call damage handlers only if necessary */
+   if (!(clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2))
+   return;
  
-		if (helper->buffer)

-   drm_client_buffer_vunmap(helper->buffer);
+   /* Generic fbdev uses a shadow buffer */
+   if (helper->buffer) {
+   ret = drm_client_buffer_vmap(helper->buffer, &map);
+   if (ret)
+   return;
+   drm_fb_helper_damage_blit_real(helper, &clip_copy, &map);
}
+
+   if (helper->fb->funcs->dirty)
+   helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+
+   if (helper->buffer)
+   drm_client_buffer_vunmap(helper->buffer);
  }
  
  /**

--
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [drm/fb] 6a1b34c0a3: WARNING:at_drivers/gpu/drm/drm_fb_helper.c:#drm_fb_helper_damage_work


Hi

Am 24.11.20 um 02:58 schrieb Xing Zhengjun:



On 11/23/2020 4:04 PM, Thomas Zimmermann wrote:

Hi

Am 22.11.20 um 15:18 schrieb kernel test robot:


Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: 6a1b34c0a339fdc75d7932ad5702f2177c9d7a1c ("drm/fb-helper: 
Move damage blit code and its setup into separate routine")
url: 
https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-fb-helper-Various-fixes-and-cleanups/20201120-182750 




in testcase: trinity
version: trinity-static-i386-x86_64-f93256fb_2019-08-28
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 
-m 8G


caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


That dmesg is full of messages like

[  696.323556] alloc_vmap_area: 24 callbacks suppressed
[  696.323562] vmap allocation for size 3149824 failed: use 
vmalloc= to increase size


I think the test system needs to be reconfigured first.



We have tried "vmalloc=256M" and "vmalloc=512M", the same warning still 
happened.


I added a more descriptive error message before pushing the patch. This 
may help to find the problem's cause.


Best regards
Thomas





Best regards
Thomas




+---+++ 

|   
| 154f2d1afd | 6a1b34c0a3 |
+---+++ 

| 
WARNING:at_drivers/gpu/drm/drm_fb_helper.c:#drm_fb_helper_damage_work 
| 0  | 36 |

| EIP:drm_fb_helper_damage_work | 0  | 36 |
+---+++ 




If you fix the issue, kindly add following tag
Reported-by: kernel test robot 


[  106.616652] WARNING: CPU: 1 PID: 173 at 
drivers/gpu/drm/drm_fb_helper.c:434 
drm_fb_helper_damage_work+0x371/0x390

[  106.627732] Modules linked in:
[  106.632419] CPU: 1 PID: 173 Comm: kworker/1:2 Not tainted 
5.10.0-rc4-next-20201120-7-g6a1b34c0a339 #3
[  106.637806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS 1.12.0-1 04/01/2014

[  106.642853] Workqueue: events drm_fb_helper_damage_work
[  106.647664] EIP: drm_fb_helper_damage_work+0x371/0x390
[  106.652305] Code: b1 17 c7 01 68 bd 5b 2d c5 53 50 68 55 21 2d c5 
83 15 44 b1 17 c7 00 e8 ae bc b1 01 83 05 48 b1 17 c7 01 83 15 4c b1 
17 c7 00 <0f> 0b 83 05 50 b1 17 c7 01 83 15 54 b1 17 c7 00 83 c4 10 
e9 78 fd

[  106.663517] EAX: 002d EBX: c8730520 ECX: 0847 EDX: 
[  106.668423] ESI: ca987000 EDI: cab274d8 EBP: f62f5f20 ESP: f62f5ee8
[  106.673214] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 
00010246

[  106.678295] CR0: 80050033 CR2:  CR3: 063a7000 CR4: 000406d0
[  106.683160] DR0:  DR1:  DR2:  DR3: 
[  106.687967] DR6: fffe0ff0 DR7: 0400
[  106.690763] Call Trace:
[  106.693394]  process_one_work+0x3ea/0xaa0
[  106.693501] ixgbevf: Intel(R) 10 Gigabit PCI Express Virtual 
Function Network Driver

[  106.695300]  worker_thread+0x330/0x900
[  106.697406] ixgbevf: Copyright (c) 2009 - 2018 Intel Corporation.
[  106.702963]  kthread+0x190/0x210
[  106.705709]  ? rescuer_thread+0x650/0x650
[  106.708379]  ? kthread_insert_work_sanity_check+0x120/0x120
[  106.711271]  ret_from_fork+0x1c/0x30
[  106.713973] ---[ end trace dd528799d3369ac1 ]---


To reproduce:

 # build kernel
cd linux
cp config-5.10.0-rc4-next-20201120-7-g6a1b34c0a339 .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare 
modules_prepare bzImage


 git clone https://github.com/intel/lkp-tests.git
 cd lkp-tests
 bin/lkp qemu -k  job-script # job-script is 
attached in this email




Thanks,
Oliver Sang




___
LKP mailing list -- l...@lists.01.org
To unsubscribe send an email to lkp-le...@lists.01.org





--
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys


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] video: hyperv_fb: Directly use the MMIO VRAM

2020-11-24 Thread Wei Liu

On Tue, Nov 24, 2020 at 08:33:32AM +, Dexuan Cui wrote:
> Hi Wei Liu,
> Please do not pick up this patch, because actually MMIO VRAM can not work
> with fb_deferred_io.
> 

No problem. Thanks for the heads-up.

Wei.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v5 00/17] HDCP 2.2 and HDCP 1.4 Gen12 DP MST support

2020-11-24 Thread Karthik B S


On 11/11/2020 11:50 AM, Anshuman Gupta wrote:

This is v5 version to test with IGT 
https://patchwork.freedesktop.org/series/82987/
This has addressed the review comments from Ram.
It has been also tested manually with above IGT series.


As we currently do not have a setup for HDCP over DP MST on CI,

I've tested this series on local set up with the above IGT series.

Tested-by: Karthik B S 



[PATCH v5 11/17] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
has an Ack from Tomas to merge it via drm-intel.

[PATCH v5 12/17] drm/hdcp: Max MST content streams
has an Ack from drm-misc maintainer to merge it via drm-intel.

Test-with: 20201103082628.9287-2-karthik@intel.com

Anshuman Gupta (17):
   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: 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: Enable HDCP 1.4 stream encryption
   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: Enable HDCP 2.2 MST support

  drivers/gpu/drm/i915/display/intel_ddi.c  |  14 +-
  drivers/gpu/drm/i915/display/intel_ddi.h  |   6 +-
  .../drm/i915/display/intel_display_types.h|  20 +-
  drivers/gpu/drm/i915/display/intel_dp.c   |  14 +-
  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 182 +--
  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  12 +-
  drivers/gpu/drm/i915/display/intel_hdcp.c | 294 ++
  drivers/gpu/drm/i915/display/intel_hdcp.h |   8 +-
  drivers/gpu/drm/i915/display/intel_hdmi.c |  19 +-
  drivers/gpu/drm/i915/i915_reg.h   |  31 ++
  drivers/misc/mei/hdcp/mei_hdcp.c  |   3 +-
  include/drm/drm_hdcp.h|   8 +-
  12 files changed, 489 insertions(+), 122 deletions(-)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support

2020-11-24 Thread Will Deacon

On Tue, Nov 24, 2020 at 09:32:54AM +0530, Sai Prakash Ranjan wrote:
> On 2020-11-24 00:52, Rob Clark wrote:
> > On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan
> >  wrote:
> > > 
> > > On 2020-11-23 20:51, Will Deacon wrote:
> > > > On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote:
> > > >> Some hardware variants contain a system cache or the last level
> > > >> cache(llc). This cache is typically a large block which is shared
> > > >> by multiple clients on the SOC. GPU uses the system cache to cache
> > > >> both the GPU data buffers(like textures) as well the SMMU pagetables.
> > > >> This helps with improved render performance as well as lower power
> > > >> consumption by reducing the bus traffic to the system memory.
> > > >>
> > > >> The system cache architecture allows the cache to be split into slices
> > > >> which then be used by multiple SOC clients. This patch series is an
> > > >> effort to enable and use two of those slices preallocated for the GPU,
> > > >> one for the GPU data buffers and another for the GPU SMMU hardware
> > > >> pagetables.
> > > >>
> > > >> Patch 1 - Patch 6 adds system cache support in SMMU and GPU driver.
> > > >> Patch 7 and 8 are minor cleanups for arm-smmu impl.
> > > >>
> > > >> Changes in v8:
> > > >>  * Introduce a generic domain attribute for pagetable config (Will)
> > > >>  * Rename quirk to more generic IO_PGTABLE_QUIRK_ARM_OUTER_WBWA (Will)
> > > >>  * Move non-strict mode to use new struct domain_attr_io_pgtbl_config
> > > >> (Will)
> > > >
> > > > Modulo some minor comments I've made, this looks good to me. What is
> > > > the
> > > > plan for merging it? I can take the IOMMU parts, but patches 4-6 touch
> > > > the
> > > > MSM GPU driver and I'd like to avoid conflicts with that.
> > > >
> > > 
> > > SMMU bits are pretty much independent and GPU relies on the domain
> > > attribute
> > > and the quirk exposed, so as long as SMMU changes go in first it
> > > should
> > > be good.
> > > Rob?
> > 
> > I suppose one option would be to split out the patch that adds the
> > attribute into it's own patch, and merge that both thru drm and iommu?
> > 
> 
> Ok I can split out domain attr and quirk into its own patch if Will is
> fine with that approach.

Why don't I just queue the first two patches on their own branch and we
both pull that?

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND v3 2/2] drm/bridge: display-connector: add DP support

2020-11-24 Thread Tomi Valkeinen

Add DP support to display-connector driver. The driver will support HPD
via a GPIO and DP PWR.

DP PWR will be enabled at probe, which is not optimal, but I'm not sure
what would be a good place to enable and disable DP PWR. Perhaps
attach/detach, but I don't know if enabling HW is something that attach
is supposed to do.

In any case, I don't think there's much difference in power consumption
between the version in this patch and enabling the regulator later: if
the driver probes, supposedly it will attach very soon afterwards, and
we need to enable the DP PWR as soon as possible.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/bridge/display-connector.c | 46 +-
 1 file changed, 44 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/display-connector.c 
b/drivers/gpu/drm/bridge/display-connector.c
index 4d278573cdb9..04362feccd75 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,6 +21,8 @@ struct display_connector {
 
struct gpio_desc*hpd_gpio;
int hpd_irq;
+
+   struct regulator*dp_pwr;
 };
 
 static inline struct display_connector *
@@ -172,11 +175,12 @@ static int display_connector_probe(struct platform_device 
*pdev)
of_property_read_string(pdev->dev.of_node, "label", &label);
 
/*
-* Get the HPD GPIO for DVI and HDMI connectors. If the GPIO can provide
+* Get the HPD GPIO for DVI, HDMI and DP connectors. If the GPIO can 
provide
 * edge interrupts, register an interrupt handler.
 */
if (type == DRM_MODE_CONNECTOR_DVII ||
-   type == DRM_MODE_CONNECTOR_HDMIA) {
+   type == DRM_MODE_CONNECTOR_HDMIA ||
+   type == DRM_MODE_CONNECTOR_DisplayPort) {
conn->hpd_gpio = devm_gpiod_get_optional(&pdev->dev, "hpd",
 GPIOD_IN);
if (IS_ERR(conn->hpd_gpio)) {
@@ -223,6 +227,38 @@ static int display_connector_probe(struct platform_device 
*pdev)
}
}
 
+   /* Get the DP PWR for DP connector */
+   if (type == DRM_MODE_CONNECTOR_DisplayPort) {
+   int r;
+
+   conn->dp_pwr = devm_regulator_get_optional(&pdev->dev, 
"dp-pwr");
+
+   if (IS_ERR(conn->dp_pwr)) {
+   r = PTR_ERR(conn->dp_pwr);
+
+   switch (r) {
+   case -ENODEV:
+   conn->dp_pwr = NULL;
+   break;
+
+   case -EPROBE_DEFER:
+   return -EPROBE_DEFER;
+
+   default:
+   dev_err(&pdev->dev, "failed to get DP PWR 
regulator: %d\n", r);
+   return r;
+   }
+   }
+
+   if (conn->dp_pwr) {
+   r = regulator_enable(conn->dp_pwr);
+   if (r) {
+   dev_err(&pdev->dev, "failed to enable DP PWR 
regulator: %d\n", r);
+   return r;
+   }
+   }
+   }
+
conn->bridge.funcs = &display_connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
 
@@ -251,6 +287,9 @@ static int display_connector_remove(struct platform_device 
*pdev)
 {
struct display_connector *conn = platform_get_drvdata(pdev);
 
+   if (conn->dp_pwr)
+   regulator_disable(conn->dp_pwr);
+
drm_bridge_remove(&conn->bridge);
 
if (!IS_ERR(conn->bridge.ddc))
@@ -275,6 +314,9 @@ static const struct of_device_id display_connector_match[] 
= {
}, {
.compatible = "vga-connector",
.data = (void *)DRM_MODE_CONNECTOR_VGA,
+   }, {
+   .compatible = "dp-connector",
+   .data = (void *)DRM_MODE_CONNECTOR_DisplayPort,
},
{},
 };
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND v3 1/2] dt-bindings: dp-connector: add binding for DisplayPort connector

2020-11-24 Thread Tomi Valkeinen

Add binding for DisplayPort connector. A few notes:

* Similar to hdmi-connector, it has hpd-gpios as an optional property,
  as the HPD could also be handled by, e.g., the DP bridge.

* dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
  is not strictly required: standard DP cables do not even have the pin
  connected.

* Connector type. Full size and mini connectors are identical except for
  the connector size and form, so I believe there is no functional need
  for this property. But similar to 'label' property, it might be used
  to present information about the connector to the userspace.

* No eDP. There's really no "eDP connector", as it's always a custom
  made connection between the DP and the DP panel, although the eDP spec
  does offer a few suggested pin setups. So possibly there is no need for
  edp-connector binding, but even if there is, I don't want to guess what
  it could look like, and could it be part of the dp-connector binding.

* No DP++. I'm not familiar with DP++. DP++ might need an i2c bus added
  to the bindings.

Signed-off-by: Tomi Valkeinen 
Cc: Rob Herring 
---
 .../display/connector/dp-connector.yaml   | 55 +++
 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/connector/dp-connector.yaml

diff --git 
a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml 
b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
new file mode 100644
index ..b5fc3e52899e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DisplayPort Connector
+
+maintainers:
+  - Tomi Valkeinen 
+
+properties:
+  compatible:
+const: dp-connector
+
+  label: true
+
+  type:
+enum:
+  - full-size
+  - mini
+
+  hpd-gpios:
+description: A GPIO line connected to HPD
+maxItems: 1
+
+  dp-pwr-supply:
+description: Power supply for the DP_PWR pin
+maxItems: 1
+
+  port:
+description: Connection to controller providing DP signals
+
+required:
+  - compatible
+  - type
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+connector {
+compatible = "dp-connector";
+label = "dp0";
+type = "full-size";
+
+port {
+dp_connector_in: endpoint {
+remote-endpoint = <&dp_out>;
+};
+};
+};
+
+...
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RESEND v3 0/2] drm: add DisplayPort connector

2020-11-24 Thread Tomi Valkeinen

Hi,

This series adds the DT bindings and a driver for DisplayPort connector.

This is a resend of
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg326794.html
with no changes (rebased on top of latest drm-misc).

 Tomi

Tomi Valkeinen (2):
  dt-bindings: dp-connector: add binding for DisplayPort connector
  drm/bridge: display-connector: add DP support

 .../display/connector/dp-connector.yaml   | 55 +++
 drivers/gpu/drm/bridge/display-connector.c| 46 +++-
 2 files changed, 99 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/connector/dp-connector.yaml

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Am 24.11.20 um 10:16 schrieb Thomas Zimmermann:

Hi Christian

Am 16.11.20 um 12:28 schrieb Christian König:

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:

In order to avoid eviction of vmap'ed buffers, pin them in their GEM
object's vmap implementation. Unpin them in the vunmap 
implementation.

This is needed to make generic fbdev support work reliably. Without,
the buffer object could be evicted while fbdev flushed its shadow 
buffer.


In difference to the PRIME pin/unpin functions, the vmap code does 
not
modify the BOs prime_shared_count, so a vmap-pinned BO does not 
count as

shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.


Ok in this case that should work.


If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into the
BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.


The problem is what happens when it is prepared for scanout, but 
can't be moved to VRAM because it is vmapped?


When the shadow is never scanned out that isn't a problem, but we 
need to keep that in mind.




I'd like ask for your suggestions before sending an update for this 
patch.


After the discussion about locking in fbdev, [1] I intended to replace 
the pin call with code that acquires the reservation lock.


Yeah, that sounds like a good idea to me as well.

First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but then 
wondered why ttm_bo_vmap() doe not acquire the lock internally? I'd 
expect that vmap/vunmap are close together and do not overlap for the 
same BO. 


We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with 
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the 
lock/unlock into it and I hope to replace the kmap/kunmap functions with 
them in the near term.


Otherwise, acquiring the reservation lock would require another 
ref-counting variable or per-driver code.


Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper as 
you initially planned.


Regards,
Christian.



Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/401088/?series=83918&rev=1


Regards,
Christian.



For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432&data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3D&reserved=0 




Regards,
Christian.


Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/radeon/radeon_gem.c | 51 
+++--

   1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d2876ce3bc9e..eaf7fc9a7b07 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
radeon_device *rdev, int r)
   return r;
   }
   +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
+   RADEON_GEM_DOMAIN_GTT |
+   RADEON_GEM_DOMAIN_CPU;
+
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return ret;
+
+    /* pin buffer at its current location */
+    ret = radeon_bo_pin(bo, any_domain, NULL);
+    if (ret)
+    goto err_radeon_bo_unreserve;
+
+    ret = drm_gem_ttm_vmap(obj, map);
+    if (ret)
+    goto err_radeon_bo_unpin;
+
+    radeon_bo_unreserve(bo);
+
+    return 0;
+
+err_radeon_bo_unpin:
+    radeon_bo_unpin(bo);
+err_radeon_bo_unreserve:
+    radeon_bo_unreserve(bo);
+    return ret;
+}
+
+static void radeon_ge

[PATCH 02/15] drm/ast: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert ast to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.c  |  4 ++--
 drivers/gpu/drm/ast/ast_main.c | 25 +
 drivers/gpu/drm/ast/ast_mm.c   | 17 +
 drivers/gpu/drm/ast/ast_mode.c |  5 +++--
 drivers/gpu/drm/ast/ast_post.c |  8 +---
 5 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 667b450606ef..ea8164e7a6dc 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -147,7 +147,7 @@ static int ast_drm_freeze(struct drm_device *dev)
error = drm_mode_config_helper_suspend(dev);
if (error)
return error;
-   pci_save_state(dev->pdev);
+   pci_save_state(to_pci_dev(dev->dev));
return 0;
 }
 
@@ -162,7 +162,7 @@ static int ast_drm_resume(struct drm_device *dev)
 {
int ret;
 
-   if (pci_enable_device(dev->pdev))
+   if (pci_enable_device(to_pci_dev(dev->dev)))
return -EIO;
 
ret = ast_drm_thaw(dev);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 1b13199858cb..0ac3c2039c4b 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -67,8 +67,9 @@ uint8_t ast_get_index_reg_mask(struct ast_private *ast,
 
 static void ast_detect_config_mode(struct drm_device *dev, u32 *scu_rev)
 {
-   struct device_node *np = dev->pdev->dev.of_node;
+   struct device_node *np = dev->dev->of_node;
struct ast_private *ast = to_ast_private(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
uint32_t data, jregd0, jregd1;
 
/* Defaults */
@@ -85,7 +86,7 @@ static void ast_detect_config_mode(struct drm_device *dev, 
u32 *scu_rev)
}
 
/* Not all families have a P2A bridge */
-   if (dev->pdev->device != PCI_CHIP_AST2000)
+   if (pdev->device != PCI_CHIP_AST2000)
return;
 
/*
@@ -119,6 +120,7 @@ static void ast_detect_config_mode(struct drm_device *dev, 
u32 *scu_rev)
 static int ast_detect_chip(struct drm_device *dev, bool *need_post)
 {
struct ast_private *ast = to_ast_private(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
uint32_t jreg, scu_rev;
 
/*
@@ -143,19 +145,19 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
ast_detect_config_mode(dev, &scu_rev);
 
/* Identify chipset */
-   if (dev->pdev->revision >= 0x50) {
+   if (pdev->revision >= 0x50) {
ast->chip = AST2600;
drm_info(dev, "AST 2600 detected\n");
-   } else if (dev->pdev->revision >= 0x40) {
+   } else if (pdev->revision >= 0x40) {
ast->chip = AST2500;
drm_info(dev, "AST 2500 detected\n");
-   } else if (dev->pdev->revision >= 0x30) {
+   } else if (pdev->revision >= 0x30) {
ast->chip = AST2400;
drm_info(dev, "AST 2400 detected\n");
-   } else if (dev->pdev->revision >= 0x20) {
+   } else if (pdev->revision >= 0x20) {
ast->chip = AST2300;
drm_info(dev, "AST 2300 detected\n");
-   } else if (dev->pdev->revision >= 0x10) {
+   } else if (pdev->revision >= 0x10) {
switch (scu_rev & 0x0300) {
case 0x0200:
ast->chip = AST1100;
@@ -265,7 +267,7 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
 
 static int ast_get_dram_info(struct drm_device *dev)
 {
-   struct device_node *np = dev->pdev->dev.of_node;
+   struct device_node *np = dev->dev->of_node;
struct ast_private *ast = to_ast_private(dev);
uint32_t mcr_cfg, mcr_scu_mpll, mcr_scu_strap;
uint32_t denum, num, div, ref_pll, dsel;
@@ -409,10 +411,9 @@ struct ast_private *ast_device_create(const struct 
drm_driver *drv,
return ast;
dev = &ast->base;
 
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
-   ast->regs = pci_iomap(dev->pdev, 1, 0);
+   ast->regs = pci_iomap(pdev, 1, 0);
if (!ast->regs)
return ERR_PTR(-EIO);
 
@@ -421,14 +422,14 @@ struct ast_private *ast_device_create(const struct 
drm_driver *drv,
 * assume the chip has MMIO enabled by default (rev 0x20
 * and higher).
 */
-   if (!(pci_resource_flags(dev->pdev, 2) & IORESOURCE_IO)) {
+   if (!(pci_resource_flags(pdev, 2) & IORESOURCE_IO)) {
drm_info(dev, "platform has no IO space, trying MMIO\n");
ast->ioregs = ast->regs + AST_IO_MM_OFFSET;
}
 
/* "map" IO regs if the above hasn't done so already */
if (!ast->ioregs) {
-   ast->ioregs = pci_iomap(dev->pdev, 2, 0);
+   ast->ioregs = pci_iomap(pdev, 2, 0);
if (!ast->ioregs)

[PATCH 03/15] drm/bochs: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert bochs to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 1 -
 drivers/gpu/drm/bochs/bochs_hw.c  | 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index fd454225fd19..b469624fe40d 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -121,7 +121,6 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_free_dev;
 
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
ret = bochs_load(dev);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index dce4672e3fc8..2d7380a9890e 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -110,7 +110,7 @@ int bochs_hw_load_edid(struct bochs_device *bochs)
 int bochs_hw_init(struct drm_device *dev)
 {
struct bochs_device *bochs = dev->dev_private;
-   struct pci_dev *pdev = dev->pdev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
unsigned long addr, size, mem, ioaddr, iosize;
u16 id;
 
@@ -201,7 +201,7 @@ void bochs_hw_fini(struct drm_device *dev)
release_region(VBE_DISPI_IOPORT_INDEX, 2);
if (bochs->fb_map)
iounmap(bochs->fb_map);
-   pci_release_regions(dev->pdev);
+   pci_release_regions(to_pci_dev(dev->dev));
kfree(bochs->edid);
 }
 
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] drm: Move struct drm_device.pdev to legacy

The pdev field in struct drm_device points to a PCI device structure and
goes back to UMS-only days when all DRM drivers where 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 duplications 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.

The patchset touches many files, but the individual changes are mostly
trivial. I suggest to merge each driver's patch through the respective
tree and later the rest through drm-misc-next.

Thomas Zimmermann (15):
  drm/amdgpu: Remove references to struct drm_device.pdev
  drm/ast: Remove references to struct drm_device.pdev
  drm/bochs: Remove references to struct drm_device.pdev
  drm/cirrus: Remove references to struct drm_device.pdev
  drm/gma500: Remove references to struct drm_device.pdev
  drm/hibmc: Remove references to struct drm_device.pdev
  drm/i915: Remove references to struct drm_device.pdev
  drm/mgag200: Remove references to struct drm_device.pdev
  drm/nouveau: Remove references to struct drm_device.pdev
  drm/qxl: Remove references to struct drm_device.pdev
  drm/radeon: Remove references to struct drm_device.pdev
  drm/vboxvideo: Remove references to struct drm_device.pdev
  drm/virtgpu: Remove references to struct drm_device.pdev
  drm/vmwgfx: Remove references to struct drm_device.pdev
  drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 23 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 10 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 10 +--
 drivers/gpu/drm/ast/ast_drv.c |  4 +-
 drivers/gpu/drm/ast/ast_main.c| 25 +++---
 drivers/gpu/drm/ast/ast_mm.c  | 17 ++--
 drivers/gpu/drm/ast/ast_mode.c|  5 +-
 drivers/gpu/drm/ast/ast_post.c|  8 +-
 drivers/gpu/drm/bochs/bochs_drv.c |  1 -
 drivers/gpu/drm/bochs/bochs_hw.c  |  4 +-
 drivers/gpu/drm/drm_agpsupport.c  |  9 +-
 drivers/gpu/drm/drm_bufs.c|  4 +-
 drivers/gpu/drm/drm_edid.c|  7 +-
 drivers/gpu/drm/drm_irq.c | 12 +--
 drivers/gpu/drm/drm_pci.c | 26 +++---
 drivers/gpu/drm/drm_vm.c  |  2 +-
 drivers/gpu/drm/gma500/cdv_device.c   | 30 ---
 drivers/gpu/drm/gma500/cdv_intel_crt.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c   |  4 +-
 drivers/gpu/drm/gma500/framebuffer.c  |  9 +-
 drivers/gpu/drm/gma500/gma_device.c   |  3 +-
 drivers/gpu/drm/gma500/gma_display.c  |  4 +-
 drivers/gpu/drm/gma500/gtt.c  | 20 +++--
 drivers/gpu/drm/gma500/intel_bios.c   |  6 +-
 drivers/gpu/drm/gma500/intel_gmbus.c  |  4 +-
 drivers/gpu/drm/gma500/intel_i2c.c|  2 +-
 drivers/gpu/drm/gma500/mdfld_device.c |  4 +-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c|  8 +-
 drivers/gpu/drm/gma500/mid_bios.c |  9 +-
 drivers/gpu/drm/gma500/oaktrail_device.c  |  5 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c|  2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c|  2 +-
 drivers/gpu/drm/gma500/opregion.c |  3 +-
 drivers/gpu/drm/gma500/power.c| 13 +--
 drivers/gpu/drm/gma500/psb_drv.c  | 16 ++--
 drivers/gpu/drm/gma500/psb_drv.h  |  8 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c   |  6 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c   |  2 +-
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c| 36 
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   | 10 +--
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c   |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c   |  4 +-
 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/di

[PATCH 01/15] drm/amdgpu: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert amdgpu to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 23 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 10 -
 7 files changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7560b05e4ac1..d61715133825 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1404,9 +1404,9 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
*pdev,
/* don't suspend or resume card normally */
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
 
-   pci_set_power_state(dev->pdev, PCI_D0);
-   amdgpu_device_load_pci_state(dev->pdev);
-   r = pci_enable_device(dev->pdev);
+   pci_set_power_state(pdev, PCI_D0);
+   amdgpu_device_load_pci_state(pdev);
+   r = pci_enable_device(pdev);
if (r)
DRM_WARN("pci_enable_device failed (%d)\n", r);
amdgpu_device_resume(dev, true);
@@ -1418,10 +1418,10 @@ static void amdgpu_switcheroo_set_state(struct pci_dev 
*pdev,
drm_kms_helper_poll_disable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
amdgpu_device_suspend(dev, true);
-   amdgpu_device_cache_pci_state(dev->pdev);
+   amdgpu_device_cache_pci_state(pdev);
/* Shut down the device */
-   pci_disable_device(dev->pdev);
-   pci_set_power_state(dev->pdev, PCI_D3cold);
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, PCI_D3cold);
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
}
 }
@@ -1684,8 +1684,7 @@ static void amdgpu_device_enable_virtual_display(struct 
amdgpu_device *adev)
adev->enable_virtual_display = false;
 
if (amdgpu_virtual_display) {
-   struct drm_device *ddev = adev_to_drm(adev);
-   const char *pci_address_name = pci_name(ddev->pdev);
+   const char *pci_address_name = pci_name(adev->pdev);
char *pciaddstr, *pciaddstr_tmp, *pciaddname_tmp, *pciaddname;
 
pciaddstr = kstrdup(amdgpu_virtual_display, GFP_KERNEL);
@@ -3375,7 +3374,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
}
}
 
-   pci_enable_pcie_error_reporting(adev->ddev.pdev);
+   pci_enable_pcie_error_reporting(adev->pdev);
 
/* Post card if necessary */
if (amdgpu_device_need_post(adev)) {
@@ -4922,8 +4921,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev 
*pdev, pci_channel_sta
case pci_channel_io_normal:
return PCI_ERS_RESULT_CAN_RECOVER;
/* Fatal error, prepare for slot reset */
-   case pci_channel_io_frozen: 
-   /*  
+   case pci_channel_io_frozen:
+   /*
 * Cancel and wait for all TDRs in progress if failing to
 * set  adev->in_gpu_reset in amdgpu_device_lock_adev
 *
@@ -5014,7 +5013,7 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev 
*pdev)
goto out;
}
 
-   adev->in_pci_err_recovery = true;   
+   adev->in_pci_err_recovery = true;
r = amdgpu_device_pre_asic_reset(adev, NULL, &need_full_reset);
adev->in_pci_err_recovery = false;
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 2e8a8b57639f..77974c3981fa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -721,13 +721,14 @@ amdgpu_display_user_framebuffer_create(struct drm_device 
*dev,
   struct drm_file *file_priv,
   const struct drm_mode_fb_cmd2 *mode_cmd)
 {
+   struct amdgpu_device *adev = drm_to_adev(dev);
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
 
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj ==  NULL) {
-   dev_err(&dev->pdev->dev, "No GEM object associated to handle 
0x%08X, "
+   dev_err(&adev->pdev->dev, "No GEM object associated to handle 
0x%08X, "
"can't create framebuffer\n", mode_cmd->handles[0]);
return ERR_PTR(-ENOENT);

[PATCH 10/15] drm/qxl: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert qxl to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.c   | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 3 ++-
 drivers/gpu/drm/qxl/qxl_irq.c   | 3 ++-
 drivers/gpu/drm/qxl/qxl_kms.c   | 1 -
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 6e7f16f4cec7..fb5f6a5e81d7 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -163,7 +163,7 @@ DEFINE_DRM_GEM_FOPS(qxl_fops);
 
 static int qxl_drm_freeze(struct drm_device *dev)
 {
-   struct pci_dev *pdev = dev->pdev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct qxl_device *qdev = to_qxl(dev);
int ret;
 
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index 16e1e589508e..b6075f452b9e 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -370,13 +370,14 @@ static int qxl_clientcap_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *file_priv)
 {
struct qxl_device *qdev = to_qxl(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_qxl_clientcap *param = data;
int byte, idx;
 
byte = param->index / 8;
idx = param->index % 8;
 
-   if (dev->pdev->revision < 4)
+   if (pdev->revision < 4)
return -ENOSYS;
 
if (byte >= 58)
diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
index 1ba5a702d763..ddf6588a2a38 100644
--- a/drivers/gpu/drm/qxl/qxl_irq.c
+++ b/drivers/gpu/drm/qxl/qxl_irq.c
@@ -81,6 +81,7 @@ static void qxl_client_monitors_config_work_func(struct 
work_struct *work)
 
 int qxl_irq_init(struct qxl_device *qdev)
 {
+   struct pci_dev *pdev = to_pci_dev(qdev->ddev.dev);
int ret;
 
init_waitqueue_head(&qdev->display_event);
@@ -93,7 +94,7 @@ int qxl_irq_init(struct qxl_device *qdev)
atomic_set(&qdev->irq_received_cursor, 0);
atomic_set(&qdev->irq_received_io_cmd, 0);
qdev->irq_received_error = 0;
-   ret = drm_irq_install(&qdev->ddev, qdev->ddev.pdev->irq);
+   ret = drm_irq_install(&qdev->ddev, pdev->irq);
qdev->ram_header->int_mask = QXL_INTERRUPT_MASK;
if (unlikely(ret != 0)) {
DRM_ERROR("Failed installing irq: %d\n", ret);
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 228e2b9198f1..4a60a52ab62e 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -111,7 +111,6 @@ int qxl_device_init(struct qxl_device *qdev,
 {
int r, sb;
 
-   qdev->ddev.pdev = pdev;
pci_set_drvdata(pdev, &qdev->ddev);
 
mutex_init(&qdev->gem.mutex);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/15] drm/cirrus: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert cirrus to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Gerd Hoffmann 
---
 drivers/gpu/drm/tiny/cirrus.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 561c49d8657a..a043e602199e 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -602,7 +602,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
 
drm_mode_config_reset(dev);
 
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
ret = drm_dev_register(dev, 0);
if (ret)
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/15] drm/nouveau: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert nouveau to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Ben Skeggs 
---
 drivers/gpu/drm/nouveau/dispnv04/arb.c  | 12 +++-
 drivers/gpu/drm/nouveau/dispnv04/disp.h | 14 --
 drivers/gpu/drm/nouveau/dispnv04/hw.c   | 10 ++
 drivers/gpu/drm/nouveau/nouveau_abi16.c |  7 ---
 drivers/gpu/drm/nouveau/nouveau_acpi.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c  | 11 ---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 10 ++
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 ++---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  6 --
 drivers/gpu/drm/nouveau/nouveau_vga.c   | 20 
 10 files changed, 58 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/arb.c 
b/drivers/gpu/drm/nouveau/dispnv04/arb.c
index 9d4a2d97507e..1d3542d6006b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/arb.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/arb.c
@@ -200,16 +200,17 @@ nv04_update_arb(struct drm_device *dev, int VClk, int bpp,
int MClk = nouveau_hw_get_clock(dev, PLL_MEMORY);
int NVClk = nouveau_hw_get_clock(dev, PLL_CORE);
uint32_t cfg1 = nvif_rd32(device, NV04_PFB_CFG1);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
sim_data.pclk_khz = VClk;
sim_data.mclk_khz = MClk;
sim_data.nvclk_khz = NVClk;
sim_data.bpp = bpp;
sim_data.two_heads = nv_two_heads(dev);
-   if ((dev->pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
-   (dev->pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
+   if ((pdev->device & 0x) == 0x01a0 /*CHIPSET_NFORCE*/ ||
+   (pdev->device & 0x) == 0x01f0 /*CHIPSET_NFORCE2*/) {
uint32_t type;
-   int domain = pci_domain_nr(dev->pdev->bus);
+   int domain = pci_domain_nr(pdev->bus);
 
pci_read_config_dword(pci_get_domain_bus_and_slot(domain, 0, 1),
  0x7c, &type);
@@ -251,11 +252,12 @@ void
 nouveau_calc_arb(struct drm_device *dev, int vclk, int bpp, int *burst, int 
*lwm)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
if (drm->client.device.info.family < NV_DEVICE_INFO_V0_KELVIN)
nv04_update_arb(dev, vclk, bpp, burst, lwm);
-   else if ((dev->pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
-(dev->pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
+   else if ((pdev->device & 0xfff0) == 0x0240 /*CHIPSET_C51*/ ||
+(pdev->device & 0xfff0) == 0x03d0 /*CHIPSET_C512*/) {
*burst = 128;
*lwm = 0x0480;
} else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.h 
b/drivers/gpu/drm/nouveau/dispnv04/disp.h
index 5ace5e906949..f0a24126641a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.h
@@ -130,7 +130,7 @@ static inline bool
 nv_two_heads(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   const int impl = dev->pdev->device & 0x0ff0;
+   const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
 
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_CELSIUS && impl 
!= 0x0100 &&
impl != 0x0150 && impl != 0x01a0 && impl != 0x0200)
@@ -142,14 +142,14 @@ nv_two_heads(struct drm_device *dev)
 static inline bool
 nv_gf4_disp_arch(struct drm_device *dev)
 {
-   return nv_two_heads(dev) && (dev->pdev->device & 0x0ff0) != 0x0110;
+   return nv_two_heads(dev) && (to_pci_dev(dev->dev)->device & 0x0ff0) != 
0x0110;
 }
 
 static inline bool
 nv_two_reg_pll(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   const int impl = dev->pdev->device & 0x0ff0;
+   const int impl = to_pci_dev(dev->dev)->device & 0x0ff0;
 
if (impl == 0x0310 || impl == 0x0340 || drm->client.device.info.family 
>= NV_DEVICE_INFO_V0_CURIE)
return true;
@@ -160,9 +160,11 @@ static inline bool
 nv_match_device(struct drm_device *dev, unsigned device,
unsigned sub_vendor, unsigned sub_device)
 {
-   return dev->pdev->device == device &&
-   dev->pdev->subsystem_vendor == sub_vendor &&
-   dev->pdev->subsystem_device == sub_device;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+   return pdev->device == device &&
+   pdev->subsystem_vendor == sub_vendor &&
+   pdev->subsystem_device == sub_device;
 }
 
 #include 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/hw.c 
b/drivers/gpu/drm/nouveau/dispnv04/hw.c
index b674d68ef28a..f7d35657aa64 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/hw.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/hw.c
@@ -214,14 +214,15 @@ nouveau_hw_pllvals_to_clk(struct nvkm_pll_vals *pv)
 int
 nouveau_hw_get_clock(struct

[PATCH 06/15] drm/hibmc: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert hibmc to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Xinliang Liu 
Cc: Tian Tao  
Cc: John Stultz 
Cc: Xinwei Kong 
Cc: Chen Feng 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 10 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c |  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d845657fd99c..ac5868343d0c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -203,7 +203,7 @@ static void hibmc_hw_config(struct hibmc_drm_private *priv)
 static int hibmc_hw_map(struct hibmc_drm_private *priv)
 {
struct drm_device *dev = priv->dev;
-   struct pci_dev *pdev = dev->pdev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
resource_size_t addr, size, ioaddr, iosize;
 
ioaddr = pci_resource_start(pdev, 1);
@@ -249,7 +249,7 @@ static int hibmc_unload(struct drm_device *dev)
if (dev->irq_enabled)
drm_irq_uninstall(dev);
 
-   pci_disable_msi(dev->pdev);
+   pci_disable_msi(to_pci_dev(dev->dev));
hibmc_kms_fini(priv);
hibmc_mm_fini(priv);
dev->dev_private = NULL;
@@ -258,6 +258,7 @@ static int hibmc_unload(struct drm_device *dev)
 
 static int hibmc_load(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct hibmc_drm_private *priv;
int ret;
 
@@ -287,11 +288,11 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
 
-   ret = pci_enable_msi(dev->pdev);
+   ret = pci_enable_msi(pdev);
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
-   ret = drm_irq_install(dev, dev->pdev->irq);
+   ret = drm_irq_install(dev, pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
@@ -324,7 +325,6 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
return PTR_ERR(dev);
}
 
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
ret = pci_enable_device(pdev);
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
index 86d712090d87..410bd019bb35 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_i2c.c
@@ -83,7 +83,7 @@ int hibmc_ddc_create(struct drm_device *drm_dev,
connector->adapter.owner = THIS_MODULE;
connector->adapter.class = I2C_CLASS_DDC;
snprintf(connector->adapter.name, I2C_NAME_SIZE, "HIS i2c bit bus");
-   connector->adapter.dev.parent = &drm_dev->pdev->dev;
+   connector->adapter.dev.parent = drm_dev->dev;
i2c_set_adapdata(&connector->adapter, connector);
connector->adapter.algo_data = &connector->bit_data;
 
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 602ece11bb4a..77f075075db2 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -26,9 +26,9 @@ int hibmc_mm_init(struct hibmc_drm_private *hibmc)
struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = hibmc->dev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
-   vmm = drm_vram_helper_alloc_mm(dev,
-  pci_resource_start(dev->pdev, 0),
+   vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(pdev, 0),
   hibmc->fb_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/15] 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.

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_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 +++---
 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   |  4 ++--
 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   |  5 +++--
 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_region_lmem.c  |  8 
 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 +-
 42 files changed, 99 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4cc949b228f2..8879676372a3 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2088,7 +2088,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 c449d28d0560..a6e13208dc50 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, &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, &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;
+   st

[PATCH 08/15] drm/mgag200: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert mgag200 to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/mgag200_drv.c | 20 +++-
 drivers/gpu/drm/mgag200/mgag200_i2c.c |  2 +-
 drivers/gpu/drm/mgag200/mgag200_mm.c  | 10 ++
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index a977c9f49719..4e4c105f9a50 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -47,10 +47,11 @@ static const struct drm_driver mgag200_driver = {
 static bool mgag200_has_sgram(struct mga_device *mdev)
 {
struct drm_device *dev = &mdev->base;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 option;
int ret;
 
-   ret = pci_read_config_dword(dev->pdev, PCI_MGA_OPTION, &option);
+   ret = pci_read_config_dword(pdev, PCI_MGA_OPTION, &option);
if (drm_WARN(dev, ret, "failed to read PCI config dword: %d\n", ret))
return false;
 
@@ -60,6 +61,7 @@ static bool mgag200_has_sgram(struct mga_device *mdev)
 static int mgag200_regs_init(struct mga_device *mdev)
 {
struct drm_device *dev = &mdev->base;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 option, option2;
u8 crtcext3;
 
@@ -99,13 +101,13 @@ static int mgag200_regs_init(struct mga_device *mdev)
}
 
if (option)
-   pci_write_config_dword(dev->pdev, PCI_MGA_OPTION, option);
+   pci_write_config_dword(pdev, PCI_MGA_OPTION, option);
if (option2)
-   pci_write_config_dword(dev->pdev, PCI_MGA_OPTION2, option2);
+   pci_write_config_dword(pdev, PCI_MGA_OPTION2, option2);
 
/* BAR 1 contains registers */
-   mdev->rmmio_base = pci_resource_start(dev->pdev, 1);
-   mdev->rmmio_size = pci_resource_len(dev->pdev, 1);
+   mdev->rmmio_base = pci_resource_start(pdev, 1);
+   mdev->rmmio_size = pci_resource_len(pdev, 1);
 
if (!devm_request_mem_region(dev->dev, mdev->rmmio_base,
 mdev->rmmio_size, "mgadrmfb_mmio")) {
@@ -113,7 +115,7 @@ static int mgag200_regs_init(struct mga_device *mdev)
return -ENOMEM;
}
 
-   mdev->rmmio = pcim_iomap(dev->pdev, 1, 0);
+   mdev->rmmio = pcim_iomap(pdev, 1, 0);
if (mdev->rmmio == NULL)
return -ENOMEM;
 
@@ -218,6 +220,7 @@ static void mgag200_g200_interpret_bios(struct mga_device 
*mdev,
 static void mgag200_g200_init_refclk(struct mga_device *mdev)
 {
struct drm_device *dev = &mdev->base;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
unsigned char __iomem *rom;
unsigned char *bios;
size_t size;
@@ -226,7 +229,7 @@ static void mgag200_g200_init_refclk(struct mga_device 
*mdev)
mdev->model.g200.pclk_max = 23;
mdev->model.g200.ref_clk = 27050;
 
-   rom = pci_map_rom(dev->pdev, &size);
+   rom = pci_map_rom(pdev, &size);
if (!rom)
return;
 
@@ -244,7 +247,7 @@ static void mgag200_g200_init_refclk(struct mga_device 
*mdev)
 
vfree(bios);
 out:
-   pci_unmap_rom(dev->pdev, rom);
+   pci_unmap_rom(pdev, rom);
 }
 
 static void mgag200_g200se_init_unique_id(struct mga_device *mdev)
@@ -301,7 +304,6 @@ mgag200_device_create(struct pci_dev *pdev, unsigned long 
flags)
return mdev;
dev = &mdev->base;
 
-   dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
 
ret = mgag200_device_init(mdev, flags);
diff --git a/drivers/gpu/drm/mgag200/mgag200_i2c.c 
b/drivers/gpu/drm/mgag200/mgag200_i2c.c
index 09731e614e46..ac8e34eef513 100644
--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -126,7 +126,7 @@ struct mga_i2c_chan *mgag200_i2c_create(struct drm_device 
*dev)
i2c->clock = clock;
i2c->adapter.owner = THIS_MODULE;
i2c->adapter.class = I2C_CLASS_DDC;
-   i2c->adapter.dev.parent = &dev->pdev->dev;
+   i2c->adapter.dev.parent = dev->dev;
i2c->dev = dev;
i2c_set_adapdata(&i2c->adapter, i2c);
snprintf(i2c->adapter.name, sizeof(i2c->adapter.name), "mga i2c");
diff --git a/drivers/gpu/drm/mgag200/mgag200_mm.c 
b/drivers/gpu/drm/mgag200/mgag200_mm.c
index 641f1aa992be..b667371b69a4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mm.c
@@ -78,11 +78,12 @@ static size_t mgag200_probe_vram(struct mga_device *mdev, 
void __iomem *mem,
 static void mgag200_mm_release(struct drm_device *dev, void *ptr)
 {
struct mga_device *mdev = to_mga_device(dev);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
mdev->vram_fb_available = 0;
iounmap(mdev->vram);
-   arch_io_free_memtype_wc(pci_resource_start(dev->pdev, 0),
-   pci_resource_len(dev->pdev,

[PATCH 05/15] drm/gma500: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert gma500 to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_device.c| 30 +++---
 drivers/gpu/drm/gma500/cdv_intel_crt.c |  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  4 +--
 drivers/gpu/drm/gma500/framebuffer.c   |  9 +++---
 drivers/gpu/drm/gma500/gma_device.c|  3 +-
 drivers/gpu/drm/gma500/gma_display.c   |  4 +--
 drivers/gpu/drm/gma500/gtt.c   | 20 ++--
 drivers/gpu/drm/gma500/intel_bios.c|  6 ++--
 drivers/gpu/drm/gma500/intel_gmbus.c   |  4 +--
 drivers/gpu/drm/gma500/intel_i2c.c |  2 +-
 drivers/gpu/drm/gma500/mdfld_device.c  |  4 ++-
 drivers/gpu/drm/gma500/mdfld_dsi_dpi.c |  8 ++---
 drivers/gpu/drm/gma500/mid_bios.c  |  9 --
 drivers/gpu/drm/gma500/oaktrail_device.c   |  5 +--
 drivers/gpu/drm/gma500/oaktrail_lvds.c |  2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c |  2 +-
 drivers/gpu/drm/gma500/opregion.c  |  3 +-
 drivers/gpu/drm/gma500/power.c | 13 
 drivers/gpu/drm/gma500/psb_drv.c   | 16 +-
 drivers/gpu/drm/gma500/psb_drv.h   |  8 ++---
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  6 ++--
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|  2 +-
 drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 36 +++---
 23 files changed, 109 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index e75293e4a52f..19e055dbd4c2 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -95,13 +95,14 @@ static u32 cdv_get_max_backlight(struct drm_device *dev)
 static int cdv_get_brightness(struct backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 val = REG_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
 
if (cdv_backlight_combination_mode(dev)) {
u8 lbpc;
 
val &= ~1;
-   pci_read_config_byte(dev->pdev, 0xF4, &lbpc);
+   pci_read_config_byte(pdev, 0xF4, &lbpc);
val *= lbpc;
}
return (val * 100)/cdv_get_max_backlight(dev);
@@ -111,6 +112,7 @@ static int cdv_get_brightness(struct backlight_device *bd)
 static int cdv_set_brightness(struct backlight_device *bd)
 {
struct drm_device *dev = bl_get_data(bd);
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
int level = bd->props.brightness;
u32 blc_pwm_ctl;
 
@@ -128,7 +130,7 @@ static int cdv_set_brightness(struct backlight_device *bd)
lbpc = level * 0xfe / max + 1;
level /= lbpc;
 
-   pci_write_config_byte(dev->pdev, 0xF4, lbpc);
+   pci_write_config_byte(pdev, 0xF4, lbpc);
}
 
blc_pwm_ctl = REG_READ(BLC_PWM_CTL) & ~BACKLIGHT_DUTY_CYCLE_MASK;
@@ -205,8 +207,9 @@ static inline void CDV_MSG_WRITE32(int domain, uint port, 
uint offset,
 static void cdv_init_pm(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
u32 pwr_cnt;
-   int domain = pci_domain_nr(dev->pdev->bus);
+   int domain = pci_domain_nr(pdev->bus);
int i;
 
dev_priv->apm_base = CDV_MSG_READ32(domain, PSB_PUNIT_PORT,
@@ -234,6 +237,8 @@ static void cdv_init_pm(struct drm_device *dev)
 
 static void cdv_errata(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
/* Disable bonus launch.
 *  CPU and GPU competes for memory and display misses updates and
 *  flickers. Worst with dual core, dual displays.
@@ -242,7 +247,7 @@ static void cdv_errata(struct drm_device *dev)
 *  Bonus Launch to work around the issue, by degrading
 *  performance.
 */
-CDV_MSG_WRITE32(pci_domain_nr(dev->pdev->bus), 3, 0x30, 0x08027108);
+CDV_MSG_WRITE32(pci_domain_nr(pdev->bus), 3, 0x30, 0x08027108);
 }
 
 /**
@@ -255,12 +260,13 @@ static void cdv_errata(struct drm_device *dev)
 static int cdv_save_display_registers(struct drm_device *dev)
 {
struct drm_psb_private *dev_priv = dev->dev_private;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct psb_save_area *regs = &dev_priv->regs;
struct drm_connector *connector;
 
dev_dbg(dev->dev, "Saving GPU registers.\n");
 
-   pci_read_config_byte(dev->pdev, 0xF4, ®s->cdv.saveLBB);
+   pci_read_config_byte(pdev, 0xF4, ®s->cdv.saveLBB);
 
regs->cdv.saveDSPCLK_GATE_D = REG_READ(DSPCLK_GATE_D);
regs->cdv.saveRAMCLK_GATE_D = REG_READ(RAMCLK_GATE_D);
@@ -309,11 +315,12 @@ static int cdv_save_display_registers(struct drm_device 
*dev)
 static int cdv_restore_display_registers(struct drm_device *dev)
 {
struct d

[PATCH 11/15] drm/radeon: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert radeon to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/radeon/atombios_encoders.c|  6 +-
 drivers/gpu/drm/radeon/r100.c | 27 +++---
 drivers/gpu/drm/radeon/radeon.h   | 32 +++
 drivers/gpu/drm/radeon/radeon_atombios.c  | 89 ++-
 drivers/gpu/drm/radeon/radeon_bios.c  |  6 +-
 drivers/gpu/drm/radeon/radeon_combios.c   | 55 ++--
 drivers/gpu/drm/radeon/radeon_cs.c|  3 +-
 drivers/gpu/drm/radeon/radeon_device.c| 17 ++--
 drivers/gpu/drm/radeon/radeon_display.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  3 +-
 drivers/gpu/drm/radeon/radeon_fb.c|  2 +-
 drivers/gpu/drm/radeon/radeon_gem.c   |  6 +-
 drivers/gpu/drm/radeon/radeon_i2c.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_irq_kms.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   | 20 ++---
 .../gpu/drm/radeon/radeon_legacy_encoders.c   |  6 +-
 drivers/gpu/drm/radeon/rs780_dpm.c|  7 +-
 17 files changed, 144 insertions(+), 141 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index cc5ee1b3af84..a9ae8b6c5991 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2065,9 +2065,9 @@ atombios_apply_encoder_quirks(struct drm_encoder *encoder,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
 
/* Funky macbooks */
-   if ((dev->pdev->device == 0x71C5) &&
-   (dev->pdev->subsystem_vendor == 0x106b) &&
-   (dev->pdev->subsystem_device == 0x0080)) {
+   if ((rdev->pdev->device == 0x71C5) &&
+   (rdev->pdev->subsystem_vendor == 0x106b) &&
+   (rdev->pdev->subsystem_device == 0x0080)) {
if (radeon_encoder->devices & ATOM_DEVICE_LCD1_SUPPORT) {
uint32_t lvtma_bit_depth_control = 
RREG32(AVIVO_LVTMA_BIT_DEPTH_CONTROL);
 
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 24c8db673931..984eeb893d76 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2611,7 +2611,6 @@ int r100_asic_reset(struct radeon_device *rdev, bool hard)
 
 void r100_set_common_regs(struct radeon_device *rdev)
 {
-   struct drm_device *dev = rdev->ddev;
bool force_dac2 = false;
u32 tmp;
 
@@ -2629,7 +2628,7 @@ void r100_set_common_regs(struct radeon_device *rdev)
 * don't report it in the bios connector
 * table.
 */
-   switch (dev->pdev->device) {
+   switch (rdev->pdev->device) {
/* RN50 */
case 0x515e:
case 0x5969:
@@ -2639,17 +2638,17 @@ void r100_set_common_regs(struct radeon_device *rdev)
case 0x5159:
case 0x515a:
/* DELL triple head servers */
-   if ((dev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
-   ((dev->pdev->subsystem_device == 0x016c) ||
-(dev->pdev->subsystem_device == 0x016d) ||
-(dev->pdev->subsystem_device == 0x016e) ||
-(dev->pdev->subsystem_device == 0x016f) ||
-(dev->pdev->subsystem_device == 0x0170) ||
-(dev->pdev->subsystem_device == 0x017d) ||
-(dev->pdev->subsystem_device == 0x017e) ||
-(dev->pdev->subsystem_device == 0x0183) ||
-(dev->pdev->subsystem_device == 0x018a) ||
-(dev->pdev->subsystem_device == 0x019a)))
+   if ((rdev->pdev->subsystem_vendor == 0x1028 /* DELL */) &&
+   ((rdev->pdev->subsystem_device == 0x016c) ||
+(rdev->pdev->subsystem_device == 0x016d) ||
+(rdev->pdev->subsystem_device == 0x016e) ||
+(rdev->pdev->subsystem_device == 0x016f) ||
+(rdev->pdev->subsystem_device == 0x0170) ||
+(rdev->pdev->subsystem_device == 0x017d) ||
+(rdev->pdev->subsystem_device == 0x017e) ||
+(rdev->pdev->subsystem_device == 0x0183) ||
+(rdev->pdev->subsystem_device == 0x018a) ||
+(rdev->pdev->subsystem_device == 0x019a)))
force_dac2 = true;
break;
}
@@ -2797,7 +2796,7 @@ void r100_vram_init_sizes(struct radeon_device *rdev)
rdev->mc.real_vram_size = 8192 * 1024;
WREG32(RADEON_CONFIG_MEMSIZE, rdev->mc.real_vram_size);
}
-   /* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM - 
+   /* Fix for RN50, M6, M7 with 8/16/32(??) MBs of VRAM -
 * Novell bug 204882 + along with lots of ubuntu ones

[PATCH 15/15] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev

We have DRM drivers based on USB, SPI and platform devices. All of them
are fine with storing their device reference in struct drm_device.dev.
PCI devices should be no exception. Therefore struct drm_device.pdev is
deprecated.

Instead upcast from struct drm_device.dev with to_pci_dev(). PCI-specific
code can use dev_is_pci() to test for a PCI device. This patch changes
the DRM core code and documentation accordingly. Struct drm_device.pdev
is being moved to legacy status.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_agpsupport.c |  9 ++---
 drivers/gpu/drm/drm_bufs.c   |  4 ++--
 drivers/gpu/drm/drm_edid.c   |  7 ++-
 drivers/gpu/drm/drm_irq.c| 12 +++-
 drivers/gpu/drm/drm_pci.c| 26 +++---
 drivers/gpu/drm/drm_vm.c |  2 +-
 include/drm/drm_device.h | 12 +---
 7 files changed, 46 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 4c7ad46fdd21..a4040fe4f4ba 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -103,11 +103,13 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
  */
 int drm_agp_acquire(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+
if (!dev->agp)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
-   dev->agp->bridge = agp_backend_acquire(dev->pdev);
+   dev->agp->bridge = agp_backend_acquire(pdev);
if (!dev->agp->bridge)
return -ENODEV;
dev->agp->acquired = 1;
@@ -402,14 +404,15 @@ int drm_agp_free_ioctl(struct drm_device *dev, void *data,
  */
 struct drm_agp_head *drm_agp_init(struct drm_device *dev)
 {
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct drm_agp_head *head = NULL;
 
head = kzalloc(sizeof(*head), GFP_KERNEL);
if (!head)
return NULL;
-   head->bridge = agp_find_bridge(dev->pdev);
+   head->bridge = agp_find_bridge(pdev);
if (!head->bridge) {
-   head->bridge = agp_backend_acquire(dev->pdev);
+   head->bridge = agp_backend_acquire(pdev);
if (!head->bridge) {
kfree(head);
return NULL;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 7a01d0918861..1da8b360b60a 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -325,7 +325,7 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
 * As we're limiting the address to 2^32-1 (or less),
 * casting it down to 32 bits is no problem, but we
 * need to point to a 64bit variable first. */
-   map->handle = dma_alloc_coherent(&dev->pdev->dev,
+   map->handle = dma_alloc_coherent(dev->dev,
 map->size,
 &map->offset,
 GFP_KERNEL);
@@ -555,7 +555,7 @@ int drm_legacy_rmmap_locked(struct drm_device *dev, struct 
drm_local_map *map)
case _DRM_SCATTER_GATHER:
break;
case _DRM_CONSISTENT:
-   dma_free_coherent(&dev->pdev->dev,
+   dma_free_coherent(dev->dev,
  map->size,
  map->handle,
  map->offset);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..555a04ce2179 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -2075,9 +2076,13 @@ EXPORT_SYMBOL(drm_get_edid);
 struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
 struct i2c_adapter *adapter)
 {
-   struct pci_dev *pdev = connector->dev->pdev;
+   struct drm_device *dev = connector->dev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
struct edid *edid;
 
+   if (drm_WARN_ON_ONCE(dev, !dev_is_pci(dev->dev)))
+   return NULL;
+
vga_switcheroo_lock_ddc(pdev);
edid = drm_get_edid(connector, adapter);
vga_switcheroo_unlock_ddc(pdev);
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 09d6e9e2e075..22986a9a593b 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -122,7 +122,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
dev->driver->irq_preinstall(dev);
 
/* PCI devices require shared interrupts. */
-   if (dev->pdev)
+   if (dev_is_pci(dev->dev))
sh_flags = IRQF_SHARED;
 
ret = request_irq(irq, dev->driver->irq_handler,
@@ -140,7 +140,7 @@ int drm_irq_install(struct drm_device *dev, int irq)
if (ret < 0) {

[PATCH 13/15] drm/virtgpu: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert virtgpu to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index 27f13bd29c13..a21dc3ad6f88 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -54,7 +54,6 @@ static int virtio_gpu_pci_quirk(struct drm_device *dev, 
struct virtio_device *vd
DRM_INFO("pci: %s detected at %s\n",
 vga ? "virtio-vga" : "virtio-gpu-pci",
 pname);
-   dev->pdev = pdev;
if (vga)
drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
  
"virtiodrmfb");
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/15] drm/vboxvideo: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert vboxvideo to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Hans de Goede 
---
 drivers/gpu/drm/vboxvideo/vbox_drv.c  | 11 ++-
 drivers/gpu/drm/vboxvideo/vbox_irq.c  |  4 +++-
 drivers/gpu/drm/vboxvideo/vbox_main.c |  8 ++--
 drivers/gpu/drm/vboxvideo/vbox_ttm.c  |  7 ---
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index f3eac72cb46e..e534896b6cfd 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -51,7 +51,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
if (IS_ERR(vbox))
return PTR_ERR(vbox);
 
-   vbox->ddev.pdev = pdev;
pci_set_drvdata(pdev, vbox);
mutex_init(&vbox->hw_mutex);
 
@@ -109,15 +108,16 @@ static void vbox_pci_remove(struct pci_dev *pdev)
 static int vbox_pm_suspend(struct device *dev)
 {
struct vbox_private *vbox = dev_get_drvdata(dev);
+   struct pci_dev *pdev = to_pci_dev(dev);
int error;
 
error = drm_mode_config_helper_suspend(&vbox->ddev);
if (error)
return error;
 
-   pci_save_state(vbox->ddev.pdev);
-   pci_disable_device(vbox->ddev.pdev);
-   pci_set_power_state(vbox->ddev.pdev, PCI_D3hot);
+   pci_save_state(pdev);
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, PCI_D3hot);
 
return 0;
 }
@@ -125,8 +125,9 @@ static int vbox_pm_suspend(struct device *dev)
 static int vbox_pm_resume(struct device *dev)
 {
struct vbox_private *vbox = dev_get_drvdata(dev);
+   struct pci_dev *pdev = to_pci_dev(dev);
 
-   if (pci_enable_device(vbox->ddev.pdev))
+   if (pci_enable_device(pdev))
return -EIO;
 
return drm_mode_config_helper_resume(&vbox->ddev);
diff --git a/drivers/gpu/drm/vboxvideo/vbox_irq.c 
b/drivers/gpu/drm/vboxvideo/vbox_irq.c
index 631657fa554f..b3ded68603ba 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_irq.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_irq.c
@@ -170,10 +170,12 @@ static void vbox_hotplug_worker(struct work_struct *work)
 
 int vbox_irq_init(struct vbox_private *vbox)
 {
+   struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
+
INIT_WORK(&vbox->hotplug_work, vbox_hotplug_worker);
vbox_update_mode_hints(vbox);
 
-   return drm_irq_install(&vbox->ddev, vbox->ddev.pdev->irq);
+   return drm_irq_install(&vbox->ddev, pdev->irq);
 }
 
 void vbox_irq_fini(struct vbox_private *vbox)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c 
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index d68d9bad7674..f28779715ccd 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -8,7 +8,9 @@
  *  Hans de Goede 
  */
 
+#include 
 #include 
+
 #include 
 #include 
 #include 
@@ -30,6 +32,7 @@ void vbox_report_caps(struct vbox_private *vbox)
 
 static int vbox_accel_init(struct vbox_private *vbox)
 {
+   struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
struct vbva_buffer *vbva;
unsigned int i;
 
@@ -41,7 +44,7 @@ static int vbox_accel_init(struct vbox_private *vbox)
/* Take a command buffer for each screen from the end of usable VRAM. */
vbox->available_vram_size -= vbox->num_crtcs * VBVA_MIN_BUFFER_SIZE;
 
-   vbox->vbva_buffers = pci_iomap_range(vbox->ddev.pdev, 0,
+   vbox->vbva_buffers = pci_iomap_range(pdev, 0,
 vbox->available_vram_size,
 vbox->num_crtcs *
 VBVA_MIN_BUFFER_SIZE);
@@ -106,6 +109,7 @@ bool vbox_check_supported(u16 id)
 
 int vbox_hw_init(struct vbox_private *vbox)
 {
+   struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev);
int ret = -ENOMEM;
 
vbox->full_vram_size = inl(VBE_DISPI_IOPORT_DATA);
@@ -115,7 +119,7 @@ int vbox_hw_init(struct vbox_private *vbox)
 
/* Map guest-heap at end of vram */
vbox->guest_heap =
-   pci_iomap_range(vbox->ddev.pdev, 0, GUEST_HEAP_OFFSET(vbox),
+   pci_iomap_range(pdev, 0, GUEST_HEAP_OFFSET(vbox),
GUEST_HEAP_SIZE);
if (!vbox->guest_heap)
return -ENOMEM;
diff --git a/drivers/gpu/drm/vboxvideo/vbox_ttm.c 
b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
index f5a06675da43..0066a3c1dfc9 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_ttm.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_ttm.c
@@ -15,8 +15,9 @@ int vbox_mm_init(struct vbox_private *vbox)
struct drm_vram_mm *vmm;
int ret;
struct drm_device *dev = &vbox->ddev;
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
-   vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(dev->pdev, 0),
+   vmm = drm_vram_helper_alloc_mm(dev, pci_resource_start(pdev, 0),

[PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct
drm_device.dev. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Roland Scheidegger 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 27 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 9a9fe10d829b..83a8d34704ea 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -1230,7 +1230,7 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man,
 
/* First, try to allocate a huge chunk of DMA memory */
size = PAGE_ALIGN(size);
-   man->map = dma_alloc_coherent(&dev_priv->dev->pdev->dev, size,
+   man->map = dma_alloc_coherent(dev_priv->dev->dev, size,
  &man->handle, GFP_KERNEL);
if (man->map) {
man->using_mob = false;
@@ -1313,7 +1313,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct 
vmw_private *dev_priv)
man->num_contexts = (dev_priv->capabilities & SVGA_CAP_HP_CMD_QUEUE) ?
2 : 1;
man->headers = dma_pool_create("vmwgfx cmdbuf",
-  &dev_priv->dev->pdev->dev,
+  dev_priv->dev->dev,
   sizeof(SVGACBHeader),
   64, PAGE_SIZE);
if (!man->headers) {
@@ -1322,7 +1322,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct 
vmw_private *dev_priv)
}
 
man->dheaders = dma_pool_create("vmwgfx inline cmdbuf",
-   &dev_priv->dev->pdev->dev,
+   dev_priv->dev->dev,
sizeof(struct vmw_cmdbuf_dheader),
64, PAGE_SIZE);
if (!man->dheaders) {
@@ -1387,7 +1387,7 @@ void vmw_cmdbuf_remove_pool(struct vmw_cmdbuf_man *man)
ttm_bo_put(man->cmd_space);
man->cmd_space = NULL;
} else {
-   dma_free_coherent(&man->dev_priv->dev->pdev->dev,
+   dma_free_coherent(man->dev_priv->dev->dev,
  man->size, man->map, man->handle);
}
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 216daf93022c..e63e08f5b14f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -652,6 +652,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
enum vmw_res_type i;
bool refuse_dma = false;
char host_log[100] = {0};
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
 
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
if (unlikely(!dev_priv)) {
@@ -659,7 +660,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
return -ENOMEM;
}
 
-   pci_set_master(dev->pdev);
+   pci_set_master(pdev);
 
dev_priv->dev = dev;
dev_priv->vmw_chipset = chipset;
@@ -688,9 +689,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
 
dev_priv->used_memory_size = 0;
 
-   dev_priv->io_start = pci_resource_start(dev->pdev, 0);
-   dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
-   dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
+   dev_priv->io_start = pci_resource_start(pdev, 0);
+   dev_priv->vram_start = pci_resource_start(pdev, 1);
+   dev_priv->mmio_start = pci_resource_start(pdev, 2);
 
dev_priv->assume_16bpp = !!vmw_assume_16bpp;
 
@@ -840,7 +841,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
 
dev->dev_private = dev_priv;
 
-   ret = pci_request_regions(dev->pdev, "vmwgfx probe");
+   ret = pci_request_regions(pdev, "vmwgfx probe");
dev_priv->stealth = (ret != 0);
if (dev_priv->stealth) {
/**
@@ -849,7 +850,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
 
DRM_INFO("It appears like vesafb is loaded. "
 "Ignore above error if any.\n");
-   ret = pci_request_region(dev->pdev, 2, "vmwgfx stealth probe");
+   ret = pci_request_region(pdev, 2, "vmwgfx stealth probe");
if (unlikely(ret != 0)) {
DRM_ERROR("Failed reserving the SVGA MMIO resource.\n");
goto out_no_device;
@@ -857,7 +858,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
}
 
if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
-   ret = vmw_irq_install(dev, dev->pdev->irq);
+   ret = vmw_irq_install(dev, pdev->irq);

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Hi

Am 24.11.20 um 12:30 schrieb Christian König:

Am 24.11.20 um 10:16 schrieb Thomas Zimmermann:

Hi Christian

Am 16.11.20 um 12:28 schrieb Christian König:

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:

In order to avoid eviction of vmap'ed buffers, pin them in their GEM
object's vmap implementation. Unpin them in the vunmap 
implementation.

This is needed to make generic fbdev support work reliably. Without,
the buffer object could be evicted while fbdev flushed its shadow 
buffer.


In difference to the PRIME pin/unpin functions, the vmap code does 
not
modify the BOs prime_shared_count, so a vmap-pinned BO does not 
count as

shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.


Ok in this case that should work.


If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into the
BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.


The problem is what happens when it is prepared for scanout, but 
can't be moved to VRAM because it is vmapped?


When the shadow is never scanned out that isn't a problem, but we 
need to keep that in mind.




I'd like ask for your suggestions before sending an update for this 
patch.


After the discussion about locking in fbdev, [1] I intended to replace 
the pin call with code that acquires the reservation lock.


Yeah, that sounds like a good idea to me as well.

First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but then 
wondered why ttm_bo_vmap() doe not acquire the lock internally? I'd 
expect that vmap/vunmap are close together and do not overlap for the 
same BO. 


We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with 
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the 
lock/unlock into it and I hope to replace the kmap/kunmap functions with 
them in the near term.


Otherwise, acquiring the reservation lock would require another 
ref-counting variable or per-driver code.


Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper as 
you initially planned.


Given your example above, step one would acquire the lock, and step two 
would also acquire the lock as part of the vmap implementation. Wouldn't 
this fail (At least during unmap or unlock steps) ?


Best regards
Thomas



Regards,
Christian.



Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/401088/?series=83918&rev=1


Regards,
Christian.



For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432&data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3D&reserved=0 




Regards,
Christian.


Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/radeon/radeon_gem.c | 51 
+++--

   1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d2876ce3bc9e..eaf7fc9a7b07 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
radeon_device *rdev, int r)
   return r;
   }
   +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
+   RADEON_GEM_DOMAIN_GTT |
+   RADEON_GEM_DOMAIN_CPU;
+
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return ret;
+
+    /* pin buffer at its current location */
+    ret = radeon_bo_pin(bo, any_domain, NULL);
+    if (ret)
+    goto err_radeon_bo_unreserve;
+
+    ret = d

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Am 24.11.20 um 12:44 schrieb Thomas Zimmermann:

Hi

Am 24.11.20 um 12:30 schrieb Christian König:

Am 24.11.20 um 10:16 schrieb Thomas Zimmermann:

Hi Christian

Am 16.11.20 um 12:28 schrieb Christian König:

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:
In order to avoid eviction of vmap'ed buffers, pin them in their 
GEM
object's vmap implementation. Unpin them in the vunmap 
implementation.
This is needed to make generic fbdev support work reliably. 
Without,
the buffer object could be evicted while fbdev flushed its 
shadow buffer.


In difference to the PRIME pin/unpin functions, the vmap code 
does not
modify the BOs prime_shared_count, so a vmap-pinned BO does not 
count as

shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.


Ok in this case that should work.


If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into 
the

BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.


The problem is what happens when it is prepared for scanout, but 
can't be moved to VRAM because it is vmapped?


When the shadow is never scanned out that isn't a problem, but we 
need to keep that in mind.




I'd like ask for your suggestions before sending an update for this 
patch.


After the discussion about locking in fbdev, [1] I intended to 
replace the pin call with code that acquires the reservation lock.


Yeah, that sounds like a good idea to me as well.

First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but then 
wondered why ttm_bo_vmap() doe not acquire the lock internally? I'd 
expect that vmap/vunmap are close together and do not overlap for 
the same BO. 


We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with 
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the 
lock/unlock into it and I hope to replace the kmap/kunmap functions 
with them in the near term.


Otherwise, acquiring the reservation lock would require another 
ref-counting variable or per-driver code.


Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper as 
you initially planned.


Given your example above, step one would acquire the lock, and step 
two would also acquire the lock as part of the vmap implementation. 
Wouldn't this fail (At least during unmap or unlock steps) ?


Oh, so you want to nest them? No, that is a rather bad no-go.

You need to make sure that the lock is only taken from the FB path which 
wants to vmap the object.


Why don't you lock the GEM object from the caller in the generic FB 
implementation?


Regards,
Christian.



Best regards
Thomas



Regards,
Christian.



Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/401088/?series=83918&rev=1


Regards,
Christian.



For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432&data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3D&reserved=0 




Regards,
Christian.


Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/radeon/radeon_gem.c | 51 
+++--

   1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d2876ce3bc9e..eaf7fc9a7b07 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
radeon_device *rdev, int r)
   return r;
   }
   +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
+   RADEON_GEM_DOMAIN_GTT |
+   RADEO

[PATCH] dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.

2020-11-24 Thread Maarten Lankhorst

We hardcode the maximum number of shared fences to 4, instead of
respecting num_fences. Use a minimum of 4, but more if num_fences
is higher.

This seems to have been an oversight when first implementing the
api.

Fixes: 04a5faa8cbe5 ("reservation: update api and add some helpers")
Cc:  # v3.17+
Reported-by: Niranjana Vishwanathapura 
Signed-off-by: Maarten Lankhorst 
---
 drivers/dma-buf/dma-resv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index bb5a42b10c29..6ddbeb5dfbf6 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -200,7 +200,7 @@ int dma_resv_reserve_shared(struct dma_resv *obj, unsigned 
int num_fences)
max = max(old->shared_count + num_fences,
  old->shared_max * 2);
} else {
-   max = 4;
+   max = max(4ul, roundup_pow_of_two(num_fences));
}
 
new = dma_resv_list_alloc(max);

base-commit: d08ea807a6466f311fe921872bc18cfc384ae281
prerequisite-patch-id: 67ededd6181f1f0d00b98376bcacefb776ebfd1b
prerequisite-patch-id: 36ea30085b8b6095303642e82a6d9c2373d331c2
prerequisite-patch-id: 453c3fe559333daea47bc5d24171b32ae8483c2d
prerequisite-patch-id: 3792e6478845da3a19dda5fdca5d094d3847c6e3
prerequisite-patch-id: 7d4e280d1197ead2e3f90d10d0c38c4685bedd86
prerequisite-patch-id: 6db8468aba0d92cd5d67af028caebe4146b9f02e
prerequisite-patch-id: 6550921ad75aaa9ddd30db6a75878d06c13ab6bb
prerequisite-patch-id: 35cfae6d6d6c30453026284fc2b25733f005f950
prerequisite-patch-id: 3bf03aa3ed1532d6c67fa47cec3ba34418ea5a79
prerequisite-patch-id: 580e28da7a0e724c293eb5b36a35be0964554885
prerequisite-patch-id: 61932497d71dc764e040deea7a58286dca51a6e0
prerequisite-patch-id: b3f6ac925fd9f3517e63b0595ce138fdd0196db2
prerequisite-patch-id: 609d83e906e26c4d9c0fb5ba29f66eec0234d11b
prerequisite-patch-id: 88264df437b404b00bba07edb7761762c52daa9d
prerequisite-patch-id: 2d3d4efeb0e32423938d546a683513ee8077143e
prerequisite-patch-id: 675d46b64f98322e8ab90b947598d030f1133120
prerequisite-patch-id: fbd3c4bf0ea604f9ab30aa21f28fb26b953f8889
prerequisite-patch-id: d51e789c6ddc37cb65b6e49aaf567ba2a6168841
prerequisite-patch-id: 1e05b33595d37f01087a82f11344b0e3cca2580a
prerequisite-patch-id: 64151f1e9a5ae900c09322ef2bade0e1dad06568
prerequisite-patch-id: af71a3e75f28e0ee92721491b27f260500567d92
prerequisite-patch-id: 30c6b42d4bd39703a865ee9ebce41d986a803ce4
prerequisite-patch-id: 15a26c36a233ee3f738faa4a666b4f9c8749494d
prerequisite-patch-id: 9733d60910fb3e14ba5caa2eecc97a8c50592d7d
prerequisite-patch-id: b7b484c19e966041b39b7e3f089e9fb407c0b641
prerequisite-patch-id: dd2adee5d7c941363193ad4033f419ca8f535b69
prerequisite-patch-id: 89142874b57f3120e4dcdefd7e40168766fc7f52
prerequisite-patch-id: df6983cc3366963afb6e4229cddd5b1a42406e3c
prerequisite-patch-id: 7d90d37f7e7545c5710ebdbd3db9967c1d1b5b4d
prerequisite-patch-id: 07041f82bdb5a5f886dd13a0a6a27b66d06d17c2
prerequisite-patch-id: 6086254edae9372a2a2a79521a9713c8d30e695c
prerequisite-patch-id: 6ad40b13b98391ed21da873bdf88c04f23ecb6fb
prerequisite-patch-id: 9fbbbc72209b81bc26573427ec70246eb2d04af1
prerequisite-patch-id: 5cc8743cf655d791faca7934683dd0d758151321
prerequisite-patch-id: 5bd8d06716d6cbae7a9fd904ff8713f3a5d0c8a0
prerequisite-patch-id: 2271226e9ac9ab8d8d93c7c3b2384c3c7bd84b87
prerequisite-patch-id: 19497288dc06ceb627a6eab0c75754a945eb1d71
prerequisite-patch-id: 85867a867694055295ce127a7ce1e9818d76801f
prerequisite-patch-id: 1b1d6aa8f4b96f82548917135d7747ed6e250fc7
prerequisite-patch-id: 39838eac42ec51ce7fb0951d4da3c64c801d71cf
prerequisite-patch-id: 846be3c76fbbca1890b3874e1fdb2af846d8f3e2
prerequisite-patch-id: 35af5ef849b3b4e207d9d9385580768c75c0827b
prerequisite-patch-id: b6aa080addba2ac4c851f41a01b72004e14fe7ca
prerequisite-patch-id: c4ba87ce6d1e48bddafb896f3c3d1fe514bf3b5c
prerequisite-patch-id: f8e4fec905fb4d6e000df3f17717f7b47d22ae27
prerequisite-patch-id: 8c0f82cdfb3c0995cdff96f9c6fc2971faf60a1e
prerequisite-patch-id: b89d16d373447225b2821d784b21331fb62e7a7c
prerequisite-patch-id: 1486fef342202199cb746fcf1601621ef07a02c4
prerequisite-patch-id: efad6151fb2cedb2cbe18d3873aa8a9b1ec4ee4f
prerequisite-patch-id: 7993a9682b498599a2fca2b7bc9c871c4bc3a374
prerequisite-patch-id: a4c31ca38e3009e9e0f15ec5531f0fa09d4929b8
prerequisite-patch-id: 3e3b4dccd7abc5c1de05d70aa397221d0a6e9c91
prerequisite-patch-id: 421ba703353af51b801fa948d862e6102b52ea9f
prerequisite-patch-id: c2ad0f1f0b00408b0068c2f8b235910fe19ce430
prerequisite-patch-id: 13a554c8d1b77415d2bf11ff260a8f932902f11c
prerequisite-patch-id: b00e4016272f55195941fedf49de1cb8f0b68dc4
prerequisite-patch-id: f89b24990377441eaf3f45d9b822ff699874af59
prerequisite-patch-id: 97d90df0f9d0499e5d3b4fd5ce37f3bb964c2370
prerequisite-patch-id: 45989d03b7508141fff2b99bee1ed9296841c3dd
prerequisite-patch-id: 77549a6ae8ce281254b876b05727983bb9b7560a
prerequisite-patch-id: 2ceee10179ceeef045bd54f0d0afa57b3e45a18a
prerequisite-patch-id: 28d94479

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

Am 24.11.20 um 12:54 schrieb Christian König:

Am 24.11.20 um 12:44 schrieb Thomas Zimmermann:

Am 24.11.20 um 12:30 schrieb Christian König:

Am 24.11.20 um 10:16 schrieb Thomas Zimmermann:

Hi Christian

Am 16.11.20 um 12:28 schrieb Christian König:

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:
In order to avoid eviction of vmap'ed buffers, pin them in their
GEM
object's vmap implementation. Unpin them in the vunmap
implementation.
This is needed to make generic fbdev support work reliably.
Without,
the buffer object could be evicted while fbdev flushed its
shadow buffer.

In difference to the PRIME pin/unpin functions, the vmap code
does not
modify the BOs prime_shared_count, so a vmap-pinned BO does not
count as

shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.

Ok in this case that should work.

If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into
the

BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.

The problem is what happens when it is prepared for scanout, but
can't be moved to VRAM because it is vmapped?

When the shadow is never scanned out that isn't a problem, but we
need to keep that in mind.

I'd like ask for your suggestions before sending an update for this
patch.

After the discussion about locking in fbdev, [1] I intended to
replace the pin call with code that acquires the reservation lock.

Yeah, that sounds like a good idea to me as well.

First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but then
wondered why ttm_bo_vmap() doe not acquire the lock internally? I'd
expect that vmap/vunmap are close together and do not overlap for
the same BO.

We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the
lock/unlock into it and I hope to replace the kmap/kunmap functions
with them in the near term.

Otherwise, acquiring the reservation lock would require another
ref-counting variable or per-driver code.

Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper as
you initially planned.

Given your example above, step one would acquire the lock, and step
two would also acquire the lock as part of the vmap implementation.
Wouldn't this fail (At least during unmap or unlock steps) ?

Oh, so you want to nest them? No, that is a rather bad no-go.

I don't want to nest/overlap them. My question was whether that would be
required. Apparently not.

While the console's BO is being set for scanout, it's protected from
movement via the pin/unpin implementation, right? The driver does not
acquire the resv lock for longer periods. I'm asking because this would
prevent any console-buffer updates while the console is being displayed.

You need to make sure that the lock is only taken from the FB path which
wants to vmap the object.

Why don't you lock the GEM object from the caller in the generic FB
implementation?

With the current blitter code, it breaks abstraction. if vmap/vunmap
hold the lock implicitly, things would be easier.

Sorry for the noob questions. I'm still trying to understand the
implications of acquiring these locks.

Best regards
Thomas

Regards,
Christian.

Best regards
Thomas

Regards,
Christian.

Best regards
Thomas

[1] https://patchwork.freedesktop.org/patch/401088/?series=83918&rev=1

Regards,
Christian.

For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432&data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3D&reserved=0

Regards,
Christian.

Signed-off-by: Thomas Zimmerman

[PATCH][next] drm/mcde: fix masking and bitwise-or on variable val

2020-11-24 Thread Colin King

From: Colin Ian King 

The masking of val with ~MCDE_CRX1_CLKSEL_MASK is currently being
ignored because there seems to be a missing bitwise-or of val in the
following statement.  Fix this by replacing the assignment of val
with a bitwise-or.

Addresses-Coverity: ("Unused valued")
Fixes: d795fd322063 ("drm/mcde: Support DPI output")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/mcde/mcde_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mcde/mcde_display.c 
b/drivers/gpu/drm/mcde/mcde_display.c
index d941026b940c..7c2e0b865441 100644
--- a/drivers/gpu/drm/mcde/mcde_display.c
+++ b/drivers/gpu/drm/mcde/mcde_display.c
@@ -738,7 +738,7 @@ static void mcde_configure_fifo(struct mcde *mcde, enum 
mcde_fifo fifo,
} else {
/* Use the MCDE clock for DSI */
val &= ~MCDE_CRX1_CLKSEL_MASK;
-   val = MCDE_CRX1_CLKSEL_MCDECLK << MCDE_CRX1_CLKSEL_SHIFT;
+   val |= MCDE_CRX1_CLKSEL_MCDECLK << MCDE_CRX1_CLKSEL_SHIFT;
}
writel(val, mcde->regs + cr1);
spin_unlock(&mcde->fifo_crx1_lock);
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed


Am 24.11.20 um 13:15 schrieb Thomas Zimmermann:

[SNIP]
First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but 
then wondered why ttm_bo_vmap() doe not acquire the lock 
internally? I'd expect that vmap/vunmap are close together and do 
not overlap for the same BO. 


We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with 
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the 
lock/unlock into it and I hope to replace the kmap/kunmap functions 
with them in the near term.


Otherwise, acquiring the reservation lock would require another 
ref-counting variable or per-driver code.


Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper 
as you initially planned.


Given your example above, step one would acquire the lock, and step 
two would also acquire the lock as part of the vmap implementation. 
Wouldn't this fail (At least during unmap or unlock steps) ?


Oh, so you want to nest them? No, that is a rather bad no-go.


I don't want to nest/overlap them. My question was whether that would 
be required. Apparently not.


While the console's BO is being set for scanout, it's protected from 
movement via the pin/unpin implementation, right?


Yes, correct.

The driver does not acquire the resv lock for longer periods. I'm 
asking because this would prevent any console-buffer updates while the 
console is being displayed.


Correct as well, we only hold the lock for things like command 
submission, pinning, unpinning etc etc






You need to make sure that the lock is only taken from the FB path 
which wants to vmap the object.


Why don't you lock the GEM object from the caller in the generic FB 
implementation?


With the current blitter code, it breaks abstraction. if vmap/vunmap 
hold the lock implicitly, things would be easier.


Do you have a link to the code?

Please note that the reservation lock you need to take here is part of 
the GEM object.


Usually we design things in the way that the code needs to take a lock 
which protects an object, then do some operations with the object and 
then release the lock again.


Having in the lock inside the operation can be done as well, but 
returning with it is kind of unusual design.


Sorry for the noob questions. I'm still trying to understand the 
implications of acquiring these locks.


Well this is the reservation lock of the GEM object we are talking about 
here. We need to take that for a couple of different operations, 
vmap/vunmap doesn't sound like a special case to me.


Regards,
Christian.



Best regards
Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

Am 24.11.20 um 14:36 schrieb Christian König:

Am 24.11.20 um 13:15 schrieb Thomas Zimmermann:

[SNIP]
First I wanted to put this into drm_gem_ttm_vmap/vunmap(), but
then wondered why ttm_bo_vmap() doe not acquire the lock
internally? I'd expect that vmap/vunmap are close together and do
not overlap for the same BO.

We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the
lock/unlock into it and I hope to replace the kmap/kunmap functions
with them in the near term.

Otherwise, acquiring the reservation lock would require another
ref-counting variable or per-driver code.

Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap() helper
as you initially planned.

Given your example above, step one would acquire the lock, and step
two would also acquire the lock as part of the vmap implementation.
Wouldn't this fail (At least during unmap or unlock steps) ?

Oh, so you want to nest them? No, that is a rather bad no-go.

I don't want to nest/overlap them. My question was whether that would
be required. Apparently not.

While the console's BO is being set for scanout, it's protected from
movement via the pin/unpin implementation, right?

Yes, correct.

The driver does not acquire the resv lock for longer periods. I'm
asking because this would prevent any console-buffer updates while the
console is being displayed.

Correct as well, we only hold the lock for things like command
submission, pinning, unpinning etc etc

Thanks for answering my questions.

You need to make sure that the lock is only taken from the FB path
which wants to vmap the object.

Why don't you lock the GEM object from the caller in the generic FB
implementation?

With the current blitter code, it breaks abstraction. if vmap/vunmap
hold the lock implicitly, things would be easier.

Do you have a link to the code?

It's the damage blitter in the fbdev code. [1] While it flushes the
shadow buffer into the BO, the BO has to be kept in place. I already
changed it to lock struct drm_fb_helper.lock, but I don't think this is
enough. TTM could still evict the BO concurrently.

There's no recursion taking place, so I guess the reservation lock could
be acquired/release in drm_client_buffer_vmap/vunmap(), or a separate
pair of DRM client functions could do the locking.

Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_fb_helper.c?id=ac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394

Please note that the reservation lock you need to take here is part of
the GEM object.

Usually we design things in the way that the code needs to take a lock
which protects an object, then do some operations with the object and
then release the lock again.

Having in the lock inside the operation can be done as well, but
returning with it is kind of unusual design.

Sorry for the noob questions. I'm still trying to understand the
implications of acquiring these locks.

Well this is the reservation lock of the GEM object we are talking about
here. We need to take that for a couple of different operations,
vmap/vunmap doesn't sound like a special case to me.

Regards,
Christian.

Best regards
Thomas

___
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_0x680DC11D530B7A23.asc
Description: application/pgp-keys

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 4/7] drm/radeon: Pin buffers while they are vmap'ed

Am 24.11.20 um 14:56 schrieb Thomas Zimmermann:

Am 24.11.20 um 14:36 schrieb Christian König:

Am 24.11.20 um 13:15 schrieb Thomas Zimmermann:

We have use cases like the following during command submission:

1. lock
2. map
3. copy parts of the BO content somewhere else or patch it with
additional information

4. unmap
5. submit BO to the hardware
6. add hardware fence to the BO to make sure it doesn't move
7. unlock

That use case won't be possible with vmap/vunmap if we move the
lock/unlock into it and I hope to replace the kmap/kunmap
functions with them in the near term.

Otherwise, acquiring the reservation lock would require another
ref-counting variable or per-driver code.

Hui, why that? Just put this into drm_gem_ttm_vmap/vunmap()
helper as you initially planned.

Given your example above, step one would acquire the lock, and
step two would also acquire the lock as part of the vmap
implementation. Wouldn't this fail (At least during unmap or
unlock steps) ?

Oh, so you want to nest them? No, that is a rather bad no-go.

I don't want to nest/overlap them. My question was whether that
would be required. Apparently not.

While the console's BO is being set for scanout, it's protected from
movement via the pin/unpin implementation, right?

Yes, correct.

The driver does not acquire the resv lock for longer periods. I'm
asking because this would prevent any console-buffer updates while
the console is being displayed.

Correct as well, we only hold the lock for things like command
submission, pinning, unpinning etc etc

Thanks for answering my questions.

You need to make sure that the lock is only taken from the FB path
which wants to vmap the object.

Why don't you lock the GEM object from the caller in the generic FB
implementation?

With the current blitter code, it breaks abstraction. if vmap/vunmap
hold the lock implicitly, things would be easier.

Do you have a link to the code?

It's the damage blitter in the fbdev code. [1] While it flushes the
shadow buffer into the BO, the BO has to be kept in place. I already
changed it to lock struct drm_fb_helper.lock, but I don't think this
is enough. TTM could still evict the BO concurrently.

Yeah, that's correct.

But I still don't fully understand the problem. You just need to change
the code like this:

mutex_lock(&fb_helper->lock);
dma_resv_lock(buffer->gem->resv, NULL);

ret = drm_client_buffer_vmap(buffer, &map);
if (ret)
goto out;

dst = map;
drm_fb_helper_damage_blit_real(fb_helper, clip, &dst);

drm_client_buffer_vunmap(buffer);

out:
dma_resv_unlock(buffer->gem->resv);
mutex_unlock(&fb_helper->lock);

You could abstract that in drm_client functions as well, but I don't
really see the value in that.

Regards,
Christian.

There's no recursion taking place, so I guess the reservation lock
could be acquired/release in drm_client_buffer_vmap/vunmap(), or a
separate pair of DRM client functions could do the locking.

Best regards
Thomas

[1]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_fb_helper.c?id=ac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394

Please note that the reservation lock you need to take here is part
of the GEM object.

Usually we design things in the way that the code needs to take a
lock which protects an object, then do some operations with the
object and then release the lock again.

Having in the lock inside the operation can be done as well, but
returning with it is kind of unusual design.

Sorry for the noob questions. I'm still trying to understand the
implications of acquiring these locks.

Well this is the reservation lock of the GEM object we are talking
about here. We need to take that for a couple of different
operations, vmap/vunmap doesn't sound like a special case to me.

Regards,
Christian.

Best regards
Thomas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

On Tue, Nov 24, 2020 at 02:56:51PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 24.11.20 um 14:36 schrieb Christian König:
> > Am 24.11.20 um 13:15 schrieb Thomas Zimmermann:
> > > [SNIP]
> > > > > > > First I wanted to put this into
> > > > > > > drm_gem_ttm_vmap/vunmap(), but then wondered why
> > > > > > > ttm_bo_vmap() doe not acquire the lock internally?
> > > > > > > I'd expect that vmap/vunmap are close together and
> > > > > > > do not overlap for the same BO.
> > > > > > 
> > > > > > We have use cases like the following during command submission:
> > > > > > 
> > > > > > 1. lock
> > > > > > 2. map
> > > > > > 3. copy parts of the BO content somewhere else or patch
> > > > > > it with additional information
> > > > > > 4. unmap
> > > > > > 5. submit BO to the hardware
> > > > > > 6. add hardware fence to the BO to make sure it doesn't move
> > > > > > 7. unlock
> > > > > > 
> > > > > > That use case won't be possible with vmap/vunmap if we
> > > > > > move the lock/unlock into it and I hope to replace the
> > > > > > kmap/kunmap functions with them in the near term.
> > > > > > 
> > > > > > > Otherwise, acquiring the reservation lock would
> > > > > > > require another ref-counting variable or per-driver
> > > > > > > code.
> > > > > > 
> > > > > > Hui, why that? Just put this into
> > > > > > drm_gem_ttm_vmap/vunmap() helper as you initially
> > > > > > planned.
> > > > > 
> > > > > Given your example above, step one would acquire the lock,
> > > > > and step two would also acquire the lock as part of the vmap
> > > > > implementation. Wouldn't this fail (At least during unmap or
> > > > > unlock steps) ?
> > > > 
> > > > Oh, so you want to nest them? No, that is a rather bad no-go.
> > > 
> > > I don't want to nest/overlap them. My question was whether that
> > > would be required. Apparently not.
> > > 
> > > While the console's BO is being set for scanout, it's protected from
> > > movement via the pin/unpin implementation, right?
> > 
> > Yes, correct.
> > 
> > > The driver does not acquire the resv lock for longer periods. I'm
> > > asking because this would prevent any console-buffer updates while
> > > the console is being displayed.
> > 
> > Correct as well, we only hold the lock for things like command
> > submission, pinning, unpinning etc etc
> > 
> 
> Thanks for answering my questions.
> 
> > > 
> > > > 
> > > > You need to make sure that the lock is only taken from the FB
> > > > path which wants to vmap the object.
> > > > 
> > > > Why don't you lock the GEM object from the caller in the generic
> > > > FB implementation?
> > > 
> > > With the current blitter code, it breaks abstraction. if vmap/vunmap
> > > hold the lock implicitly, things would be easier.
> > 
> > Do you have a link to the code?
> 
> It's the damage blitter in the fbdev code. [1] While it flushes the shadow
> buffer into the BO, the BO has to be kept in place. I already changed it to
> lock struct drm_fb_helper.lock, but I don't think this is enough. TTM could
> still evict the BO concurrently.

So I'm not sure this is actually a problem: ttm could try to concurrently
evict the buffer we pinned into vram, and then just skip to the next one.

Plus atm generic fbdev isn't used on any chip where we really care about
that last few mb of vram being useable for command submission (well atm
there's no driver using it).

Having the buffer pinned into system memory and trying to do a concurrent
modeset that tries to pull it in is the hard failure mode. And holding
fb_helper.lock fully prevents that.

So not really clear on what failure mode you're seeing here?

> There's no recursion taking place, so I guess the reservation lock could be
> acquired/release in drm_client_buffer_vmap/vunmap(), or a separate pair of
> DRM client functions could do the locking.

Given how this "do the right locking" is a can of worms (and I think it's
worse than what you dug out already) I think the fb_helper.lock hack is
perfectly good enough.

I'm also somewhat worried that starting to use dma_resv lock in generic
code, while many helpers/drivers still have their hand-rolled locking,
will make conversion over to dma_resv needlessly more complicated.
-Daniel

> 
> Best regards
> Thomas
> 
> [1] 
> https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/drm_fb_helper.c?id=ac60f3f3090115d21f028bffa2dcfb67f695c4f2#n394
> 
> > 
> > Please note that the reservation lock you need to take here is part of
> > the GEM object.
> > 
> > Usually we design things in the way that the code needs to take a lock
> > which protects an object, then do some operations with the object and
> > then release the lock again.
> > 
> > Having in the lock inside the operation can be done as well, but
> > returning with it is kind of unusual design.
> > 
> > > Sorry for the noob questions. I'm still trying to understand the
> > > implications of acquiring these locks.
> > 
> > Well this is the reservation lock of the GEM object we are talking about
> > here. We

Re: [PATCH v5 07/17] drm/i915/hdcp: Enable HDCP 1.4 stream encryption

2020-11-24 Thread Ramalingam C

On 2020-11-11 at 11:50:41 +0530, Anshuman Gupta wrote:
> Enable HDCP 1.4 DP MST stream encryption.
> 
> Enable stream encryption once encryption is enabled on
> the DP transport driving the link for each stream which
> has requested encryption.
> 
> Disable stream encryption for each stream that no longer
> requires encryption before disabling HDCP encryption on
> the link.
> 
> v2:
> - Added debug print for stream encryption.
> - Disable the hdcp on port after disabling last stream
>   encryption.
> v3:
> - Cosmetic change, removed the value less comment. [Uma]
> v4:
> - Split the Gen12 HDCP enablement patch. [Ram]
> - Add connector details in drm_err.
> 
> Cc: Ramalingam C 
> Reviewed-by: Uma Shankar 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 45 ---
>  1 file changed, 31 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 0322a83c151d..e12bd0ac9fb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -612,7 +612,12 @@ int intel_hdcp_auth_downstream(struct intel_connector 
> *connector)
>   return ret;
>  }
>  
> -/* Implements Part 1 of the HDCP authorization procedure */
> +/*
> + * Implements Part 1 of the HDCP authorization procedure.
> + * Authentication Part 1 steps for Multi-stream DisplayPort.
> + * Step 1. Auth Part 1 sequence on the driving MST Trasport Link.
> + * Step 2. Enable encryption for each stream that requires encryption.
> +1*/
IMO this function is generic for SST and MST. Why do we document only
for MST at the top of the function? We can remove them.
>  static int intel_hdcp_auth(struct intel_connector *connector)
>  {
>   struct intel_digital_port *dig_port = 
> intel_attached_dig_port(connector);
> @@ -766,10 +771,17 @@ static int intel_hdcp_auth(struct intel_connector 
> *connector)
>   return -ETIMEDOUT;
>   }
>  
> - /*
> -  * XXX: If we have MST-connected devices, we need to enable encryption
> -  * on those as well.
> -  */
> + /* DP MST Auth Part 1 Step 2.a and Step 2.b */
> + if (shim->stream_encryption) {
> + ret = shim->stream_encryption(connector, true);
> + if (ret) {
> + drm_err(&dev_priv->drm, "[CONNECTOR:%d:%s] Failed to 
> enable HDCP 1.4 stream enc\n",
All the existing error messgae has the %s:%d, why are we changing it
here? Could we retain the uniformity?
> + connector->base.base.id, connector->base.name);
> + return ret;
> + }
> + drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream 
> encrypted\n",
> + transcoder_name(hdcp->stream_transcoder));
> + }
>  
>   if (repeater_present)
>   return intel_hdcp_auth_downstream(connector);
> @@ -791,18 +803,23 @@ static int _intel_hdcp_disable(struct intel_connector 
> *connector)
>   drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
>   connector->base.name, connector->base.base.id);
>  
> + if (hdcp->shim->stream_encryption) {
> + ret = hdcp->shim->stream_encryption(connector, false);
> + if (ret) {
> + drm_err(&dev_priv->drm, "[CONNECTOR:%d:%s] Failed to 
> disable HDCP 1.4 stream enc\n",
same here. remove CONNECTOR ?
> + connector->base.base.id, connector->base.name);
> + return ret;
> + }
> + drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream 
> encryption disabled\n",
> + transcoder_name(hdcp->stream_transcoder));
> + }
> +
>   /*
> -  * If there are other connectors on this port using HDCP, don't disable
> -  * it. Instead, toggle the HDCP signalling off on that particular
> -  * connector/pipe and exit.
> +  * If there are other connectors on this port using HDCP, don't disable 
> it.
> +  * Repeat steps 1-2 for each stream that no longer requires encryption.
What is this steps 1-2 here!? Here you are not disabling if other
streams are encrpted. May be you want to put something like "Untill all
steams of MST stopped encrypting, dont disable the port encryption"

-Ram
>*/
> - if (dig_port->num_hdcp_streams > 0) {
> - ret = hdcp->shim->toggle_signalling(dig_port,
> - cpu_transcoder, false);
> - if (ret)
> - DRM_ERROR("Failed to disable HDCP signalling\n");
> + if (dig_port->num_hdcp_streams > 0)
>   return ret;
> - }
>  
>   hdcp->hdcp_encrypted = false;
>   intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
> -- 
> 2.26.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht

Re: [PATCH v6 09/17] media/videbuf1|2: Mark follow_pfn usage as unsafe

On Fri, Nov 20, 2020 at 09:23:12PM +0900, Tomasz Figa wrote:
> On Fri, Nov 20, 2020 at 9:08 PM Hans Verkuil  wrote:
> >
> > On 20/11/2020 11:51, Daniel Vetter wrote:
> > > On Fri, Nov 20, 2020 at 11:39 AM Hans Verkuil  wrote:
> > >>
> > >> On 20/11/2020 10:18, Daniel Vetter wrote:
> > >>> On Fri, Nov 20, 2020 at 9:28 AM Hans Verkuil  wrote:
> > 
> >  On 20/11/2020 09:06, Hans Verkuil wrote:
> > > On 19/11/2020 15:41, Daniel Vetter wrote:
> > >> The media model assumes that buffers are all preallocated, so that
> > >> when a media pipeline is running we never miss a deadline because the
> > >> buffers aren't allocated or available.
> > >>
> > >> This means we cannot fix the v4l follow_pfn usage through
> > >> mmu_notifier, without breaking how this all works. The only real fix
> > >> is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
> > >> tell everyone to cut over to dma-buf memory sharing for zerocopy.
> > >>
> > >> userptr for normal memory will keep working as-is, this only affects
> > >> the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
> > >> videobuf2-dma-sg: Support io userptr operations on io memory").
> > >>
> > >> Acked-by: Tomasz Figa 
> > >
> > > Acked-by: Hans Verkuil 
> > 
> >  Actually, cancel this Acked-by.
> > 
> >  So let me see if I understand this right: VM_IO | VM_PFNMAP mappings 
> >  can
> >  move around. There is a mmu_notifier that can be used to be notified 
> >  when
> >  that happens, but that can't be used with media buffers since those 
> >  buffers
> >  must always be available and in the same place.
> > 
> >  So follow_pfn is replaced by unsafe_follow_pfn to signal that what is 
> >  attempted
> >  is unsafe and unreliable.
> > 
> >  If CONFIG_STRICT_FOLLOW_PFN is set, then unsafe_follow_pfn will fail, 
> >  if it
> >  is unset, then it writes a warning to the kernel log but just 
> >  continues while
> >  still unsafe.
> > 
> >  I am very much inclined to just drop VM_IO | VM_PFNMAP support in the 
> >  media
> >  subsystem. For vb2 there is a working alternative in the form of 
> >  dmabuf, and
> >  frankly for vb1 I don't care. If someone really needs this for a vb1 
> >  driver,
> >  then they can do the work to convert that driver to vb2.
> > 
> >  I've added Mauro to the CC list and I'll ping a few more people to see 
> >  what
> >  they think, but in my opinion support for USERPTR + VM_IO | VM_PFNMAP
> >  should just be killed off.
> > 
> >  If others would like to keep it, then frame_vector.c needs a comment 
> >  before
> >  the 'while' explaining why the unsafe_follow_pfn is there and that 
> >  using
> >  dmabuf is the proper alternative to use. That will make it easier for
> >  developers to figure out why they see a kernel warning and what to do 
> >  to
> >  fix it, rather than having to dig through the git history for the 
> >  reason.
> > >>>
> > >>> I'm happy to add a comment, but otherwise if you all want to ditch
> > >>> this, can we do this as a follow up on top? There's quite a bit of
> > >>> code that can be deleted and I'd like to not hold up this patch set
> > >>> here on that - it's already a fairly sprawling pain touching about 7
> > >>> different subsystems (ok only 6-ish now since the s390 patch landed).
> > >>> For the comment, is the explanation next to unsafe_follow_pfn not good
> > >>> enough?
> > >>
> > >> No, because that doesn't mention that you should use dma-buf as a 
> > >> replacement.
> > >> That's really the critical piece of information I'd like to see. That 
> > >> doesn't
> > >> belong in unsafe_follow_pfn, it needs to be in frame_vector.c since it's
> > >> vb2 specific.
> > >
> > > Ah makes sense, I'll add that.
> > >
> > >>>
> > >>> So ... can I get you to un-cancel your ack?
> > >>
> > >> Hmm, I really would like to see support for this to be dropped 
> > >> completely.
> > >>
> > >> How about this: just replace follow_pfn() by -EINVAL instead of 
> > >> unsafe_follow_pfn().
> > >>
> > >> Add a TODO comment that this code now can be cleaned up a lot. Such a 
> > >> clean up patch
> > >> can be added on top later, and actually that is something that I can do 
> > >> once this
> > >> series has landed.
> > >>
> > >> Regardless, frame_vector.c should mention dma-buf as a replacement in a 
> > >> comment
> > >> since I don't want users who hit this issue to have to dig through git 
> > >> logs
> > >> to find that dma-buf is the right approach.
> > >>
> > >> BTW, nitpick: the subject line of this patch says 'videbuf' instead of 
> > >> 'videobuf'.
> > >
> > > Will fix to, and next round will have the additional -EINVAL on top.
> > > Iirc Mauro was pretty clear that we can't just delete this, so I kinda
> > > don't want to get stuck in this discussion with my patc

Re: [PATCH v5 08/17] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support

2020-11-24 Thread Ramalingam C

On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> Enable HDCP 1.4 over DP MST for Gen12.
> 
> Cc: Ramalingam C 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 16865b200062..f00e12fc83e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -826,13 +826,9 @@ static struct drm_connector 
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>   intel_attach_force_audio_property(connector);
>   intel_attach_broadcast_rgb_property(connector);
>  
> -
> - /* TODO: Figure out how to make HDCP work on GEN12+ */
> - if (INTEL_GEN(dev_priv) < 12) {
Just a thought, shouldn't we enable for the platforms that we have
tested HDCP? like <= 12. 

We could keep expanding the list supported.

Ram.
> - ret = intel_dp_init_hdcp(dig_port, intel_connector);
> - if (ret)
> - DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> - }
> + ret = intel_dp_init_hdcp(dig_port, intel_connector);
> + if (ret)
> + drm_dbg_kms(&dev_priv->drm, "HDCP init failed, skipping.\n");
>  
>   /*
>* Reuse the prop from the SST connector because we're
> -- 
> 2.26.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 17/17] RFC: mm: add mmu_notifier argument to follow_pfn

On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> > @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> >   * Return: zero and the pfn at @pfn on success, -ve otherwise.
> >   */
> >  int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> > -   unsigned long *pfn)
> > +   unsigned long *pfn, struct mmu_notifier *subscription)
> >  {
> > -   int ret = -EINVAL;
> > -   spinlock_t *ptl;
> > -   pte_t *ptep;
> > +   if (WARN_ON(!subscription->mm))
> > +   return -EINVAL;
> >  
> > +   if (WARN_ON(subscription->mm != vma->vm_mm))
> > +   return -EINVAL;
> 
> These two things are redundant right? vma->vm_mm != NULL?

Yup, will remove.

> BTW, why do we even have this for nommu? If the only caller is kvm,
> can you even compile kvm on nommu??

Kinda makes sense, but I have no idea how to make sure with compile
testing this is really the case. And I didn't see any hard evidence in
Kconfig or Makefile that mmu notifiers requires CONFIG_MMU. So not sure
what to do here.

Should I just remove the nommu version of follow_pfn and see what happens?
We can't remove it earlier since it's still used by other subsystems.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] mm: Extract might_alloc() debug check

On Fri, Nov 20, 2020 at 02:07:19PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 10:54:43AM +0100, Daniel Vetter wrote:
> > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> > index d5ece7a9a403..f94405d43fd1 100644
> > --- a/include/linux/sched/mm.h
> > +++ b/include/linux/sched/mm.h
> > @@ -180,6 +180,22 @@ static inline void fs_reclaim_acquire(gfp_t gfp_mask) 
> > { }
> >  static inline void fs_reclaim_release(gfp_t gfp_mask) { }
> >  #endif
> >  
> > +/**
> > + * might_alloc - Marks possible allocation sites
> > + * @gfp_mask: gfp_t flags that would be use to allocate
> > + *
> > + * Similar to might_sleep() and other annotations this can be used in 
> > functions
> > + * that might allocate, but often dont. Compiles to nothing without
> > + * CONFIG_LOCKDEP. Includes a conditional might_sleep() if @gfp allows 
> > blocking.
> > + */
> > +static inline void might_alloc(gfp_t gfp_mask)
> > +{
> > +   fs_reclaim_acquire(gfp_mask);
> > +   fs_reclaim_release(gfp_mask);
> > +
> > +   might_sleep_if(gfpflags_allow_blocking(gfp_mask));
> > +}
> 
> Reviewed-by: Jason Gunthorpe 
> 
> Oh, I just had a another thread with Matt about xarray, this would be
> perfect to add before xas_nomem():

Yeah I think there's plenty of places where this will be useful. Want to
slap a sob onto this diff so I can include it for the next round, or will
you or Matt send this out when my might_alloc has landed?
-Daniel

> 
> diff --git a/lib/idr.c b/lib/idr.c
> index f4ab4f4aa3c7f5..722d9ddff53221 100644
> --- a/lib/idr.c
> +++ b/lib/idr.c
> @@ -391,6 +391,8 @@ int ida_alloc_range(struct ida *ida, unsigned int min, 
> unsigned int max,
>   if ((int)max < 0)
>   max = INT_MAX;
>  
> + might_alloc(gfp);
> +
>  retry:
>   xas_lock_irqsave(&xas, flags);
>  next:
> diff --git a/lib/xarray.c b/lib/xarray.c
> index 5fa51614802ada..dd260ee7dcae9a 100644
> --- a/lib/xarray.c
> +++ b/lib/xarray.c
> @@ -1534,6 +1534,8 @@ void *__xa_store(struct xarray *xa, unsigned long 
> index, void *entry, gfp_t gfp)
>   XA_STATE(xas, xa, index);
>   void *curr;
>  
> + might_alloc(gfp);
> +
>   if (WARN_ON_ONCE(xa_is_advanced(entry)))
>   return XA_ERROR(-EINVAL);
>   if (xa_track_free(xa) && !entry)
> @@ -1600,6 +1602,8 @@ void *__xa_cmpxchg(struct xarray *xa, unsigned long 
> index,
>   XA_STATE(xas, xa, index);
>   void *curr;
>  
> + might_alloc(gfp);
> +
>   if (WARN_ON_ONCE(xa_is_advanced(entry)))
>   return XA_ERROR(-EINVAL);
>  
> @@ -1637,6 +1641,8 @@ int __xa_insert(struct xarray *xa, unsigned long index, 
> void *entry, gfp_t gfp)
>   XA_STATE(xas, xa, index);
>   void *curr;
>  
> + might_alloc(gfp);
> +
>   if (WARN_ON_ONCE(xa_is_advanced(entry)))
>   return -EINVAL;
>   if (!entry)
> @@ -1806,6 +1812,8 @@ int __xa_alloc(struct xarray *xa, u32 *id, void *entry,
>  {
>   XA_STATE(xas, xa, 0);
>  
> + might_alloc(gfp);
> +
>   if (WARN_ON_ONCE(xa_is_advanced(entry)))
>   return -EINVAL;
>   if (WARN_ON_ONCE(!xa_track_free(xa)))

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 084/141] drm/via: Fix fall-through warnings for Clang

On Sun, Nov 22, 2020 at 11:03:58PM +0100, Sam Ravnborg wrote:
> On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva 
> 
> Thanks, also applied to drm-misc-next.

Thank you, Sam.
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix kernel-doc warnings for SCALING_FILTER

On Fri, Nov 20, 2020 at 11:06:22AM +, Simon Ser wrote:
> This patch fixes the following kernel-doc warnings:
> 
> /home/simon/src/linux/Documentation/gpu/drm-kms:466: 
> ./drivers/gpu/drm/drm_crtc.c:236: WARNING: Unexpected indentation.
> /home/simon/src/linux/Documentation/gpu/drm-kms:466: 
> ./drivers/gpu/drm/drm_crtc.c:237: WARNING: Block quote ends without a blank 
> line; unexpected unindent.
> /home/simon/src/linux/Documentation/gpu/drm-kms:472: 
> ./drivers/gpu/drm/drm_blend.c:203: WARNING: Unexpected indentation.
> /home/simon/src/linux/Documentation/gpu/drm-kms:472: 
> ./drivers/gpu/drm/drm_blend.c:204: WARNING: Block quote ends without a blank 
> line; unexpected unindent.
> 
> Signed-off-by: Simon Ser 
> Fixes: 5c759eda9b04 ("drm: Introduce plane and CRTC scaling filter 
> properties")
> Cc: Pankaj Bharadiya 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Cc: Uma Shankar 
> Cc: Daniel Vetter 

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_blend.c |  2 +-
>  drivers/gpu/drm/drm_crtc.c  | 12 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index ae2234aae93d..5c2141e9a9f4 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -196,10 +196,10 @@
>   * exposed and assumed to be black).
>   *
>   * SCALING_FILTER:
> - *
>   * Indicates scaling filter to be used for plane scaler
>   *
>   * The value of this property can be one of the following:
> + *
>   * Default:
>   * Driver's default scaling filter
>   * Nearest Neighbor:
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f927976eca50..74090fc3aa55 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -230,14 +230,14 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc 
> *crtc)
>   *
>   *   Setting MODE_ID to 0 will release reserved resources for the CRTC.
>   * SCALING_FILTER:
> - *   Atomic property for setting the scaling filter for CRTC scaler
> + *   Atomic property for setting the scaling filter for CRTC scaler
>   *
> - *   The value of this property can be one of the following:
> - *   Default:
> - *   Driver's default scaling filter
> - *   Nearest Neighbor:
> - *   Nearest Neighbor scaling filter
> + *   The value of this property can be one of the following:
>   *
> + *   Default:
> + *   Driver's default scaling filter
> + *   Nearest Neighbor:
> + *   Nearest Neighbor scaling filter
>   */
>  
>  /**
> -- 
> 2.29.2
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] drm/vkms: Failure when using drmGetConnectorCurrent()

On Fri, Nov 20, 2020 at 01:19:04PM -0300, Leandro Ribeiro wrote:
> Hello,
> 
> We have a patch in Weston to replace drmGetConnector() calls with
> drmGetConnectorCurrent():
> 
> https://gitlab.freedesktop.org/wayland/weston/-/issues/437
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518
> 
> Unfortunately this is not working when we use VKMS (upstream version
> tested). Please see
> 
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518#note_700345

I guess this is without fbdev configured on vkms? That's what usually
papers over this problem for most drivers.

> for more information, and feel free to jump into the discussion. If there's
> more helpful information that I can share, please let me know.

Like Simon suggested, please submit that patch you have for discussion.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 134/141] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang

Hi Sam,

On Sun, Nov 22, 2020 at 11:05:40PM +0100, Sam Ravnborg wrote:
> Hi Gustavo,
> On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> > by explicitly adding a break statement instead of letting the code fall
> > through to the next case.
> > 
> > Link: https://github.com/KSPP/linux/issues/115
> > Signed-off-by: Gustavo A. R. Silva 
> 
> Thanks, applied this and the following patch to drm-misc-next.
> Looks forward to have this warning enabled.
> 
> One can only wonder how many hours will be saved by lettting the
> compiler tell you a break is missing. This is the kind of bugs you can
> stare you blind at.

Absolutely. We'll never know how many bugs this will catch in the
future decades of kernel development, before the code is even
committed/submitted. :)

Thanks!
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 02/12] drm: Unamp the entire device address space on device unplug

On Sat, Nov 21, 2020 at 03:16:15PM +0100, Christian König wrote:
> Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
> > Invalidate all BOs CPU mappings once device is removed.
> > 
> > v3: Move the code from TTM into drm_dev_unplug
> > 
> > Signed-off-by: Andrey Grodzovsky 
> 
> Reviewed-by: Christian König 

Was wondering for a moment whether this should be in drm_dev_unregister
instead, but then it's only one part of the coin really. So

Reviewed-by: Daniel Vetter 

> 
> > ---
> >   drivers/gpu/drm/drm_drv.c | 3 +++
> >   1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 13068fd..d550fd5 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -479,6 +479,9 @@ void drm_dev_unplug(struct drm_device *dev)
> > synchronize_srcu(&drm_unplug_srcu);
> > drm_dev_unregister(dev);
> > +
> > +   /* Clear all CPU mappings pointing to this device */
> > +   unmap_mapping_range(dev->anon_inode->i_mapping, 0, 0, 1);
> >   }
> >   EXPORT_SYMBOL(drm_dev_unplug);
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Mon, Nov 23, 2020 at 04:03:45PM -0400, Jason Gunthorpe wrote:
> On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> 
> >   IB/hfi1: Fix fall-through warnings for Clang
> >   IB/mlx4: Fix fall-through warnings for Clang
> >   IB/qedr: Fix fall-through warnings for Clang
> >   RDMA/mlx5: Fix fall-through warnings for Clang
> 
> I picked these four to the rdma tree, thanks

Awesome. :)

Thank you, Jason.
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Mon, Nov 23, 2020 at 08:38:46PM +, Mark Brown wrote:
> On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> > This series aims to fix almost all remaining fall-through warnings in
> > order to enable -Wimplicit-fallthrough for Clang.
> > 
> > In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> > add multiple break/goto/return/fallthrough statements instead of just
> > letting the code fall through to the next case.
> > 
> > [...]
> 
> Applied to
> 
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> for-next
> 
> Thanks!
> 
> [1/1] regulator: as3722: Fix fall-through warnings for Clang
>   commit: b52b417ccac4fae5b1f2ec4f1d46eb91e4493dc5

Thank you, Mark.
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 10/12] drm/amdgpu: Avoid sysfs dirs removal post device unplug

On Sat, Nov 21, 2020 at 12:21:20AM -0500, Andrey Grodzovsky wrote:
> Avoids NULL ptr due to kobj->sd being unset on device removal.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c   | 4 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index caf828a..812e592 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "amdgpu.h"
>  #include "amdgpu_ras.h"
> @@ -1043,7 +1044,8 @@ static int amdgpu_ras_sysfs_remove_feature_node(struct 
> amdgpu_device *adev)
>   .attrs = attrs,
>   };
>  
> - sysfs_remove_group(&adev->dev->kobj, &group);
> + if (!drm_dev_is_unplugged(&adev->ddev))
> + sysfs_remove_group(&adev->dev->kobj, &group);

This looks wrong. sysfs, like any other interface, should be
unconditionally thrown out when we do the drm_dev_unregister. Whether
hotunplugged or not should matter at all. Either this isn't needed at all,
or something is wrong with the ordering here. But definitely fishy.
-Daniel

>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> index 2b7c90b..54331fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "amdgpu.h"
>  #include "amdgpu_ucode.h"
> @@ -464,7 +465,8 @@ int amdgpu_ucode_sysfs_init(struct amdgpu_device *adev)
>  
>  void amdgpu_ucode_sysfs_fini(struct amdgpu_device *adev)
>  {
> - sysfs_remove_group(&adev->dev->kobj, &fw_attr_group);
> + if (!drm_dev_is_unplugged(&adev->ddev))
> + sysfs_remove_group(&adev->dev->kobj, &fw_attr_group);
>  }
>  
>  static int amdgpu_ucode_init_single_fw(struct amdgpu_device *adev,
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 08/12] drm/amdgpu: Split amdgpu_device_fini into early and late

On Sat, Nov 21, 2020 at 12:21:18AM -0500, Andrey Grodzovsky wrote:
> Some of the stuff in amdgpu_device_fini such as HW interrupts
> disable and pending fences finilization must be done right away on
> pci_remove while most of the stuff which relates to finilizing and
> releasing driver data structures can be kept until
> drm_driver.release hook is called, i.e. when the last device
> reference is dropped.
> 

Uh fini_late and fini_early are rathare meaningless namings, since no
clear why there's a split. If you used drm_connector_funcs as inspiration,
that's kinda not good because 'register' itself is a reserved keyword.
That's why we had to add late_ prefix, could as well have used
C_sucks_ as prefix :-) And then the early_unregister for consistency.

I think fini_hw and fini_sw (or maybe fini_drm) would be a lot clearer
about what they're doing.

I still strongly recommend that you cut over as much as possible of the
fini_hw work to devm_ and for the fini_sw/drm stuff there's drmm_
-Daniel

> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  7 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 15 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 24 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 12 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  3 ++-
>  9 files changed, 65 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 83ac06a..6243f6d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1063,7 +1063,9 @@ static inline struct amdgpu_device 
> *amdgpu_ttm_adev(struct ttm_bo_device *bdev)
>  
>  int amdgpu_device_init(struct amdgpu_device *adev,
>  uint32_t flags);
> -void amdgpu_device_fini(struct amdgpu_device *adev);
> +void amdgpu_device_fini_early(struct amdgpu_device *adev);
> +void amdgpu_device_fini_late(struct amdgpu_device *adev);
> +
>  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
>  
>  void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
> @@ -1275,6 +1277,8 @@ void amdgpu_driver_lastclose_kms(struct drm_device 
> *dev);
>  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
> *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> +void amdgpu_driver_release_kms(struct drm_device *dev);
> +
>  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
>  int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
>  int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 2f60b70..797d94d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3557,14 +3557,12 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   * Tear down the driver info (all asics).
>   * Called at driver shutdown.
>   */
> -void amdgpu_device_fini(struct amdgpu_device *adev)
> +void amdgpu_device_fini_early(struct amdgpu_device *adev)
>  {
>   dev_info(adev->dev, "amdgpu: finishing device.\n");
>   flush_delayed_work(&adev->delayed_init_work);
>   adev->shutdown = true;
>  
> - kfree(adev->pci_state);
> -
>   /* make sure IB test finished before entering exclusive mode
>* to avoid preemption on IB test
>* */
> @@ -3581,11 +3579,18 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   else
>   drm_atomic_helper_shutdown(adev_to_drm(adev));
>   }
> - amdgpu_fence_driver_fini(adev);
> + amdgpu_fence_driver_fini_early(adev);
>   if (adev->pm_sysfs_en)
>   amdgpu_pm_sysfs_fini(adev);
>   amdgpu_fbdev_fini(adev);
> +
> + amdgpu_irq_fini_early(adev);
> +}
> +
> +void amdgpu_device_fini_late(struct amdgpu_device *adev)
> +{
>   amdgpu_device_ip_fini(adev);
> + amdgpu_fence_driver_fini_late(adev);
>   release_firmware(adev->firmware.gpu_info_fw);
>   adev->firmware.gpu_info_fw = NULL;
>   adev->accel_working = false;
> @@ -3621,6 +3626,9 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   amdgpu_pmu_fini(adev);
>   if (adev->mman.discovery_bin)
>   amdgpu_discovery_fini(adev);
> +
> + kfree(adev->pci_state);
> +
>  }
>  
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 7f98cf1..3d130fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1244,14 +1244,10 @@ amdgpu_

[Bug 205675] Display locks up. AMDGPU timeout

2020-11-24 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=205675

srwretryt (wihejo6...@bcpfm.com) changed:

   What|Removed |Added

 CC||wihejo6...@bcpfm.com

--- Comment #37 from srwretryt (wihejo6...@bcpfm.com) ---
https://medium.com/@kareem.bijan/chelsea-vs-stade-rennes-free-livestream-tv-channel-b6c5ce442e0f
https://medium.com/@kareem.bijan/soccer-live-chelsea-vs-stade-rennes-livestream-chelsea-vs-stade-rennes-soccer-live-2020-104e59348509
https://paiza.io/projects/yqgKm2hseRY0x0y4D58Y1A?language=php
https://blog.goo.ne.jp/swrwretryty/e/08afcd06ce04868b7664737178cf6a93
https://note.com/sernsertrytuy/n/n3f5ea9fb3019
https://caribbeanfever.com/photo/albums/watch-stade-rennes-vs-chelsea-live-stream-free-2020
https://www.postads.ph/ad/chelsea-vs-stade-rennes-live-stream-free-ucl-online

-- 
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 v5 08/17] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support

2020-11-24 Thread Anshuman Gupta

On 2020-11-24 at 19:50:17 +0530, Ramalingam C wrote:
> On 2020-11-11 at 11:50:42 +0530, Anshuman Gupta wrote:
> > Enable HDCP 1.4 over DP MST for Gen12.
> > 
> > Cc: Ramalingam C 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 16865b200062..f00e12fc83e8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -826,13 +826,9 @@ static struct drm_connector 
> > *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
> > intel_attach_force_audio_property(connector);
> > intel_attach_broadcast_rgb_property(connector);
> >  
> > -
> > -   /* TODO: Figure out how to make HDCP work on GEN12+ */
> > -   if (INTEL_GEN(dev_priv) < 12) {
> Just a thought, shouldn't we enable for the platforms that we have
> tested HDCP? like <= 12. 
> 
> We could keep expanding the list supported.
thanks for comment, i will keep this as if (INTEL_GEN(dev_priv) < 12)
Thanks,
Anshuman
> 
> Ram.
> > -   ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > -   if (ret)
> > -   DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> > -   }
> > +   ret = intel_dp_init_hdcp(dig_port, intel_connector);
> > +   if (ret)
> > +   drm_dbg_kms(&dev_priv->drm, "HDCP init failed, skipping.\n");
> >  
> > /*
> >  * Reuse the prop from the SST connector because we're
> > -- 
> > 2.26.2
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH rdma-core 3/5] pyverbs: Add dma-buf based MR support