Re: [RFC PATCH v3 5/5] drm/panel: simple: add panel-dpi support
On Sun, Feb 16, 2020 at 07:15:13PM +0100, Sam Ravnborg wrote: > RFC only - not tested yet! > > The panel-dpi compatible is a fallback that > allows the DT to specify the timing. > > When matching panel-dpi expect the device tree to include the > timing information for the display-panel. > > Background for this change: > There are a lot of panels and new models hits the market very often. > It is a lost cause trying to chase them all and users of new panels > will often find them in situations that the panel they ues are not > supported by the kernel. > On top of this a lot of panels are customized based on customer > specifications. > > Including the panel timing in the device tree allows for a simple > way to describe the actual HW and use this description in a generic > way in the kernel. > This allows uses of proprietary panels, or panels which are not > included in the kernel, to specify the timing in the device tree > together with all the other HW descriptions. > And thus, using the device tree it is then easy to add support > for an otherwise unknown panel. > > The current support expect panels that do not require any > delays for prepare/enable/disable/unprepare. > > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Laurent Pinchart > Cc: Maxime Ripard > Cc: Oleksandr Suvorov I submitted a similar patch a year ago: https://lists.freedesktop.org/archives/dri-devel/2019-March/209682.html So I'm all for it :) Regardless of the outcome of this discussion, for all the patches: Acked-by: Maxime Ripard Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 30e32adc1fc6..b7c3fb2bfb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
radeon_device *rdev, u64 size
extern void radeon_program_register_sequence(struct radeon_device *rdev,
const u32 *registers,
const u32 array_size);
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
/*
* vm
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index d23f2ed4126e..4d37571c7ff5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo *bo)
*/
static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
{
- return bo->tbo.offset;
+ struct radeon_device *rdev;
+ u64 start = 0;
+
+ rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ switch(bo->tbo.mem.mem_type) {
+ case TTM_PL_TT:
+ start = rdev->mc.gtt_start;
+ break;
+ case TTM_PL_VRAM:
+ start = rdev->mc.vram_start;
+ break;
+ }
+
+ return (bo->tbo.mem.start << PAGE_SHIFT) + start;
}
static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index badf1b6d1549..1c8303468e8f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,7 +56,7 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
-static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
struct radeon_device *rdev;
@@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.gtt_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/6] do not store GPU address in TTM
With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. I tested this patch series on qxl, bochs and amdgpu. Christian tested it on radeon HW. It would be nice if someone test this for nouveau and vmgfx. Nirmoy Das (7): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset drm/qxl: don't use ttm bo->offset drm/bochs: don't use ttm bo->offset drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 29 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 3 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c| 1 + drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ drivers/gpu/drm/qxl/qxl_drv.h | 5 ++-- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h| 5 drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 +++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c| 7 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h| 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 35 files changed, 100 insertions(+), 75 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20
Hi Andrey,
On Fri, Feb 14, 2020 at 11:32:31PM +0200, Andrey Lebedev wrote:
> On Fri, Feb 14, 2020 at 09:53:51AM +0100, Maxime Ripard wrote:
> > On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> > > On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > > > This will create a spurious warning message for TCON1, since we
> > > > > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > > > > reset line, so we need to make it finer grained.
> > > > >
> > > > > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > > > > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > > > > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > > > > can be confusing to someone.
> > > > >
> > > > > I'd need some pointers on how to deal with that though (if we want to
> > > > > do
> > > > > it in this scope).
> > > >
> > > > Like I was mentionning, you could introduce a new compatible for each
> > > > TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
> > >
> > > Can you give me an idea how that compatible might look like?
> > >
> > > tcon0: lcd-controller@1c0c000 {
> > > compatible = "allwinner,sun7i-a20-tcon",
> > > "allwinner,lvds";
> > >
> > > or
> > >
> > > tcon0: lcd-controller@1c0c000 {
> > > compatible = "allwinner,sun7i-a20-tcon",
> > > "allwinner,tcon0";
> > >
> > > ? Or something completely different?
> >
> > Something like
> >
> > {
> > compatible = "allwinner,sun7i-a20-tcon0", "allwinner,sun7i-a20-tcon";
> > };
> >
> > {
> > compatible = "allwinner,sun7i-a20-tcon1", "allwinner,sun7i-a20-tcon";
> > };
> >
>
> Hi Maxime, here is what I came up with, please take a look. If the
> approach is right, I'll split it up and include into the patch set.
>
> From f3e45c958a9551a52ac26435785bdb572e54d8db Mon Sep 17 00:00:00 2001
> From: Andrey Lebedev
> Date: Fri, 14 Feb 2020 23:21:59 +0200
> Subject: [PATCH] Mark tcon0 to be the only tcon capable of LVDS on sun7i-a20
>
> This allows to avoid warnings about reset line not provided for tcon1.
>
> Signed-off-by: Andrey Lebedev
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 3b3c366a2bee..bab59fc4d9b1 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -405,7 +405,7 @@
> };
>
> tcon0: lcd-controller@1c0c000 {
> - compatible = "allwinner,sun7i-a20-tcon";
> + compatible = "allwinner,sun7i-a20-tcon0",
> "allwinner,sun7i-a20-tcon";
That's correct
> reg = <0x01c0c000 0x1000>;
> interrupts = ;
> resets = < RST_TCON0>, < RST_LVDS>;
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 800a9bd86112..cb2040aec436 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1107,6 +1107,25 @@ static struct sunxi_engine
> *sun4i_tcon_find_engine(struct sun4i_drv *drv,
> return sun4i_tcon_find_engine_traverse(drv, node, 0);
> }
>
> +/*
> + * Check if given tcon supports LVDS
> + *
> + * Some of the sunxi SoC variants contain several timing controllers, but
> only
> + * one of them can be used to drive LVDS screen. In this case such tcon is
> + * identified in respective quirks struct: lvds_compatible_tcon property will
> + * hold "compatible" string of the tcon, that supports LVDS.
> + *
> + * If lvds_compatible_tcon is not set, all tcons are considered capable of
> + * driving LVDS.
> + */
> +static bool sun4i_tcon_lvds_compat(struct device *dev, struct sun4i_tcon
> *tcon)
> +{
> + if (tcon->quirks->lvds_compatible_tcon == NULL)
> + return true;
> + return of_device_is_compatible(dev->of_node,
> +tcon->quirks->lvds_compatible_tcon);
> +}
> +
> static int sun4i_tcon_bind(struct device *dev, struct device *master,
> void *data)
> {
> @@ -1161,7 +1180,7 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> return ret;
> }
>
> - if (tcon->quirks->supports_lvds) {
> + if (tcon->quirks->supports_lvds && sun4i_tcon_lvds_compat(dev, tcon)) {
> /*
>* This can only be made optional since we've had DT
>* nodes without the LVDS reset properties.
> @@ -1481,6 +1500,7 @@ static const struct sun4i_tcon_quirks sun6i_a31s_quirks
> = {
>
> static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> .supports_lvds = true,
> + .lvds_compatible_tcon = "allwinner,sun7i-a20-tcon0",
>
[PATCH 8/8] drm/ttm: do not keep GPU dependent addresses
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 151edfd8de77..d5885cd609a3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -85,7 +85,6 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev,
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
- drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
drm_printf(p, "size: %llu\n", man->size);
drm_printf(p, "available_caching: 0x%08X\n",
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
@@ -345,12 +344,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
moved:
bo->evicted = false;
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index b9bc1b00142e..d6f39ee5bf5d 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -213,8 +213,6 @@ struct ttm_buffer_object {
* either of these locks held.
*/
- uint64_t offset; /* GPU address space is independent of CPU word size */
-
struct sg_table *sg;
};
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd09f4b2..c8ce6c181abe 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -177,7 +177,6 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
- uint64_t gpu_offset; /* GPU address space is independent of CPU word
size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..04e78f783638 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -917,7 +917,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
bo->pin_count++;
if (max_offset != 0) {
- u64 domain_start =
bo->tbo.bdev->man[mem_type].gpu_offset;
+ u64 domain_start = amdgpu_ttm_domain_start(adev,
mem_type);
WARN_ON_ONCE(max_offset <
(amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1445,7 +1445,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
- return amdgpu_gmc_sign_extend(bo->tbo.offset);
+ return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ uint64_t offset;
+
+offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+ return amdgpu_gmc_sign_extend(offset);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 36dec51d1ef1..1d86b4c7a1f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -279,6 +279,7 @@ void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence
*fence,
bool shared);
int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
int amdgpu_bo_validate(struct amdgpu_bo *bo);
int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 3ab46d4647e4..e329a108e760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -97,7 +97,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_TT:
/* GTT memory */
man->func = _gtt_mgr_func;
- man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -105,7 +104,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _vram_mgr_func;
- man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -116,7 +114,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -264,7 +261,7 @@ static uint64_t amdgpu_mm_node_addr(struct
ttm_buffer_object *bo,
if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
addr = mm_node->start << PAGE_SHIFT;
- addr += bo->bdev->man[mem->mem_type].gpu_offset;
+ addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev),
mem->mem_type);
}
return addr;
}
@@ -751,6 +748,27 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct
ttm_buffer_object *bo,
(offset >> PAGE_SHIFT);
}
+/**
+ * amdgpu_ttm_domain_start - Returns GPU start address
+ * @adev: amdgpu device object
+ * @type: type of the memory
+
[PATCH 7/7] drm/ttm: do not keep GPU dependent addresses
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 151edfd8de77..d5885cd609a3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -85,7 +85,6 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev,
struct drm_printer *p
drm_printf(p, "has_type: %d\n", man->has_type);
drm_printf(p, "use_type: %d\n", man->use_type);
drm_printf(p, "flags: 0x%08X\n", man->flags);
- drm_printf(p, "gpu_offset: 0x%08llX\n", man->gpu_offset);
drm_printf(p, "size: %llu\n", man->size);
drm_printf(p, "available_caching: 0x%08X\n",
man->available_caching);
drm_printf(p, "default_caching: 0x%08X\n", man->default_caching);
@@ -345,12 +344,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
moved:
bo->evicted = false;
- if (bo->mem.mm_node)
- bo->offset = (bo->mem.start << PAGE_SHIFT) +
- bdev->man[bo->mem.mem_type].gpu_offset;
- else
- bo->offset = 0;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index b9bc1b00142e..d6f39ee5bf5d 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -213,8 +213,6 @@ struct ttm_buffer_object {
* either of these locks held.
*/
- uint64_t offset; /* GPU address space is independent of CPU word size */
-
struct sg_table *sg;
};
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index c9e0fd09f4b2..c8ce6c181abe 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -177,7 +177,6 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
- uint64_t gpu_offset; /* GPU address space is independent of CPU word
size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property
On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote: > On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote: > > On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote: > > > On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote: > > > > SoCs that have multiple TCONs can use the two set of pins on the first > > > > TCON > > > > to drive a dual-link display. Add a property to enable the dual link. > > > > > > > > Signed-off-by: Maxime Ripard > > > > --- > > > > .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 +++ > > > > 1 file changed, 7 insertions(+) > > > > > > > > diff --git > > > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > > > > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > index 86ad617d2327..aa6dd8409dbc 100644 > > > > --- > > > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > +++ > > > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > @@ -105,6 +105,13 @@ properties: > > > > - const: edp > > > > - const: lvds > > > > > > > > + allwinner,lvds-dual-link: > > > > +type: boolean > > > > +description: | > > > > + On a SoC with two TCON with LVDS support, the first TCON can > > > > + operate over both pins sets to output in a dual-link setup. This > > > > + will be triggered by setting this property. > > > > > > Could you maybe provide an example of how this property is supposed to > > > be used ? I'm especially wondering what ports are used in that case and > > > how they're connected. > > > > It's pretty trivial to support, it's only a property to set on the > > encoder node itself. > > > > I'm not really sure what you meant by your question with the ports > > though :/ > > I assume that, in the single-link case, you have two TCON instances that > operate independently, each of them with one port that models an LVDS > connection to a panel. Indeed, > In the dual-link mode, how does that look like ? Does the TCON > instance that operate in dual-link mode have two ports in DT ? There > are two physical ports, so I think it makes sense to always have two > ports in DT. That's what we're doing for the LVDS encoders on R-Car > Gen3, in order to specify in DT which LVDS input of the dual-link > panel is connected to which LVDS output of the SoC. That allows > configuring the LVDS encoder to send the even and odd pixels on the > right port. As far as I can tell, you can't control that in our TCON. It just on more lanes, that's it. Also, we currently have multiple ports, to map another feature of the TCON, which is that it can drive directly a panel, or will send its output to the HDMI / TV encoders. Adding another port in that will break the current binding we have. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset
Switch over to GEM VRAM's implementation to retrieve bo->offset Signed-off-by: Nirmoy Das --- drivers/gpu/drm/bochs/bochs_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 8066d7d370d5..b8e1079f077e 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -38,7 +38,7 @@ static void bochs_plane_update(struct bochs_device *bochs, state->crtc_x, state->crtc_y, state->fb->pitches[0], -state->fb->offsets[0] + gbo->bo.offset); +state->fb->offsets[0] + drm_gem_vram_offset(gbo)); bochs_hw_setformat(bochs, state->fb->format); } -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] drm/qxl: don't use ttm bo->offset
This patch also removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c| 9 -
4 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 27e45a2d6b52..df581f0e6699 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -134,7 +134,6 @@ struct qxl_memslot {
uint64_tstart_phys_addr;
uint64_tsize;
uint64_thigh_bits;
- uint64_tgpu_offset;
};
enum {
@@ -311,10 +310,9 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? >main_slot : >surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
+ /* TODO - need to hold one of the locks to read bo->tbo.mem.start */
- /* TODO - need to hold one of the locks to read tbo.offset */
- return slot->high_bits | (bo->tbo.offset - slot->gpu_offset + offset);
+ return slot->high_bits | ((bo->tbo.mem.start << PAGE_SHIFT) + offset);
}
/* qxl_display.c */
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 70b20ee4741a..7a5bf544f34d 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -86,11 +86,10 @@ static void setup_slot(struct qxl_device *qdev,
high_bits <<= (64 - (qdev->rom->slot_gen_bits +
qdev->rom->slot_id_bits));
slot->high_bits = high_bits;
- DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx, gpu_offset 0x%lx\n",
+ DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx\n",
slot->index, slot->name,
(unsigned long)slot->start_phys_addr,
-(unsigned long)slot->size,
-(unsigned long)slot->gpu_offset);
+(unsigned long)slot->size);
}
void qxl_reinit_memslots(struct qxl_device *qdev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index 8ae54ba7857c..21fa81048f4f 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -48,11 +48,6 @@ static inline void qxl_bo_unreserve(struct qxl_bo *bo)
ttm_bo_unreserve(>tbo);
}
-static inline u64 qxl_bo_gpu_offset(struct qxl_bo *bo)
-{
- return bo->tbo.offset;
-}
-
static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
{
return bo->tbo.num_pages << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 62a5e424971b..635d000e7934 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -51,11 +51,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct qxl_device *qdev = qxl_get_qdev(bdev);
- unsigned int gpu_offset_shift =
- 64 - (qdev->rom->slot_gen_bits + qdev->rom->slot_id_bits + 8);
- struct qxl_memslot *slot;
-
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
@@ -66,11 +61,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
case TTM_PL_PRIV:
/* "On-card" video ram */
- slot = (type == TTM_PL_VRAM) ?
- >main_slot : >surfaces_slot;
- slot->gpu_offset = (uint64_t)type << gpu_offset_shift;
man->func = _bo_manager_func;
- man->gpu_offset = slot->gpu_offset;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/qxl: don't use ttm bo->offset
This patch also removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/qxl/qxl_drv.h| 5 ++---
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c| 9 -
4 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 27e45a2d6b52..58e7098a17ff 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -311,10 +311,9 @@ qxl_bo_physical_address(struct qxl_device *qdev, struct
qxl_bo *bo,
(bo->tbo.mem.mem_type == TTM_PL_VRAM)
? >main_slot : >surfaces_slot;
- WARN_ON_ONCE((bo->tbo.offset & slot->gpu_offset) != slot->gpu_offset);
+ /* TODO - need to hold one of the locks to read bo->tbo.mem.start */
- /* TODO - need to hold one of the locks to read tbo.offset */
- return slot->high_bits | (bo->tbo.offset - slot->gpu_offset + offset);
+ return slot->high_bits | ((bo->tbo.mem.start << PAGE_SHIFT) + offset);
}
/* qxl_display.c */
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 70b20ee4741a..7a5bf544f34d 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -86,11 +86,10 @@ static void setup_slot(struct qxl_device *qdev,
high_bits <<= (64 - (qdev->rom->slot_gen_bits +
qdev->rom->slot_id_bits));
slot->high_bits = high_bits;
- DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx, gpu_offset 0x%lx\n",
+ DRM_INFO("slot %d (%s): base 0x%08lx, size 0x%08lx\n",
slot->index, slot->name,
(unsigned long)slot->start_phys_addr,
-(unsigned long)slot->size,
-(unsigned long)slot->gpu_offset);
+(unsigned long)slot->size);
}
void qxl_reinit_memslots(struct qxl_device *qdev)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index 8ae54ba7857c..21fa81048f4f 100644
--- a/drivers/gpu/drm/qxl/qxl_object.h
+++ b/drivers/gpu/drm/qxl/qxl_object.h
@@ -48,11 +48,6 @@ static inline void qxl_bo_unreserve(struct qxl_bo *bo)
ttm_bo_unreserve(>tbo);
}
-static inline u64 qxl_bo_gpu_offset(struct qxl_bo *bo)
-{
- return bo->tbo.offset;
-}
-
static inline unsigned long qxl_bo_size(struct qxl_bo *bo)
{
return bo->tbo.num_pages << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 62a5e424971b..635d000e7934 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -51,11 +51,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct qxl_device *qdev = qxl_get_qdev(bdev);
- unsigned int gpu_offset_shift =
- 64 - (qdev->rom->slot_gen_bits + qdev->rom->slot_id_bits + 8);
- struct qxl_memslot *slot;
-
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
@@ -66,11 +61,7 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
case TTM_PL_PRIV:
/* "On-card" video ram */
- slot = (type == TTM_PL_VRAM) ?
- >main_slot : >surfaces_slot;
- slot->gpu_offset = (uint64_t)type << gpu_offset_shift;
man->func = _bo_manager_func;
- man->gpu_offset = slot->gpu_offset;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3] arm64: dts: sc7180: add nodes for idp display
Add nodes for IDP display. The display is Visionox RM69299.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Adding dependency patchwork series
- Removing suspend configuration
- Adding blank before space curly brace
Changes in v3:
- Updating status for mdp and mdss node to get the
display working
- Change in commit text
This patch depends on following patchwork series:
https://patchwork.kernel.org/patch/11364687/
https://patchwork.kernel.org/patch/11366303/
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 63 +
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 388f50ad4fde..349db8fe78a5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -7,6 +7,7 @@
/dts-v1/;
+#include
#include
#include "sc7180.dtsi"
#include "pm6150.dtsi"
@@ -232,6 +233,57 @@ vreg_bob: bob {
};
};
+ {
+ status = "okay";
+
+ vdda-supply = <_l3c_1p2>;
+
+ panel@0 {
+ compatible = "visionox,rm69299-1080p-display";
+ reg = <0>;
+
+ vdda-supply = <_l8c_1p8>;
+ vdd3p3-supply = <_l18a_2p8>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ reset-gpios = <_gpio 3 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
{
status = "okay";
pinctrl-names = "default";
@@ -289,6 +341,17 @@ _1_qmpphy {
/* PINCTRL - additions to nodes defined in sc7180.dtsi */
+_gpio {
+ disp_pins: disp-pins {
+ pins = "gpio3";
+ function = "func1";
+ qcom,drive-strength = <2>;
+ power-source = <0>;
+ bias-disable;
+ output-low;
+ };
+};
+
_clk {
pinconf {
pins = "gpio63";
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drm/vram-helper: don't use ttm bo->offset
Calculate GPU offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..e7ef4cd8116d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return gbo->bo.mem.start << PAGE_SHIFT;
}
EXPORT_SYMBOL(drm_gem_vram_offset);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] drm/nouveau: don't use ttm bo->offset
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Christian König
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 * i,
fb->pitches[0]);
nvif_wr32(dev,
Re: [Freedreno] [v1] drm/msm/dsi/pll: call vco set rate explicitly
On 2020-02-12 10:40, Rob Clark wrote: On Tue, Feb 11, 2020 at 8:05 PM Jeffrey Hugo wrote: On Tue, Feb 11, 2020 at 5:28 PM Rob Clark wrote: > > On Tue, Feb 11, 2020 at 7:59 AM Jeffrey Hugo wrote: > > > > On Tue, Feb 11, 2020 at 8:44 AM Rob Clark wrote: > > > > > > On Mon, Feb 10, 2020 at 9:58 PM wrote: > > > > > > > > On 2020-02-07 19:40, Jeffrey Hugo wrote: > > > > > On Fri, Feb 7, 2020 at 5:38 AM wrote: > > > > >> > > > > >> On 2020-02-06 20:29, Jeffrey Hugo wrote: > > > > >> > On Thu, Feb 6, 2020 at 2:13 AM Harigovindan P > > > > >> > wrote: > > > > >> >> > > > > >> >> For a given byte clock, if VCO recalc value is exactly same as > > > > >> >> vco set rate value, vco_set_rate does not get called assuming > > > > >> >> VCO is already set to required value. But Due to GDSC toggle, > > > > >> >> VCO values are erased in the HW. To make sure VCO is programmed > > > > >> >> correctly, we forcefully call set_rate from vco_prepare. > > > > >> > > > > > >> > Is this specific to certain SoCs? I don't think I've observed this. > > > > >> > > > > >> As far as Qualcomm SOCs are concerned, since pll is analog and the > > > > >> value > > > > >> is directly read from hardware if we get recalc value same as set rate > > > > >> value, the vco_set_rate will not be invoked. We checked in our idp > > > > >> device which has the same SOC but it works there since the rates are > > > > >> different. > > > > > > > > > > This doesn't seem to be an answer to my question. What Qualcomm SoCs > > > > > does this issue apply to? Everything implementing the 10nm pll? One > > > > > specific SoC? I don't believe I've seen this on MSM8998, nor SDM845, > > > > > so I'm interested to know what is the actual impact here. I don't see > > > > > an "IDP" SoC in the IP catalog, so I really have no idea what you are > > > > > referring to. > > > > > > > > > > > > This is not 10nm specific. It is applicable for other nms also. > > > > Its specific to the frequency being set. If vco_recalc returns the same > > > > value as being set by vco_set_rate, > > > > vco_set_rate will not be invoked second time onwards. > > > > > > > > For example: Lets take below devices: > > > > > > > > Cheza is based on SDM845 which is 10nm only. > > > > Clk frequency:206016 > > > > dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=1236096000 > > > > dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 1236095947 > > > > > > > > Trogdor is based on sc7180 which is also 10nm. > > > > Clk frequency:69300 > > > > dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=166320 > > > > dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 166320 > > > > > > > > In same trogdor device, we slightly changed the clock frequency and the > > > > values actually differ which will not cause any issue. > > > > Clk frequency:69310 > > > > dsi_pll_10nm_vco_set_rate - DSI PLL0 rate=166344 > > > > dsi_pll_10nm_vco_recalc_rate - DSI PLL0 returning vco rate = 1663439941 > > > > > > > > > tbh, loosing state when power is off is kind of the behavior that I'd > > > expect. It kinda makes me wonder if things are not getting powered > > > off all the way on some SoCs? > > > > > > jhugo, are you worried that this patch will cause problems on other > > > users of the 10nm pll? > > > > Essentially yes. Conceptually it doesn't seem like this change should > > cause any harm, however - > > > > This sounds like we are trying to work around the clk framework, which > > seems wrong. It feels like we should be able to set a clk flag for > > this and make the framework deal with it. > > > > Also, this fix is 10nm specific, yet this issue affects all > > implementations? Seems like this should perhaps be in common code so > > that we don't need to play whack-a-mole by fixing every implementation > > piecemeal. > > > > Finally, the PLLs are notorious for not taking a configuration unless > > they are running. I admit, I haven't looked at this patch in detail > > to determine if that is the case here, but there doesn't seem to be > > any indication from the commit test or a comment that doing so is > > actually valid in all cases. > > I'm not obviously seeing a clk-provider flag for this.. although I > won't claim to be a clk expert so maybe I'm looking for the wrong > thing.. > > On a more practical level, I'd kinda like to get some sort of fix for > v5.6, as currently suspend/resume doesn't work (or at least the > display does not survive) on trogdor, which is a bit annoying. It > sounds a bit like cheza was just getting lucky (because of rate > rounding?) I'm not sure if it is the same situation on other sdm850 > devices (yoga c630) or sdm835 devices (are they using the 10mm pll as > well?). sdm835 is the first implementation of the 10nm PLL. Pretty much everything after (including sdm845/850) also uses the 10nm PLL. > I will confess to not really testing s/r on the yoga c630, > although maybe someone else has (Bjorn?). > > Possibly this should be pushed up to the clk
[PATCH v2 RESEND] drm/i915/gvt: make gvt oblivious of kvmgt data structures
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.
v2:
- rebased onto gvt-staging (no conflicts)
Signed-off-by: Julian Stecklina
Acked-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/gvt.h | 32 +---
drivers/gpu/drm/i915/gvt/kvmgt.c | 287 +++
2 files changed, 184 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 9fe9decc0d86..8cf292a8d6bd 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -196,31 +196,8 @@ struct intel_vgpu {
struct dentry *debugfs;
-#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
- struct {
- struct mdev_device *mdev;
- struct vfio_region *region;
- int num_regions;
- struct eventfd_ctx *intx_trigger;
- struct eventfd_ctx *msi_trigger;
-
- /*
-* Two caches are used to avoid mapping duplicated pages (eg.
-* scratch pages). This help to reduce dma setup overhead.
-*/
- struct rb_root gfn_cache;
- struct rb_root dma_addr_cache;
- unsigned long nr_cache_entries;
- struct mutex cache_lock;
-
- struct notifier_block iommu_notifier;
- struct notifier_block group_notifier;
- struct kvm *kvm;
- struct work_struct release_work;
- atomic_t released;
- struct vfio_device *vfio_device;
- } vdev;
-#endif
+ /* Hypervisor-specific device state. */
+ void *vdev;
struct list_head dmabuf_obj_list_head;
struct mutex dmabuf_lock;
@@ -229,6 +206,11 @@ struct intel_vgpu {
u32 scan_nonprivbb;
};
+static inline void *intel_vgpu_vdev(struct intel_vgpu *vgpu)
+{
+ return vgpu->vdev;
+}
+
/* validating GM healthy status*/
#define vgpu_is_vm_unhealthy(ret_val) \
(((ret_val) == -EBADRQC) || ((ret_val) == -EFAULT))
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 85e59c502ab5..9a435bc1a2f0 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -108,6 +108,36 @@ struct gvt_dma {
struct kref ref;
};
+struct kvmgt_vdev {
+ struct intel_vgpu *vgpu;
+ struct mdev_device *mdev;
+ struct vfio_region *region;
+ int num_regions;
+ struct eventfd_ctx *intx_trigger;
+ struct eventfd_ctx *msi_trigger;
+
+ /*
+* Two caches are used to avoid mapping duplicated pages (eg.
+* scratch pages). This help to reduce dma setup overhead.
+*/
+ struct rb_root gfn_cache;
+ struct rb_root dma_addr_cache;
+ unsigned long nr_cache_entries;
+ struct mutex cache_lock;
+
+ struct notifier_block iommu_notifier;
+ struct notifier_block group_notifier;
+ struct kvm *kvm;
+ struct work_struct release_work;
+ atomic_t released;
+ struct vfio_device *vfio_device;
+};
+
+static inline struct kvmgt_vdev *kvmgt_vdev(struct intel_vgpu *vgpu)
+{
+ return intel_vgpu_vdev(vgpu);
+}
+
static inline bool handle_valid(unsigned long handle)
{
return !!(handle & ~0xff);
@@ -129,7 +159,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
for (npage = 0; npage < total_pages; npage++) {
unsigned long cur_gfn = gfn + npage;
- ret = vfio_unpin_pages(mdev_dev(vgpu->vdev.mdev), _gfn, 1);
+ ret = vfio_unpin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev),
_gfn, 1);
WARN_ON(ret != 1);
}
}
@@ -152,7 +182,7 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
unsigned long gfn,
unsigned long cur_gfn = gfn + npage;
unsigned long pfn;
- ret = vfio_pin_pages(mdev_dev(vgpu->vdev.mdev), _gfn, 1,
+ ret = vfio_pin_pages(mdev_dev(kvmgt_vdev(vgpu)->mdev),
_gfn, 1,
IOMMU_READ | IOMMU_WRITE, );
if (ret != 1) {
gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx, ret
%d\n",
@@ -219,7 +249,7 @@ static void gvt_dma_unmap_page(struct intel_vgpu *vgpu,
unsigned long gfn,
static struct gvt_dma *__gvt_cache_find_dma_addr(struct intel_vgpu *vgpu,
dma_addr_t dma_addr)
{
- struct rb_node *node = vgpu->vdev.dma_addr_cache.rb_node;
+ struct rb_node *node = kvmgt_vdev(vgpu)->dma_addr_cache.rb_node;
struct gvt_dma *itr;
while (node) {
@@ -237,7 +267,7 @@ static struct gvt_dma *__gvt_cache_find_dma_addr(struct
intel_vgpu *vgpu,
static struct
[PATCH] GPU: DRM: VC4/V3D Replace wait_for macros in to remove use of msleep
The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
which is inappropriate due to its inaccuracy at low values (minimum
wait time is about 30ms on the Raspberry Pi).
This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more accurate waits.
Signed-off-by: James Hughes
---
drivers/gpu/drm/v3d/v3d_drv.h | 41 ++---
drivers/gpu/drm/vc4/vc4_drv.h | 43 +--
2 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 7b4f3b5a086e..069fefe16d28 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -267,27 +267,42 @@ struct v3d_csd_job {
};
/**
- * _wait_for - magic (register) wait macro
+ * __wait_for - magic wait macro
*
- * Does the right thing for modeset paths when run under kdgb or similar atomic
- * contexts. Note that it's important that we check the condition again after
- * having timed out, since the timeout could be due to preemption or similar
and
- * we've never had a chance to check the condition before the timeout.
+ * Macro to help avoid open coding check/wait/timeout patterns. Note that it's
+ * important that we check the condition again after having timed out, since
the
+ * timeout could be due to preemption or similar and we've never had a chance
to
+ * check the condition before the timeout.
*/
-#define wait_for(COND, MS) ({ \
- unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1; \
- int ret__ = 0; \
- while (!(COND)) { \
- if (time_after(jiffies, timeout__)) { \
- if (!(COND))\
- ret__ = -ETIMEDOUT; \
+#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \
+ const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \
+ long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \
+ int ret__; \
+ might_sleep(); \
+ for (;;) { \
+ const bool expired__ = ktime_after(ktime_get_raw(), end__); \
+ OP; \
+ /* Guarantee COND check prior to timeout */ \
+ barrier(); \
+ if (COND) { \
+ ret__ = 0; \
break; \
} \
- msleep(1); \
+ if (expired__) {\
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ usleep_range(wait__, wait__ * 2); \
+ if (wait__ < (Wmax))\
+ wait__ <<= 1; \
} \
ret__; \
})
+#define _wait_for(COND, US, Wmin, Wmax)__wait_for(, (COND), (US),
(Wmin), \
+ (Wmax))
+#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000)
+
static inline unsigned long nsecs_to_jiffies_timeout(const u64 n)
{
/* nsecs_to_jiffies64() does not guard against overflow */
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 7956f6ed9b6a..c59be5e1d52b 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -629,32 +629,41 @@ struct vc4_validated_shader_info {
};
/**
- * _wait_for - magic (register) wait macro
+ * __wait_for - magic wait macro
*
- * Does the right thing for modeset paths when run under kdgb or similar atomic
- * contexts. Note that it's important that we check the condition again after
- * having timed out, since the timeout could be due to preemption or similar
and
- * we've never had a chance to check the condition before the timeout.
+ * Macro to help avoid open coding check/wait/timeout patterns. Note that it's
+ * important that we check the condition again after having timed out, since
the
+ * timeout could be due to preemption or similar and we've never had a chance
to
+ * check the condition
[PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..04e78f783638 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -917,7 +917,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
bo->pin_count++;
if (max_offset != 0) {
- u64 domain_start =
bo->tbo.bdev->man[mem_type].gpu_offset;
+ u64 domain_start = amdgpu_ttm_domain_start(adev,
mem_type);
WARN_ON_ONCE(max_offset <
(amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1445,7 +1445,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
- return amdgpu_gmc_sign_extend(bo->tbo.offset);
+ return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ uint64_t offset;
+
+offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+ return amdgpu_gmc_sign_extend(offset);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 36dec51d1ef1..1d86b4c7a1f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -279,6 +279,7 @@ void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence
*fence,
bool shared);
int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
int amdgpu_bo_validate(struct amdgpu_bo *bo);
int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 3ab46d4647e4..e329a108e760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -97,7 +97,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_TT:
/* GTT memory */
man->func = _gtt_mgr_func;
- man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -105,7 +104,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _vram_mgr_func;
- man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -116,7 +114,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -264,7 +261,7 @@ static uint64_t amdgpu_mm_node_addr(struct
ttm_buffer_object *bo,
if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
addr = mm_node->start << PAGE_SHIFT;
- addr += bo->bdev->man[mem->mem_type].gpu_offset;
+ addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev),
mem->mem_type);
}
return addr;
}
@@ -751,6 +748,27 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct
ttm_buffer_object *bo,
(offset >> PAGE_SHIFT);
}
+/**
+ * amdgpu_ttm_domain_start - Returns GPU start address
+ * @adev: amdgpu device object
+
[PATCH 0/8] do not store GPU address in TTM
With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. I tested this patch series on qxl, bochs and amdgpu. Christian tested it on radeon HW. It would be nice if someone test this for nouveau and vmgfx. Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset drm/bochs: use drm_gem_vram_offset to get bo offset drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 29 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/bochs/bochs_kms.c | 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c| 1 + drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++ drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h| 5 drivers/gpu/drm/qxl/qxl_ttm.c | 9 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 +++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c| 7 - drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h| 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 35 files changed, 99 insertions(+), 76 deletions(-) -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..a714582bb61c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
ret = ttm_bo_validate(bo, , );
/* For some reason we didn't end up at the start of vram */
- WARN_ON(ret == 0 && bo->offset != 0);
+ WARN_ON(ret == 0 && (bo->mem.start << PAGE_SHIFT) != 0);
if (!ret)
vmw_bo_pin_reserved(buf, true);
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object
*bo,
{
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
- ptr->offset = bo->offset;
+ ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 73489a45decb..72c2cf4053df 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3313,7 +3313,7 @@ static void vmw_apply_relocations(struct vmw_sw_context
*sw_context)
bo = >vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- reloc->location->offset += bo->offset;
+ reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index e5252ef3812f..1cdc445b24c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -612,7 +612,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct
vmw_private *dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM) {
cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
- cmd->body.guestResult.offset = bo->offset;
+ cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..e7134aebeb81 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = _gmrid_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/bochs: don't use ttm bo->offset
Calculate GPU offset within bochs driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 8066d7d370d5..852ec7910d84 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -38,7 +38,8 @@ static void bochs_plane_update(struct bochs_device *bochs,
state->crtc_x,
state->crtc_y,
state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] +
+(gbo->bo.mem.start << PAGE_SHIFT));
bochs_hw_setformat(bochs, state->fb->format);
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..e7ef4cd8116d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return gbo->bo.mem.start << PAGE_SHIFT;
}
EXPORT_SYMBOL(drm_gem_vram_offset);
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/nouveau: don't use ttm bo->offset
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 * i,
fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_BUFF0_OFFSET + 4 * i,
[PATCH 2/8] drm/radeon: don't use ttm bo->offset
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 +---
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 30e32adc1fc6..b7c3fb2bfb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2828,6 +2828,7 @@ extern void radeon_ttm_set_active_vram_size(struct
radeon_device *rdev, u64 size
extern void radeon_program_register_sequence(struct radeon_device *rdev,
const u32 *registers,
const u32 array_size);
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev);
/*
* vm
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index d23f2ed4126e..4d37571c7ff5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -90,7 +90,21 @@ static inline void radeon_bo_unreserve(struct radeon_bo *bo)
*/
static inline u64 radeon_bo_gpu_offset(struct radeon_bo *bo)
{
- return bo->tbo.offset;
+ struct radeon_device *rdev;
+ u64 start = 0;
+
+ rdev = radeon_get_rdev(bo->tbo.bdev);
+
+ switch(bo->tbo.mem.mem_type) {
+ case TTM_PL_TT:
+ start = rdev->mc.gtt_start;
+ break;
+ case TTM_PL_VRAM:
+ start = rdev->mc.vram_start;
+ break;
+ }
+
+ return (bo->tbo.mem.start << PAGE_SHIFT) + start;
}
static inline unsigned long radeon_bo_size(struct radeon_bo *bo)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index badf1b6d1549..1c8303468e8f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,7 +56,7 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
-static struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
+struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
struct radeon_device *rdev;
@@ -82,7 +82,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.gtt_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -104,7 +103,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = rdev->mc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] drm/vmwgfx: don't use ttm bo->offset
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..1e59c019affa 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
ret = ttm_bo_validate(bo, , );
/* For some reason we didn't end up at the start of vram */
- WARN_ON(ret == 0 && bo->offset != 0);
+ WARN_ON(ret == 0 && bo->mem.start != 0);
if (!ret)
vmw_bo_pin_reserved(buf, true);
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object
*bo,
{
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
- ptr->offset = bo->offset;
+ ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 73489a45decb..72c2cf4053df 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3313,7 +3313,7 @@ static void vmw_apply_relocations(struct vmw_sw_context
*sw_context)
bo = >vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- reloc->location->offset += bo->offset;
+ reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index e5252ef3812f..1cdc445b24c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -612,7 +612,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct
vmw_private *dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM) {
cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
- cmd->body.guestResult.offset = bo->offset;
+ cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..e7134aebeb81 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = _gmrid_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/51] drm/omap: Replace custom display drivers with drm_bridge and drm_panel
Hi, On Sun, Feb 16, 2020 at 11:02:17PM +0200, Laurent Pinchart wrote: > This patch series is the sixth attempt to (nearly, see [1]) > complete the rework of the omapdrm driver to move to drm_bridge > and drm_panel. > > Version 2, available at [2], explains in its long cover letter the > rationale for the changes. I won't duplicate it here as it is > still valid as-is. > > Compared to v5, available at [3], this version has been rebased on > top of drm-misc-next, and minor bugs have been fixed, including > interlaced modes support with VENC. > > The patches can be found at > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel > > [1] The only notable exception is the omapdrm-specific DSI panel > driver that implements a large number of custom operations. This > is being addressed separately. > > [2] https://patchwork.kernel.org/cover/11102445/ > [3] https://patchwork.kernel.org/cover/11349617/ The series is Tested-by: Sebastian Reichel Reviewed-by: Sebastian Reichel Testing was done on Droid 4, DSI command mode panel is still working. I had to add the following patch because of the base you chose for the branch. Might make sense to use 5.6-rc1 instead. https://lore.kernel.org/lkml/CAHk-=wh8VLe3AEKhz=1bzSO=1fv4EM71EhufxuC=Gp=+blh...@mail.gmail.com/ -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/mediatek: add fb swap in async_update
Hi, Bibby:
On Thu, 2020-02-13 at 12:06 +0800, CK Hu wrote:
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > Besides x, y position, width and height,
> > fb also need updating in async update.
> >
>
> Reviewed-by: CK Hu
>
Applied to mediatek-drm-fixes-5.6 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.6
Regards,
CK
> > Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
> > update")
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index d32b494ff1de..e084c36fdd8a 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -122,6 +122,7 @@ static void mtk_plane_atomic_async_update(struct
> > drm_plane *plane,
> > plane->state->src_y = new_state->src_y;
> > plane->state->src_h = new_state->src_h;
> > plane->state->src_w = new_state->src_w;
> > + swap(plane->state->fb, new_state->fb);
> > state->pending.async_dirty = true;
> >
> > mtk_drm_crtc_async_update(new_state->crtc, plane, new_state);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/mediatek: add plane check in async_check function
Hi, Bibby:
On Thu, 2020-02-13 at 11:54 +0800, CK Hu wrote:
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > MTK do rotation checking and transferring in layer check function,
> > but we do not check that in atomic_check,
> > so add back in atomic_check function.
> >
>
> Reviewed-by: CK Hu
>
Applied to mediatek-drm-fixes-5.6 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.6
Regards,
CK
> > Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic
> > update")
> >
> > Signed-off-by: Bibby Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index 189744d34f53..d32b494ff1de 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -81,6 +81,7 @@ static int mtk_plane_atomic_async_check(struct drm_plane
> > *plane,
> > struct drm_plane_state *state)
> > {
> > struct drm_crtc_state *crtc_state;
> > + int ret;
> >
> > if (plane != state->crtc->cursor)
> > return -EINVAL;
> > @@ -91,6 +92,11 @@ static int mtk_plane_atomic_async_check(struct drm_plane
> > *plane,
> > if (!plane->state->fb)
> > return -EINVAL;
> >
> > + ret = mtk_drm_crtc_plane_check(state->crtc, plane,
> > + to_mtk_plane_state(state));
> > + if (ret)
> > + return ret;
> > +
> > if (state->state)
> > crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> > state->crtc);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/edid: temporary workaround to pass HDMI 2.0 compliance HF1-13
On Tue, Feb 18, Ville Syrjälä wrote:
>On Tue, Feb 18, 2020 at 01:41:39AM +0800, Lee Shawn C wrote:
>> Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
>> output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
>> And check scrambling feature was disabled as well.
>>
>> But QD980 report it can support low rate scrambling. The vendor
>> specific data block byte[6] was 0x88. If driver enabled scrambling
>> rely on this info. Then HF1-13 would not get pass because DUT have to
>> disable scrambling to run this case.
>
>Sounds like a broken test to me.
Yes! We will try to contact the vendor (Teledyne LeCroy) to analyze.
Like what we mention the patch title. This is just a temporary
workaround to pass this case.
Best regards,
Shawn
>
>>
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Cc: Clint Taylor
>> Cc: Cooper Chiou
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/drm_edid.c | 13 ++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 99769d6c9f84..0b4badc20c35 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -85,6 +85,8 @@
>> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
>> /* Non desktop display (i.e. HMD) */
>> #define EDID_QUIRK_NON_DESKTOP (1 << 12)
>> +/* Do not enable low rates scrambling */
>> +#define EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING (1 << 13)
>>
>> struct detailed_mode_closure {
>> struct drm_connector *connector;
>> @@ -214,6 +216,9 @@ static const struct edid_quirk {
>>
>> /* OSVR HDK and HDK2 VR Headsets */
>> { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
>> +
>> +/* Quantumdata 980 test platform */
>> +{ "QDI", 0x03D4, EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING },
>> };
>>
>> /*
>> @@ -4710,10 +4715,11 @@ static void
>> drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector, }
>>
>> static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
>> - const u8 *hf_vsdb)
>> + const u8 *hf_vsdb, const struct edid *edid)
>> {
>> struct drm_display_info *display = >display_info;
>> struct drm_hdmi_info *hdmi = >hdmi;
>> +u32 quirks = edid_get_quirks(edid);
>>
>> display->has_hdmi_infoframe = true;
>>
>> @@ -4747,7 +4753,8 @@ static void drm_parse_hdmi_forum_vsdb(struct
>> drm_connector *connector,
>> scdc->scrambling.supported = true;
>>
>> /* Few sinks support scrambling for clocks < 340M */
>> -if ((hf_vsdb[6] & 0x8))
>> +if ((hf_vsdb[6] & 0x8) &&
>> +!(quirks & EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING))
>> scdc->scrambling.low_rates = true;
>> }
>> }
>> @@ -4870,7 +4877,7 @@ static void drm_parse_cea_ext(struct drm_connector
>> *connector,
>> if (cea_db_is_hdmi_vsdb(db))
>> drm_parse_hdmi_vsdb_video(connector, db);
>> if (cea_db_is_hdmi_forum_vsdb(db))
>> -drm_parse_hdmi_forum_vsdb(connector, db);
>> +drm_parse_hdmi_forum_vsdb(connector, db, edid);
>> if (cea_db_is_y420cmdb(db))
>> drm_parse_y420cmdb_bitmap(connector, db);
>> if (cea_db_is_vcdb(db))
>> --
>> 2.17.1
>
>--
>Ville Syrjälä
>Intel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/51] drm/bridge: Add connector-related bridge operations and data
On Tue, Feb 18, 2020 at 2:21 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Mon, Feb 17, 2020 at 10:53:08AM +0100, Daniel Vetter wrote:
> > On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> > > To support implementation of DRM connectors on top of DRM bridges
> > > instead of by bridges, the drm_bridge needs to expose new operations and
> > > data:
> > >
> > > - Output detection, hot-plug notification, mode retrieval and EDID
> > > retrieval operations
> > > - Bitmask of supported operations
> > > - Bridge output type
> > > - I2C adapter for DDC access
> > >
> > > Add and document these.
> > >
> > > Three new bridge helper functions are also added to handle hot plug
> > > notification in a way that is as transparent as possible for the
> > > bridges.
> > >
> > > Signed-off-by: Laurent Pinchart
> > > Reviewed-by: Boris Brezillon
> > > Reviewed-by: Sam Ravnborg
> > > ---
> > > Changes since v3:
> > >
> > > - Fix typos
> > >
> > > Changes since v2:
> > >
> > > - Add wrappers around the .detect(), .get_modes() and .get_edid()
> > > operations
> > > - Warn bridge drivers about valid usage of the connector argument to
> > > .get_modes() and .get_edid()
> > >
> > > Changes since v1:
> > >
> > > - Make .hpd_enable() and .hpd_disable() optional
> > > - Rename .lost_hotplug() to .hpd_notify()
> > > - Add ddc field to drm_bridge
> > > ---
> > > drivers/gpu/drm/drm_bridge.c | 162 +
> > > include/drm/drm_bridge.h | 192 ++-
> > > 2 files changed, 353 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index 68ab933ee430..78d26a9a3ee6 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -71,6 +71,8 @@ static LIST_HEAD(bridge_list);
> > > */
> > > void drm_bridge_add(struct drm_bridge *bridge)
> > > {
> > > + mutex_init(>hpd_mutex);
> > > +
> > > mutex_lock(_lock);
> > > list_add_tail(>list, _list);
> > > mutex_unlock(_lock);
> > > @@ -87,6 +89,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > > mutex_lock(_lock);
> > > list_del_init(>list);
> > > mutex_unlock(_lock);
> > > +
> > > + mutex_destroy(>hpd_mutex);
> > > }
> > > EXPORT_SYMBOL(drm_bridge_remove);
> > >
> > > @@ -919,6 +923,164 @@ int drm_atomic_bridge_chain_check(struct drm_bridge
> > > *bridge,
> > > }
> > > EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
> > >
> > > +/**
> > > + * drm_bridge_detect - check if anything is attached to the bridge output
> > > + * @bridge: bridge control structure
> > > + *
> > > + * If the bridge supports output detection, as reported by the
> > > + * DRM_BRIDGE_OP_DETECT bridge ops flag, call _bridge_funcs.detect
> > > for the
> > > + * bridge and return the connection status. Otherwise return
> > > + * connector_status_unknown.
> > > + *
> > > + * RETURNS:
> > > + * The detection status on success, or connector_status_unknown if the
> > > bridge
> > > + * doesn't support output detection.
> > > + */
> > > +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> > > +{
> > > + if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> > > + return connector_status_unknown;
> > > +
> > > + return bridge->funcs->detect(bridge);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> > > +
> > > +/**
> > > + * drm_bridge_get_modes - fill all modes currently valid for the sink
> > > into the
> > > + * @connector
> > > + * @bridge: bridge control structure
> > > + * @connector: the connector to fill with modes
> > > + *
> > > + * If the bridge supports output modes retrieval, as reported by the
> > > + * DRM_BRIDGE_OP_MODES bridge ops flag, call _bridge_funcs.get_modes
> > > to
> > > + * fill the connector with all valid modes and return the number of modes
> > > + * added. Otherwise return 0.
> > > + *
> > > + * RETURNS:
> > > + * The number of modes added to the connector.
> > > + */
> > > +int drm_bridge_get_modes(struct drm_bridge *bridge,
> > > +struct drm_connector *connector)
> > > +{
> > > + if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> > > + return 0;
> > > +
> > > + return bridge->funcs->get_modes(bridge, connector);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> > > +
> > > +/**
> > > + * drm_bridge_get_edid - get the EDID data of the connected display
> > > + * @bridge: bridge control structure
> > > + * @connector: the connector to read EDID for
> > > + *
> > > + * If the bridge supports output EDID retrieval, as reported by the
> > > + * DRM_BRIDGE_OP_EDID bridge ops flag, call _bridge_funcs.get_edid to
> > > + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> > > + *
> > > + * RETURNS:
> > > + * The retrieved EDID on success, or an error pointer otherwise.
> > > + */
> > > +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> > > +struct
Re: [PATCHv5 04/34] drm/gem-fb-helper: Add generic afbc size checks
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:50PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 49 +--
> include/drm/drm_framebuffer.h| 50
> include/drm/drm_gem_framebuffer_helper.h | 1 +
> 3 files changed, 96 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index d2fce1ec8f37..5fe9032a5ee8 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -21,6 +21,11 @@
> #include
> #include
>
> +#define AFBC_HEADER_SIZE 16
> +#define AFBC_TH_LAYOUT_ALIGNMENT 8
> +#define AFBC_SUPERBLOCK_PIXELS 256
> +#define AFBC_SUPERBLOCK_ALIGNMENT128
> +
> /**
> * DOC: overview
> *
> @@ -299,6 +304,34 @@ int drm_gem_fb_lookup(struct drm_device *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>
> +static int drm_gem_afbc_min_size(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_afbc_framebuffer *afbc_fb)
> +{
> + u32 n_blocks;
> +
> + if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
> _fb->block_width, _fb->block_height))
> + return -EINVAL;
> +
> + /* tiled header afbc */
> + if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
> + afbc_fb->block_width *= AFBC_TH_LAYOUT_ALIGNMENT;
> + afbc_fb->block_height *= AFBC_TH_LAYOUT_ALIGNMENT;
> + }
TBH, here caculated afbc_fb->block_with/height are not
block_width/height, but fb w/h alignment.
Per my understanding, afbc only has block size: 16x16, 32x8, 64x4 ...
generally the afbc w/h alignment according the the block_size, but once the
tiled header enabled, since one tiled header describes 8x8 superblocks,
so the alignment of w/h need to mutiple 8.
So I think we'd better name the variable to width/height_alignment.
BTW: no matter block_w/h or w/h_alignmtent are only for size
calculation, seems no need to store them to afbc_fb.
> +
> + afbc_fb->aligned_width = ALIGN(mode_cmd->width, afbc_fb->block_width);
> + afbc_fb->aligned_height = ALIGN(mode_cmd->height,
> afbc_fb->block_height);
> + afbc_fb->offset = mode_cmd->offsets[0];
> +
> + n_blocks = (afbc_fb->aligned_width * afbc_fb->aligned_height) /
> AFBC_SUPERBLOCK_PIXELS;
> + afbc_fb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
> afbc_fb->alignment_header);
> +
After check the references in malidp, rockchip and komeda, seems this
afbc->alignment_header is dedicated for komeda only and a pass in
argument.
This is not true. Per afbc HW spec alignment is essential for
all afbc usage. according to the spec the requiremnt are:
AFBC1.0/1.1: 64 byte alignment both for header and body buffer.
AFBC1.2 (tiled header enabled): 4096 alignment.
So this alignement is not a vendor specific value, but afbc feature
requirement, can be determined by afbc modifier.
(malidp and komeda obeys this spec, not sure about Rockchip, but I
think it should be)
But you may see, komeda uses 1024 (not 64) for none-tiled-header afbc,
that's because GPU(MALI) changed this value to 1024 for bus
performance (sorry I don't know the detail), and komeda changed to
1024 to follow.
Back to alignment_header here, I think we can just follow the spec, use 64
for none-tiled-header, 4096 for tiled-header, and no need to let the caller
to specify it
> + afbc_fb->afbc_size = afbc_fb->offset_payload
> ++ n_blocks * ALIGN(afbc_fb->bpp *
> AFBC_SUPERBLOCK_PIXELS / 8, AFBC_SUPERBLOCK_ALIGNMENT);
> +
> + return 0;
> +}
> +
> /**
> * drm_gem_fb_size_check2() - Helper function for use in
> * _mode_config_funcs.fb_create implementations
> @@ -334,19 +367,27 @@ int drm_gem_fb_size_check2(struct drm_device *dev,
> check->pitch_modulo)
> return -EINVAL;
>
> - if (check && check->use_min_size)
> + if (check && check->use_min_size) {
> min_size = check->min_size[i];
> - else
> + } else if (check && check->data &&
> drm_is_afbc(mode_cmd->modifier[0])) {
> + struct drm_afbc_framebuffer *afbc_fb;
> + int ret;
> +
> + afbc_fb = check->data;
> + ret = drm_gem_afbc_min_size(dev, mode_cmd, afbc_fb);
> + if (ret < 0)
> + return ret;
> + min_size = ret;
> + } else {
> min_size = (height - 1) * pitch
>+ drm_format_info_min_pitch(info, i, width)
>+
Re: [PATCHv5 03/34] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check
On Tue, Dec 17, 2019 at 03:49:49PM +0100, Andrzej Pietrasiewicz wrote:
> The new version accepts a struct describing deviations from standard way of
> doing the size checks. The caller must provide the respective values.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 46
> include/drm/drm_gem_framebuffer_helper.h | 16 +++
> 2 files changed, 54 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index b3494f6b66bb..d2fce1ec8f37 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -300,8 +300,8 @@ int drm_gem_fb_lookup(struct drm_device *dev,
> EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>
> /**
> - * drm_gem_fb_size_check() - Helper function for use in
> - *_mode_config_funcs.fb_create implementations
> + * drm_gem_fb_size_check2() - Helper function for use in
> + * _mode_config_funcs.fb_create implementations
> * @dev: DRM device
> * @mode_cmd: Metadata from the userspace framebuffer creation request
> *
> @@ -311,9 +311,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
> * Returns:
> * Zero on success or a negative error code on failure.
> */
> -int drm_gem_fb_size_check(struct drm_device *dev,
> - const struct drm_mode_fb_cmd2 *mode_cmd,
> - struct drm_gem_object **objs)
> +int drm_gem_fb_size_check2(struct drm_device *dev,
[nit-pick]: how about name it to drm_gem_fb_custom_size_check()
Reviewed-by: James Qian Wang (Arm Technology China)
James.
> +const struct drm_mode_fb_cmd2 *mode_cmd,
> +const struct drm_size_check *check,
> +struct drm_gem_object **objs)
> {
> const struct drm_format_info *info;
> int i;
> @@ -326,10 +327,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> unsigned int min_size;
> + u32 pitch = mode_cmd->pitches[i];
> +
> + if (check && check->use_pitch_multiplier)
> + if ((pitch * check->pitch_multiplier[i]) %
> + check->pitch_modulo)
> + return -EINVAL;
>
> - min_size = (height - 1) * mode_cmd->pitches[i]
> - + drm_format_info_min_pitch(info, i, width)
> - + mode_cmd->offsets[i];
> + if (check && check->use_min_size)
> + min_size = check->min_size[i];
> + else
> + min_size = (height - 1) * pitch
> + + drm_format_info_min_pitch(info, i, width)
> + + mode_cmd->offsets[i];
>
> if (objs[i]->size < min_size)
> return -EINVAL;
> @@ -338,6 +348,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> return 0;
>
> }
> +EXPORT_SYMBOL_GPL(drm_gem_fb_size_check2);
> +
> +/**
> + * drm_gem_fb_size_check() - Helper function for use in
> + *_mode_config_funcs.fb_create implementations
> + * @dev: DRM device
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + *
> + * This function can be used to verify buffer sizes for all planes.
> + * It is caller's responsibility to put the objects on failure.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int drm_gem_fb_size_check(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object **objs)
> +{
> + return drm_gem_fb_size_check2(dev, mode_cmd, NULL, objs);
> +}
> EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
>
> static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
> diff --git a/include/drm/drm_gem_framebuffer_helper.h
> b/include/drm/drm_gem_framebuffer_helper.h
> index c85d4b152e91..4955af96d6c3 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -11,6 +11,18 @@ struct drm_mode_fb_cmd2;
> struct drm_plane;
> struct drm_plane_state;
> struct drm_simple_display_pipe;
> +struct drm_size_check;
> +
> +/**
> + * struct drm_size_check - Description of special requirements for size
> checks.
> + */
> +struct drm_size_check {
> + unsigned int min_size[4];
> + bool use_min_size;
> + u32 pitch_multiplier[4];
> + u32 pitch_modulo;
> + bool use_pitch_multiplier;
> +};
>
> struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
> unsigned int plane);
> @@ -32,6 +44,10 @@ int drm_gem_fb_lookup(struct drm_device *dev,
>
Re: [PATCHv5 02/34] drm/gem-fb-helper: Allow drivers to allocate struct drm_framebuffer on their own
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:48PM +0100, Andrzej Pietrasiewicz wrote:
> Prepare tools for drivers which need to allocate a struct drm_framebuffer
> (or a container of struct drm_framebuffer) explicitly, before calling
> helpers. In such a case we need new helpers which omit allocating the
> struct drm_framebuffer and this patch provides them. Consequently, they
> are used also inside the helpers themselves.
>
> The interested drivers will likely need to be able to perform object
> lookups and size checks in separate invocations and this patch provides
> that as well. Helpers themselves are updated, too.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 216 ++-
> include/drm/drm_gem_framebuffer_helper.h | 17 ++
> 2 files changed, 181 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index b9bcd310ca2d..b3494f6b66bb 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -54,6 +54,69 @@ struct drm_gem_object *drm_gem_fb_get_obj(struct
> drm_framebuffer *fb,
> }
> EXPORT_SYMBOL_GPL(drm_gem_fb_get_obj);
>
> +/**
> + * drm_gem_fb_init_with_funcs() - Initialize an already allocated framebuffer
> + * @fb: Framebuffer
> + * @dev: DRM device
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + * @obj: GEM objects to be assigned to the framebuffer
> + * @num_planes: number of planes
> + * @funcs: vtable to be used for the framebuffer object
> + *
> + * This variant of the function allows passing a custom vtable.
> + *
> + * Returns:
> + * 0 on success or a negative error code
> + */
> +int drm_gem_fb_init_with_funcs(struct drm_framebuffer *fb,
> +struct drm_device *dev,
> +const struct drm_mode_fb_cmd2 *mode_cmd,
> +struct drm_gem_object **obj,
> +unsigned int num_planes,
> +const struct drm_framebuffer_funcs *funcs)
> +{
> + int ret, i;
> +
> + drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
> +
> + for (i = 0; i < num_planes; i++)
> + fb->obj[i] = obj[i];
> +
> + ret = drm_framebuffer_init(dev, fb, funcs);
> + if (ret)
> + DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
> ret);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_init_with_funcs);
> +
> +static const struct drm_framebuffer_funcs drm_gem_fb_funcs = {
> + .destroy= drm_gem_fb_destroy,
> + .create_handle = drm_gem_fb_create_handle,
> +};
> +
> +/**
> + * drm_gem_fb_init() - Initialize an already allocated framebuffer
> + * @fb: Framebuffer
> + * @dev: DRM device
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + * @obj: GEM objects to be assigned to the framebuffer
> + * @num_planes: number of planes
> + *
> + * This variant of the function uses a default vtable.
> + *
> + * Returns:
> + * 0 on success or a negative error code
> + */
> +int drm_gem_fb_init(struct drm_framebuffer *fb,
> + struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object **obj, unsigned int num_planes)
> +{
> + return drm_gem_fb_init_with_funcs(fb, dev, mode_cmd, obj, num_planes,
> _gem_fb_funcs);
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_init);
> +
> static struct drm_framebuffer *
> drm_gem_fb_alloc(struct drm_device *dev,
>const struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -61,21 +124,14 @@ drm_gem_fb_alloc(struct drm_device *dev,
>const struct drm_framebuffer_funcs *funcs)
> {
> struct drm_framebuffer *fb;
> - int ret, i;
> + int ret;
>
> fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> if (!fb)
> return ERR_PTR(-ENOMEM);
>
> - drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
> -
> - for (i = 0; i < num_planes; i++)
> - fb->obj[i] = obj[i];
> -
> - ret = drm_framebuffer_init(dev, fb, funcs);
> + ret = drm_gem_fb_init_with_funcs(fb, dev, mode_cmd, obj, num_planes,
> funcs);
> if (ret) {
> - DRM_DEV_ERROR(dev->dev, "Failed to init framebuffer: %d\n",
> - ret);
> kfree(fb);
> return ERR_PTR(ret);
> }
> @@ -144,59 +200,29 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
> struct drm_file *file,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>const struct drm_framebuffer_funcs *funcs)
> {
> - const struct drm_format_info *info;
> struct drm_gem_object *objs[4];
> struct drm_framebuffer *fb;
> - int ret, i;
> -
> - info = drm_get_format_info(dev, mode_cmd);
> - if (!info)
> - return ERR_PTR(-EINVAL);
> -
> -
Re: [PATCHv5 01/34] drm/core: Add afbc helper functions
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:47PM +0100, Andrzej Pietrasiewicz wrote:
> Add checking if a modifier is afbc and getting afbc block size.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 53
> include/drm/drm_fourcc.h | 4 +++
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index b234bfaeda06..d14dd7c86020 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> static char printable_char(int c)
> {
> @@ -393,3 +394,55 @@ uint64_t drm_format_info_min_pitch(const struct
> drm_format_info *info,
> drm_format_info_block_height(info, plane));
> }
> EXPORT_SYMBOL(drm_format_info_min_pitch);
> +
> +/**
> + * drm_is_afbc - test if the modifier describes an afbc buffer
> + * @modifier - modifier to be tested
> + *
> + * Returns: true if the modifier describes an afbc buffer
> + */
> +bool drm_is_afbc(u64 modifier)
> +{
> + /* is it ARM AFBC? */
> + if ((modifier & DRM_FORMAT_MOD_ARM_AFBC(0)) == 0)
> + return false;
> +
> + /* Block size must be known */
> + if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) == 0)
> + return false;
Do we really need this block size check here ?
Since modifier with ARM AFBC modifier but have no BLOCK_SIZE which
should be an error, but this check returns such error to NONE-AFBC.
And I saw you already have such error check in func
get_superblock_wh(), so I think we can del this size check in this
func.
James.
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_is_afbc);
> +
> +/**
> + * drm_afbc_get_superblock_wh - extract afbc block width/height from modifier
> + * @modifier: the modifier to be looked at
> + * @w: address of a place to store the block width
> + * @h: address of a place to store the block height
> + *
> + * Returns: true if the modifier describes a supported block size
> + */
> +bool drm_afbc_get_superblock_wh(u64 modifier, u32 *w, u32 *h)
> +{
> + switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + *w = 16;
> + *h = 16;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> + *w = 32;
> + *h = 8;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
> + /* fall through */
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
> + /* fall through */
> + default:
> + DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> + modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_afbc_get_superblock_wh);
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 306d1efeb5e0..7eb23062bf45 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -320,4 +320,8 @@ uint64_t drm_format_info_min_pitch(const struct
> drm_format_info *info,
> int plane, unsigned int buffer_width);
> const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> *buf);
>
> +bool drm_is_afbc(u64 modifier);
> +
> +bool drm_afbc_get_superblock_wh(u64 modifier, u32 *w, u32 *h);
> +
> #endif /* __DRM_FOURCC_H__ */
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 04/51] drm/bridge: Add connector-related bridge operations and data
Hi Daniel,
On Mon, Feb 17, 2020 at 10:53:08AM +0100, Daniel Vetter wrote:
> On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> > To support implementation of DRM connectors on top of DRM bridges
> > instead of by bridges, the drm_bridge needs to expose new operations and
> > data:
> >
> > - Output detection, hot-plug notification, mode retrieval and EDID
> > retrieval operations
> > - Bitmask of supported operations
> > - Bridge output type
> > - I2C adapter for DDC access
> >
> > Add and document these.
> >
> > Three new bridge helper functions are also added to handle hot plug
> > notification in a way that is as transparent as possible for the
> > bridges.
> >
> > Signed-off-by: Laurent Pinchart
> > Reviewed-by: Boris Brezillon
> > Reviewed-by: Sam Ravnborg
> > ---
> > Changes since v3:
> >
> > - Fix typos
> >
> > Changes since v2:
> >
> > - Add wrappers around the .detect(), .get_modes() and .get_edid()
> > operations
> > - Warn bridge drivers about valid usage of the connector argument to
> > .get_modes() and .get_edid()
> >
> > Changes since v1:
> >
> > - Make .hpd_enable() and .hpd_disable() optional
> > - Rename .lost_hotplug() to .hpd_notify()
> > - Add ddc field to drm_bridge
> > ---
> > drivers/gpu/drm/drm_bridge.c | 162 +
> > include/drm/drm_bridge.h | 192 ++-
> > 2 files changed, 353 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 68ab933ee430..78d26a9a3ee6 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -71,6 +71,8 @@ static LIST_HEAD(bridge_list);
> > */
> > void drm_bridge_add(struct drm_bridge *bridge)
> > {
> > + mutex_init(>hpd_mutex);
> > +
> > mutex_lock(_lock);
> > list_add_tail(>list, _list);
> > mutex_unlock(_lock);
> > @@ -87,6 +89,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > mutex_lock(_lock);
> > list_del_init(>list);
> > mutex_unlock(_lock);
> > +
> > + mutex_destroy(>hpd_mutex);
> > }
> > EXPORT_SYMBOL(drm_bridge_remove);
> >
> > @@ -919,6 +923,164 @@ int drm_atomic_bridge_chain_check(struct drm_bridge
> > *bridge,
> > }
> > EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
> >
> > +/**
> > + * drm_bridge_detect - check if anything is attached to the bridge output
> > + * @bridge: bridge control structure
> > + *
> > + * If the bridge supports output detection, as reported by the
> > + * DRM_BRIDGE_OP_DETECT bridge ops flag, call _bridge_funcs.detect for
> > the
> > + * bridge and return the connection status. Otherwise return
> > + * connector_status_unknown.
> > + *
> > + * RETURNS:
> > + * The detection status on success, or connector_status_unknown if the
> > bridge
> > + * doesn't support output detection.
> > + */
> > +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> > +{
> > + if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> > + return connector_status_unknown;
> > +
> > + return bridge->funcs->detect(bridge);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> > +
> > +/**
> > + * drm_bridge_get_modes - fill all modes currently valid for the sink into
> > the
> > + * @connector
> > + * @bridge: bridge control structure
> > + * @connector: the connector to fill with modes
> > + *
> > + * If the bridge supports output modes retrieval, as reported by the
> > + * DRM_BRIDGE_OP_MODES bridge ops flag, call _bridge_funcs.get_modes to
> > + * fill the connector with all valid modes and return the number of modes
> > + * added. Otherwise return 0.
> > + *
> > + * RETURNS:
> > + * The number of modes added to the connector.
> > + */
> > +int drm_bridge_get_modes(struct drm_bridge *bridge,
> > +struct drm_connector *connector)
> > +{
> > + if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> > + return 0;
> > +
> > + return bridge->funcs->get_modes(bridge, connector);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> > +
> > +/**
> > + * drm_bridge_get_edid - get the EDID data of the connected display
> > + * @bridge: bridge control structure
> > + * @connector: the connector to read EDID for
> > + *
> > + * If the bridge supports output EDID retrieval, as reported by the
> > + * DRM_BRIDGE_OP_EDID bridge ops flag, call _bridge_funcs.get_edid to
> > + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> > + *
> > + * RETURNS:
> > + * The retrieved EDID on success, or an error pointer otherwise.
> > + */
> > +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> > +struct drm_connector *connector)
> > +{
> > + if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> > + return ERR_PTR(-ENOTSUPP);
> > +
> > + return bridge->funcs->get_edid(bridge, connector);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
> > +
> > +/**
> > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>
Re: [PATCH v6 00/51] drm/omap: Replace custom display drivers with drm_bridge and drm_panel
Hi Sebastian, On Tue, Feb 18, 2020 at 12:00:13AM +0100, Sebastian Reichel wrote: > Hi, > > On Sun, Feb 16, 2020 at 11:02:17PM +0200, Laurent Pinchart wrote: > > This patch series is the sixth attempt to (nearly, see [1]) > > complete the rework of the omapdrm driver to move to drm_bridge > > and drm_panel. > > > > Version 2, available at [2], explains in its long cover letter the > > rationale for the changes. I won't duplicate it here as it is > > still valid as-is. > > > > Compared to v5, available at [3], this version has been rebased on > > top of drm-misc-next, and minor bugs have been fixed, including > > interlaced modes support with VENC. > > > > The patches can be found at > > > > git://linuxtv.org/pinchartl/media.git omapdrm/bridge/devel > > > > [1] The only notable exception is the omapdrm-specific DSI panel > > driver that implements a large number of custom operations. This > > is being addressed separately. > > > > [2] https://patchwork.kernel.org/cover/11102445/ > > [3] https://patchwork.kernel.org/cover/11349617/ > > The series is > > Tested-by: Sebastian Reichel > Reviewed-by: Sebastian Reichel Thank you. > Testing was done on Droid 4, DSI command mode panel is still > working. I had to add the following patch because of the base > you chose for the branch. Might make sense to use 5.6-rc1 instead. > > https://lore.kernel.org/lkml/CAHk-=wh8VLe3AEKhz=1bzSO=1fv4EM71EhufxuC=Gp=+blh...@mail.gmail.com/ I had initially based it on drm-next, but there are changes in drm-misc-next that were conflicting, hence the rebase. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/9] regmap: Add USB support
On Mon, Feb 17, 2020 at 11:15:37PM +0100, Noralf Trønnes wrote: > Den 17.02.2020 22.39, skrev Mark Brown: > > Out of interest why are 8 bit registers going to be a problem? > I have written 3 drivers so far and they all have some registers that > need to deal with values larger than 255. If I would need to add a lot > of code because of dropping regmap, then I would have looked at ways to > work around this in order to keep regmap, hi/lo registers perhaps with > wrapping access functions. But it looks like the LOC won't change much, > I need a few lines to ensure values are little endian, but I can also > remove some lines that's not needed anymore. Right, so you effectively have mixed register sizes which regmap isn't going to be super happy with (assuming you need all the actual display data to be 8 bit "registers"). One thing you could do there if you wanted to try the regmap route is to have multiple regmaps but since it's not clear what you're really getting from regmap other than the trace functionality you're probably right that it's not worth bothering. The only other thing I can think of is packing RGB into a single register so you're display data isn't 8 bit but that's probably not sensible from a graphics point of view (I didn't really look at that code so no idea what you're doing there). signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/9] regmap: Add USB support
Den 17.02.2020 22.39, skrev Mark Brown: > On Mon, Feb 17, 2020 at 10:33:58PM +0100, Noralf Trønnes wrote: >> Den 17.02.2020 13.11, skrev Mark Brown: > >>> This looks like you just don't support a straight write operation, if >>> you need to do this emulation push it up the stack. > >> After going through the stack I realise that I have a problem. >> What I have failed to fully comprehend is this regmap requirement: > >> if (val_len % map->format.val_bytes) >> return -EINVAL; > >> There will be a spi and i2c driver down the line which will transfer >> buffers of any size, and having to use 8-bit register values will not be >> great. > > Out of interest why are 8 bit registers going to be a problem? > I have written 3 drivers so far and they all have some registers that need to deal with values larger than 255. If I would need to add a lot of code because of dropping regmap, then I would have looked at ways to work around this in order to keep regmap, hi/lo registers perhaps with wrapping access functions. But it looks like the LOC won't change much, I need a few lines to ensure values are little endian, but I can also remove some lines that's not needed anymore. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Applied "ASoC: hdmi-codec: set plugged_cb to NULL when component removing" to the asoc tree
The patch
ASoC: hdmi-codec: set plugged_cb to NULL when component removing
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4aadf4b49ec7d80c5db842ca28479d07108c9484 Mon Sep 17 00:00:00 2001
From: Tzung-Bi Shih
Date: Mon, 17 Feb 2020 11:16:52 +0800
Subject: [PATCH] ASoC: hdmi-codec: set plugged_cb to NULL when component
removing
Sets plugged_cb to NULL when component removing to notify its consumers
: no further plugged status report is required.
Signed-off-by: Tzung-Bi Shih
Link:
https://lore.kernel.org/r/20200217105513.1.Icc323daaf71ad02f191fd8d91136b01b61eca5e3@changeid
Signed-off-by: Mark Brown
---
sound/soc/codecs/hdmi-codec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 543363102d03..bc2903d27e6e 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -779,7 +779,17 @@ static int hdmi_of_xlate_dai_id(struct snd_soc_component
*component,
return ret;
}
+static void hdmi_remove(struct snd_soc_component *component)
+{
+ struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
+
+ if (hcp->hcd.ops->hook_plugged_cb)
+ hcp->hcd.ops->hook_plugged_cb(component->dev->parent,
+ hcp->hcd.data, NULL, NULL);
+}
+
static const struct snd_soc_component_driver hdmi_driver = {
+ .remove = hdmi_remove,
.dapm_widgets = hdmi_widgets,
.num_dapm_widgets = ARRAY_SIZE(hdmi_widgets),
.of_xlate_dai_id= hdmi_of_xlate_dai_id,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Applied "drm/mediatek: fix race condition for HDMI jack status reporting" to the asoc tree
The patch
drm/mediatek: fix race condition for HDMI jack status reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From f07980d4ed60fbb35857b655c94b111f4ddf2abf Mon Sep 17 00:00:00 2001
From: Tzung-Bi Shih
Date: Mon, 17 Feb 2020 11:16:53 +0800
Subject: [PATCH] drm/mediatek: fix race condition for HDMI jack status
reporting
hdmi_conn_detect and mtk_hdmi_audio_hook_plugged_cb would be called
by different threads.
Imaging the following calling sequence:
Thread AThread B
mtk_hdmi_audio_hook_plugged_cb()
mtk_cec_hpd_high() -> disconnected
hdmi_conn_detect()
mtk_cec_hpd_high() -> connected
plugged_cb(connected)
plugged_cb(disconnected)
The latest disconnected is false reported. Makes mtk_cec_hpd_high
and plugged_cb atomic to fix.
Also uses the same lock to protect read/write of plugged_cb and codec_dev.
Fixes: 5d3c64477392 ("drm/mediatek: support HDMI jack status reporting")
Signed-off-by: Tzung-Bi Shih
Acked-by: CK Hu
Link:
https://lore.kernel.org/r/20200217105513.2.I477092c2f104fd589133436c3ae4590e6fc6323b@changeid
Signed-off-by: Mark Brown
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 03aeb73005ef..d80017e3d84a 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -171,6 +172,7 @@ struct mtk_hdmi {
bool enabled;
hdmi_codec_plugged_cb plugged_cb;
struct device *codec_dev;
+ struct mutex update_plugged_status_lock;
};
static inline struct mtk_hdmi *hdmi_ctx_from_bridge(struct drm_bridge *b)
@@ -1199,10 +1201,13 @@ static void mtk_hdmi_clk_disable_audio(struct mtk_hdmi
*hdmi)
static enum drm_connector_status
mtk_hdmi_update_plugged_status(struct mtk_hdmi *hdmi)
{
- bool connected = mtk_cec_hpd_high(hdmi->cec_dev);
+ bool connected;
+ mutex_lock(>update_plugged_status_lock);
+ connected = mtk_cec_hpd_high(hdmi->cec_dev);
if (hdmi->plugged_cb && hdmi->codec_dev)
hdmi->plugged_cb(hdmi->codec_dev, connected);
+ mutex_unlock(>update_plugged_status_lock);
return connected ?
connector_status_connected : connector_status_disconnected;
@@ -1669,8 +1674,11 @@ static int mtk_hdmi_audio_hook_plugged_cb(struct device
*dev, void *data,
{
struct mtk_hdmi *hdmi = data;
+ mutex_lock(>update_plugged_status_lock);
hdmi->plugged_cb = fn;
hdmi->codec_dev = codec_dev;
+ mutex_unlock(>update_plugged_status_lock);
+
mtk_hdmi_update_plugged_status(hdmi);
return 0;
@@ -1729,6 +1737,7 @@ static int mtk_drm_hdmi_probe(struct platform_device
*pdev)
return ret;
}
+ mutex_init(>update_plugged_status_lock);
platform_set_drvdata(pdev, hdmi);
ret = mtk_hdmi_output_init(hdmi);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/9] regmap: Add USB support
On Mon, Feb 17, 2020 at 10:33:58PM +0100, Noralf Trønnes wrote: > Den 17.02.2020 13.11, skrev Mark Brown: > > This looks like you just don't support a straight write operation, if > > you need to do this emulation push it up the stack. > After going through the stack I realise that I have a problem. > What I have failed to fully comprehend is this regmap requirement: > if (val_len % map->format.val_bytes) > return -EINVAL; > There will be a spi and i2c driver down the line which will transfer > buffers of any size, and having to use 8-bit register values will not be > great. Out of interest why are 8 bit registers going to be a problem? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/9] regmap: Add USB support
Den 17.02.2020 13.11, skrev Mark Brown:
> On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
>
>> Add support for regmap over USB for use with the Multifunction USB Device.
>> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
>> interface. The register index width is always 32-bit, but the register
>> value can be 8, 16 or 32 bits wide. LZ4 compression is supported on bulk
>> transfers.
>> +static int regmap_usb_write(void *context, const void *data, size_t count)
>> +{
>> +struct regmap_usb_context *ctx = context;
>> +size_t val_len = count - sizeof(u32);
>> +void *val;
>> +int ret;
>> +
>> +/* buffer needs to be properly aligned for DMA use */
>> +val = kmemdup(data + sizeof(u32), val_len, GFP_KERNEL);
>> +if (!val)
>> +return -ENOMEM;
>> +
>> +ret = regmap_usb_gather_write(ctx, data, sizeof(u32), val, val_len);
>> +kfree(val);
>> +
>> +return ret;
>> +}
>
> This looks like you just don't support a straight write operation, if
> you need to do this emulation push it up the stack.
>
After going through the stack I realise that I have a problem.
What I have failed to fully comprehend is this regmap requirement:
if (val_len % map->format.val_bytes)
return -EINVAL;
There will be a spi and i2c driver down the line which will transfer
buffers of any size, and having to use 8-bit register values will not be
great.
When I started writing regmap-usb 6 months ago I didn't know where it
would take me. The result is now a Multifuntion USB device with an mfd
driver. So, no usage except for the children of the mfd device.
Dropping regmap won't lead to any increased code size to speak of, so
instead of trying to make regmap match my use case, I think I'll put
this code inside the mfd driver.
Oversights like this was one of the things I was hoping to unearth with
this RFC.
Thanks,
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On Mon, Feb 17, 2020 at 7:58 PM Christian König
wrote:
>
> Am 17.02.20 um 18:55 schrieb Daniel Vetter:
> > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> >> Implement the importer side of unpinned DMA-buf handling.
> >>
> >> v2: update page tables immediately
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> >> 2 files changed, 71 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> >> index 770baba621b3..48de7624d49c 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> >> @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev,
> >> struct dma_buf *dma_buf)
> >> return ERR_PTR(ret);
> >> }
> >>
> >> +/**
> >> + * amdgpu_dma_buf_move_notify - _notify implementation
> >> + *
> >> + * @attach: the DMA-buf attachment
> >> + *
> >> + * Invalidate the DMA-buf attachment, making sure that the we re-create
> >> the
> >> + * mapping before the next use.
> >> + */
> >> +static void
> >> +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> >> +{
> >> +struct drm_gem_object *obj = attach->importer_priv;
> >> +struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
> >> +struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> >> +struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> >> +struct ttm_operation_ctx ctx = { false, false };
> >> +struct ttm_placement placement = {};
> >> +struct amdgpu_vm_bo_base *bo_base;
> >> +int r;
> >> +
> >> +if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> >> +return;
> >> +
> >> +r = ttm_bo_validate(>tbo, , );
> >> +if (r) {
> >> +DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
> >> +return;
> >> +}
> >> +
> >> +for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> >> +struct amdgpu_vm *vm = bo_base->vm;
> >> +struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
> >> +
> >> +if (ticket) {
> > Yeah so this is kinda why I've been a total pain about the exact semantics
> > of the move_notify hook. I think we should flat-out require that importers
> > _always_ have a ticket attach when they call this, and that they can cope
> > with additional locks being taken (i.e. full EDEADLCK) handling.
>
> That is pretty much exactly my thinking as well.
>
> And is also the sole reason why I started looking into the ww_mutex
> cursor handling a while back (e.g. the initial version with the horrible
> macro hack).
>
> But this is really really hard to get right. So my thinking for now is
> to push this series upstream to at least unblock my ongoing P2P work.
Hm, but at least the move_notify stuff and the locking nightmare
around that feels rushed if we just push that. Otoh it's indeed
getting painful, and we'll probably have another few rounds of
headaches to sort this all out. What about a
config EXPERIMENTAL_DYNAMIC_DMA_BUF
depends on BROKEN
Wrapped around the new ->move_notify hook, plus all relevant code?
That way you can land at least something, in-tree refactoring might
become easier with at least some example of what it needs to achieve.
But we're also not tricking anyone into believing that this is
production ready.
> > Simplest way to force that contract is to add a dummy 2nd ww_mutex lock to
> > the dma_resv object, which we then can take #ifdef
> > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> >
> > Now the real disaster is how we handle deadlocks. Two issues:
> >
> > - Ideally we'd keep any lock we've taken locked until the end, it helps
> >needless backoffs. I've played around a bit with that but not even poc
> >level, just an idea:
> >
> > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> >
> >Idea is essentially to track a list of objects we had to lock as part of
> >the ttm_bo_validate of the main object.
> >
> > - Second one is if we get a EDEADLCK on one of these sublocks (like the
> >one here). We need to pass that up the entire callchain, including a
> >temporary reference (we have to drop locks to do the ww_mutex_lock_slow
> >call), and need a custom callback to drop that temporary reference
> >(since that's all driver specific, might even be internal ww_mutex and
> >not anything remotely looking like a normal dma_buf). This probably
> >needs the exec util helpers from ttm, but at the dma_resv level, so that
> >we can do something like this:
> >
> > struct dma_resv_ticket {
> > struct ww_acquire_ctx base;
> >
> > /* can be set by anyone (including other drivers) that got hold of
> >* this ticket and had to acquire some new lock. This
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) --- Does this series help? https://patchwork.freedesktop.org/patch/353367/ -- 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 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
Am 17.02.20 um 18:55 schrieb Daniel Vetter:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 770baba621b3..48de7624d49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct
dma_buf *dma_buf)
return ERR_PTR(ret);
}
+/**
+ * amdgpu_dma_buf_move_notify - _notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct ttm_operation_ctx ctx = { false, false };
+ struct ttm_placement placement = {};
+ struct amdgpu_vm_bo_base *bo_base;
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r) {
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+ return;
+ }
+
+ for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+ struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+ if (ticket) {
Yeah so this is kinda why I've been a total pain about the exact semantics
of the move_notify hook. I think we should flat-out require that importers
_always_ have a ticket attach when they call this, and that they can cope
with additional locks being taken (i.e. full EDEADLCK) handling.
That is pretty much exactly my thinking as well.
And is also the sole reason why I started looking into the ww_mutex
cursor handling a while back (e.g. the initial version with the horrible
macro hack).
But this is really really hard to get right. So my thinking for now is
to push this series upstream to at least unblock my ongoing P2P work.
Simplest way to force that contract is to add a dummy 2nd ww_mutex lock to
the dma_resv object, which we then can take #ifdef
CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
Now the real disaster is how we handle deadlocks. Two issues:
- Ideally we'd keep any lock we've taken locked until the end, it helps
needless backoffs. I've played around a bit with that but not even poc
level, just an idea:
https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
Idea is essentially to track a list of objects we had to lock as part of
the ttm_bo_validate of the main object.
- Second one is if we get a EDEADLCK on one of these sublocks (like the
one here). We need to pass that up the entire callchain, including a
temporary reference (we have to drop locks to do the ww_mutex_lock_slow
call), and need a custom callback to drop that temporary reference
(since that's all driver specific, might even be internal ww_mutex and
not anything remotely looking like a normal dma_buf). This probably
needs the exec util helpers from ttm, but at the dma_resv level, so that
we can do something like this:
struct dma_resv_ticket {
struct ww_acquire_ctx base;
/* can be set by anyone (including other drivers) that got hold of
* this ticket and had to acquire some new lock. This lock might
* protect anything, including driver-internal stuff, and isn't
* required to be a dma_buf or even just a dma_resv. */
struct ww_mutex *contended_lock;
/* callback which the driver (which might be a dma-buf exporter
* and not matching the driver that started this locking ticket)
* sets together with @contended_lock, for the main driver to drop
* when it calls dma_resv_unlock on the contended_lock. */
void (drop_ref*)(struct ww_mutex *contended_lock);
};
My initial thinking was to make all of this part of the core ww_mutex
implementation, but then I quickly found that this won't work.
This is all supremely nasty (also ttm_bo_validate would need to be
improved to handle these sublocks and random new objects that could force
a ww_mutex_lock_slow).
The next idea was to have it based on dma_resv objects, but as you also
figured out you then need to drop the reference to the contended
Re: [PATCH 1/2] dt-bindings: display: sun4i-tcon: Add LVDS Dual Link property
Hi Maxime, On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote: > On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote: > > On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote: > > > On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote: > > > > On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote: > > > > > SoCs that have multiple TCONs can use the two set of pins on the > > > > > first TCON > > > > > to drive a dual-link display. Add a property to enable the dual link. > > > > > > > > > > Signed-off-by: Maxime Ripard > > > > > --- > > > > > .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 7 > > > > > +++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > > > > > > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > > index 86ad617d2327..aa6dd8409dbc 100644 > > > > > --- > > > > > a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > > +++ > > > > > b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml > > > > > @@ -105,6 +105,13 @@ properties: > > > > > - const: edp > > > > > - const: lvds > > > > > > > > > > + allwinner,lvds-dual-link: > > > > > +type: boolean > > > > > +description: | > > > > > + On a SoC with two TCON with LVDS support, the first TCON can > > > > > + operate over both pins sets to output in a dual-link setup. > > > > > This > > > > > + will be triggered by setting this property. > > > > > > > > Could you maybe provide an example of how this property is supposed to > > > > be used ? I'm especially wondering what ports are used in that case and > > > > how they're connected. > > > > > > It's pretty trivial to support, it's only a property to set on the > > > encoder node itself. > > > > > > I'm not really sure what you meant by your question with the ports > > > though :/ > > > > I assume that, in the single-link case, you have two TCON instances that > > operate independently, each of them with one port that models an LVDS > > connection to a panel. > > Indeed, > > > In the dual-link mode, how does that look like ? Does the TCON > > instance that operate in dual-link mode have two ports in DT ? There > > are two physical ports, so I think it makes sense to always have two > > ports in DT. That's what we're doing for the LVDS encoders on R-Car > > Gen3, in order to specify in DT which LVDS input of the dual-link > > panel is connected to which LVDS output of the SoC. That allows > > configuring the LVDS encoder to send the even and odd pixels on the > > right port. > > As far as I can tell, you can't control that in our TCON. It just on > more lanes, that's it. Also, we currently have multiple ports, to map > another feature of the TCON, which is that it can drive directly a > panel, or will send its output to the HDMI / TV encoders. Adding > another port in that will break the current binding we have. This will create one issue though, in that the dual-link sinks are supposed to have two input ports, in order to expose the odd and even pixels ordering. If you have a single ouput port in your TCON, how will you interface with such sinks ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206577] New: Periodic screen blanking at a high refresh rate and resolution
https://bugzilla.kernel.org/show_bug.cgi?id=206577 Bug ID: 206577 Summary: Periodic screen blanking at a high refresh rate and resolution Product: Drivers Version: 2.5 Kernel Version: 5.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: tombaz...@outlook.com Regression: No Using a Samsung LC43J892DKUXEN 43" monitor with a Vega 64. I am unable to set the display output to 3840x1200 @ 120Hz. At 100Hz the display behaves as expected, however at 120Hz the display will turn black briefly as if there is a power loss or as if the source input has changed. This will repeat maybe a couple of times every minute. I have tested using a ROG Strix RX VEGA64 OC edition and a Sapphire Radeon RX VEGA 64 Nitro+. I've tested on linux 5.5.2 and mesa 19.3.3, as well as on driver versions 19.9.3, 19.12.3, 19.7.5, 19.12.2, 20.1.1, and 20.2.1 on Windows. I submitted this issue to the AMD bug report a few weeks ago but haven't heard anything back from them, so I am submitting here as well. I had the monitor sent back to Samsung for testing. They used a STRIX GTX950 and had no issues. I have tried multiple DisplayPort cables including the one included with the monitor. -- 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 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> Implement the importer side of unpinned DMA-buf handling.
>
> v2: update page tables immediately
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> 2 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 770baba621b3..48de7624d49c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct
> dma_buf *dma_buf)
> return ERR_PTR(ret);
> }
>
> +/**
> + * amdgpu_dma_buf_move_notify - _notify implementation
> + *
> + * @attach: the DMA-buf attachment
> + *
> + * Invalidate the DMA-buf attachment, making sure that the we re-create the
> + * mapping before the next use.
> + */
> +static void
> +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> +{
> + struct drm_gem_object *obj = attach->importer_priv;
> + struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
> + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> + struct ttm_operation_ctx ctx = { false, false };
> + struct ttm_placement placement = {};
> + struct amdgpu_vm_bo_base *bo_base;
> + int r;
> +
> + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> + return;
> +
> + r = ttm_bo_validate(>tbo, , );
> + if (r) {
> + DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
> + return;
> + }
> +
> + for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> + struct amdgpu_vm *vm = bo_base->vm;
> + struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
> +
> + if (ticket) {
Yeah so this is kinda why I've been a total pain about the exact semantics
of the move_notify hook. I think we should flat-out require that importers
_always_ have a ticket attach when they call this, and that they can cope
with additional locks being taken (i.e. full EDEADLCK) handling.
Simplest way to force that contract is to add a dummy 2nd ww_mutex lock to
the dma_resv object, which we then can take #ifdef
CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
Now the real disaster is how we handle deadlocks. Two issues:
- Ideally we'd keep any lock we've taken locked until the end, it helps
needless backoffs. I've played around a bit with that but not even poc
level, just an idea:
https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
Idea is essentially to track a list of objects we had to lock as part of
the ttm_bo_validate of the main object.
- Second one is if we get a EDEADLCK on one of these sublocks (like the
one here). We need to pass that up the entire callchain, including a
temporary reference (we have to drop locks to do the ww_mutex_lock_slow
call), and need a custom callback to drop that temporary reference
(since that's all driver specific, might even be internal ww_mutex and
not anything remotely looking like a normal dma_buf). This probably
needs the exec util helpers from ttm, but at the dma_resv level, so that
we can do something like this:
struct dma_resv_ticket {
struct ww_acquire_ctx base;
/* can be set by anyone (including other drivers) that got hold of
* this ticket and had to acquire some new lock. This lock might
* protect anything, including driver-internal stuff, and isn't
* required to be a dma_buf or even just a dma_resv. */
struct ww_mutex *contended_lock;
/* callback which the driver (which might be a dma-buf exporter
* and not matching the driver that started this locking ticket)
* sets together with @contended_lock, for the main driver to drop
* when it calls dma_resv_unlock on the contended_lock. */
void (drop_ref*)(struct ww_mutex *contended_lock);
};
This is all supremely nasty (also ttm_bo_validate would need to be
improved to handle these sublocks and random new objects that could force
a ww_mutex_lock_slow).
Plan B would be to throw our hands into and declare that "move_notify is
best effort only and can fail for any reason". Exactly like ttm eviction
currently does, even with all your hacks to do at least some dma_resv_lock
(but not the full slowpath).
Given how much "fun" you have with all the low memory handling and ttm
fundamentally being best-effort only (despite that dma_resv would allow us
to do this right, with some work) I'm not sure that's a good idea to
extend to a cross-driver interface. Personally I'd lean towards fixing
this first fully (in ttm/amdgpu), and then using that to implement
move_notify correctly.
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 Manuel Ullmann (la...@posteo.de) changed: What|Removed |Added Attachment #287449|0 |1 is patch|| Attachment #287449|application/mbox|text/plain mime type|| -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #12 from Manuel Ullmann (la...@posteo.de) --- Created attachment 287449 --> https://bugzilla.kernel.org/attachment.cgi?id=287449=edit Call optimize bandwidth again. I pinned the issue down to the four lines, which call optimize_bandwidth. Unfortunately the commit message indicates, that its removal fixed other issues, so it can not be simply put back in. Maybe this one is also vendor specific voltage lowering. Are there some sys nodes, which expose vendor adaptations? I’ve got one from MSI [1] with 130 Watt TDP. [1]: https://us.msi.com/Graphics-card/Radeon-RX-5500-XT-GAMING-X-8G/Specification -- 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
[drm-intel:drm-intel-next-queued 1/2] drivers/gpu/drm/i915/gt/intel_lrc.c:1224:3: note: in expansion of macro 'I915_SELFTEST_ONLY'
Hi Tvrtko,
FYI, the error/warning still remains.
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: d194314da04eb965c651dcef6d692dc83821a414
commit: 1883a0a4658eaba354db2179b4d3395247d27582 [1/2] drm/i915: Track hw
reported context runtime
config: i386-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
git checkout 1883a0a4658eaba354db2179b4d3395247d27582
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/i915/gt/intel_engine_types.h:24:0,
from drivers/gpu/drm/i915/gt/intel_context_types.h:18,
from drivers/gpu/drm/i915/gem/i915_gem_context_types.h:20,
from drivers/gpu/drm/i915/i915_request.h:31,
from drivers/gpu/drm/i915/i915_active.h:13,
from drivers/gpu/drm/i915/gem/i915_gem_object_types.h:13,
from drivers/gpu/drm/i915/display/intel_frontbuffer.h:30,
from drivers/gpu/drm/i915/i915_drv.h:72,
from drivers/gpu/drm/i915/gt/intel_lrc.c:136:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function
'intel_context_update_runtime':
drivers/gpu/drm/i915/i915_selftest.h:118:31: warning: statement with no
effect [-Wunused-value]
#define I915_SELFTEST_ONLY(x) 0
^
>> drivers/gpu/drm/i915/gt/intel_lrc.c:1224:3: note: in expansion of macro
>> 'I915_SELFTEST_ONLY'
I915_SELFTEST_ONLY(ce->runtime.num_underflow += dt < 0);
^~
drivers/gpu/drm/i915/i915_selftest.h:118:31: warning: statement with no
effect [-Wunused-value]
#define I915_SELFTEST_ONLY(x) 0
^
drivers/gpu/drm/i915/gt/intel_lrc.c:1225:3: note: in expansion of macro
'I915_SELFTEST_ONLY'
I915_SELFTEST_ONLY(ce->runtime.max_underflow =
^~
vim +/I915_SELFTEST_ONLY +1224 drivers/gpu/drm/i915/gt/intel_lrc.c
1208
1209 static void intel_context_update_runtime(struct intel_context *ce)
1210 {
1211 u32 old;
1212 s32 dt;
1213
1214 if (intel_context_is_barrier(ce))
1215 return;
1216
1217 old = ce->runtime.last;
1218 ce->runtime.last = intel_context_get_runtime(ce);
1219 dt = ce->runtime.last - old;
1220
1221 if (unlikely(dt <= 0)) {
1222 CE_TRACE(ce, "runtime underflow: last=%u, new=%u,
delta=%d\n",
1223 old, ce->runtime.last, dt);
> 1224 I915_SELFTEST_ONLY(ce->runtime.num_underflow += dt < 0);
1225 I915_SELFTEST_ONLY(ce->runtime.max_underflow =
1226 max_t(u32,
ce->runtime.max_underflow, -dt));
1227 return;
1228 }
1229
1230 ewma_runtime_add(>runtime.avg, dt);
1231 ce->runtime.total += dt;
1232 }
1233
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #5 from Noel Maersk (veox+ker...@veox.pw) --- I'm not able to bisect at current moment. Will try by end of workweek. - User `muncrief` has recently reported something similar in a different bug report, here: https://bugzilla.kernel.org/show_bug.cgi?id=204241#c48 ... for Radeon R9 390, ever since linux 5.5-rc1. They were suggested opening a new issue, but a search on bugzilla shows they never did. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #3 from Noel Maersk (veox+ker...@veox.pw) --- Created attachment 287447 --> https://bugzilla.kernel.org/attachment.cgi?id=287447=edit lspci output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 Noel Maersk (veox+ker...@veox.pw) changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #2 from Noel Maersk (veox+ker...@veox.pw) --- Created attachment 287445 --> https://bugzilla.kernel.org/attachment.cgi?id=287445=edit dmesg output for resume-from-hibernate, linux 5.5.4 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #1 from Noel Maersk (veox+ker...@veox.pw) --- Created attachment 287443 --> https://bugzilla.kernel.org/attachment.cgi?id=287443=edit dmesg output for resume-from-suspend, linux 5.4.20 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206575] New: [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 Bug ID: 206575 Summary: [amdgpu] [drm] No video signal on resume from suspend, R9 380 Product: Drivers Version: 2.5 Kernel Version: 5.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: veox+ker...@veox.pw Regression: No Created attachment 287441 --> https://bugzilla.kernel.org/attachment.cgi?id=287441=edit dmesg output for resume-from-suspend, linux 5.5.4 OS: Arch Linux GPU: (MSI) Radeon R9 380 On `systemctl suspend` and subsequent resume, the monitors display "no signal". The machine is responsive, commands can be typed on the keyboard, SSH'ing is also possible. Somewhat unexpectedly, resume from hibernation works fine (i.e. there is signal). This started happening a few weeks ago, seemingly when `linux` v5.5.2 was installed. Was also present on v5.5.3 and v5.5.4 (current). `linux-lts` v5.4.20 does not exhibit this behaviour; it's a regression. -- 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 4/8] drm/nouveau: don't use ttm bo->offset
On 2/17/20 4:57 PM, Alex Deucher wrote:
On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das wrote:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Christian König
Missing Acked or Reviewed prefix for Christian.
:facepalm: Thanks Alex.
Nirmoy
Alex
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
-
Re: [PATCH 4/8] drm/nouveau: don't use ttm bo->offset
On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das wrote:
>
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> Christian König
Missing Acked or Reviewed prefix for Christian.
Alex
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
> drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
> drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
> drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
> 15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index 1f08de4241e0..d06a93f2b38a 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
> fb = nouveau_framebuffer(crtc->primary->fb);
> }
>
> - nv_crtc->fb.offset = fb->nvbo->bo.offset;
> + nv_crtc->fb.offset = fb->nvbo->offset;
>
> if (nv_crtc->lut.depth != drm_fb->format->depth) {
> nv_crtc->lut.depth = drm_fb->format->depth;
> @@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
> drm_file *file_priv,
> nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
>
> nouveau_bo_unmap(cursor);
> - nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
> + nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
> nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
> nv_crtc->cursor.show(nv_crtc, true);
> out:
> @@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
> drm_framebuffer *fb,
> /* Initialize a page flip struct */
> *s = (struct nv04_page_flip_state)
> { { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
> - new_bo->bo.offset };
> + new_bo->offset };
>
> /* Keep vblanks on during flip, for the target crtc of this flip */
> drm_crtc_vblank_get(crtc);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 44ee82d0c9b6..89a4ddfcc55f 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume,
> bool runtime)
> continue;
>
> if (nv_crtc->cursor.set_offset)
> - nv_crtc->cursor.set_offset(nv_crtc,
> nv_crtc->cursor.nvbo->bo.offset);
> + nv_crtc->cursor.set_offset(nv_crtc,
> nv_crtc->cursor.nvbo->offset);
> nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
> nv_crtc->cursor_saved_y);
> }
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> index a3a0a73ae8ab..9529bd9053e7 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> @@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
>
> nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
> - nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
> + nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
> nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
> nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
> nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
> @@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> if (format & NV_PVIDEO_FORMAT_PLANAR) {
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
> nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
> - nv_fb->nvbo->bo.offset + fb->offsets[1]);
> + nv_fb->nvbo->offset + fb->offsets[1]);
> }
> nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
> nvif_wr32(dev, NV_PVIDEO_STOP, 0);
> @@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
>
> for (i = 0; i < 2; i++) {
>
Re: [PATCH 1/5] dma-buf: add dynamic DMA-buf handling v14
Please ignore this one, I've send out the wrong version without Daniels
latest comment nit picks fixed.
The interesting one in this series is the last patch.
Regards,
Christian.
Am 17.02.20 um 16:45 schrieb Christian König:
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 106 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +-
include/linux/dma-buf.h | 78 --
3 files changed, 170 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -529,6 +529,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
exp_info->ops->dynamic_mapping))
return ERR_PTR(-EINVAL);
+ if (WARN_ON(!exp_info->ops->dynamic_mapping &&
+ (exp_info->ops->pin || exp_info->ops->unpin)))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -653,7 +657,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* calls attach() of dma_buf_ops to allow device-specific attach functionality
* @dmabuf: [in]buffer to attach device to.
* @dev: [in]device to be attached.
- * @dynamic_mapping: [in]calling convention for map/unmap
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -669,7 +674,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
*/
struct dma_buf_attachment *
dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
- bool dynamic_mapping)
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -683,7 +689,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
attach->dev = dev;
attach->dmabuf = dmabuf;
- attach->dynamic_mapping = dynamic_mapping;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
@@ -702,15 +709,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
- if (dma_buf_is_dynamic(attach->dmabuf))
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
dma_resv_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
if (!sgt)
sgt = ERR_PTR(-ENOMEM);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
- goto err_unlock;
+ goto err_unpin;
}
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -724,6 +735,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
kfree(attach);
return ERR_PTR(ret);
+err_unpin:
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_buf_unpin(attach);
+
err_unlock:
if
[PATCH 4/5] drm/amdgpu: add amdgpu_dma_buf_pin/unpin v2
This implements the exporter side of unpinned DMA-buf handling.
v2: fix minor coding style issues
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 53 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index b2ca78b6abce..770baba621b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -222,6 +222,37 @@ static void amdgpu_dma_buf_detach(struct dma_buf *dmabuf,
bo->prime_shared_count--;
}
+/**
+ * amdgpu_dma_buf_pin - _buf_ops.pin implementation
+ *
+ * @attach: attachment to pin down
+ *
+ * Pin the BO which is backing the DMA-buf so that it can't move any more.
+ */
+static int amdgpu_dma_buf_pin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ /* pin buffer into GTT */
+ return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
+}
+
+/**
+ * amdgpu_dma_buf_unpin - _buf_ops.unpin implementation
+ *
+ * @attach: attachment to unpin
+ *
+ * Unpin a previously pinned BO to make it movable again.
+ */
+static void amdgpu_dma_buf_unpin(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->dmabuf->priv;
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+
+ amdgpu_bo_unpin(bo);
+}
+
/**
* amdgpu_dma_buf_map - _buf_ops.map_dma_buf implementation
* @attach: DMA-buf attachment
@@ -244,9 +275,19 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
struct sg_table *sgt;
long r;
- r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
- if (r)
- return ERR_PTR(r);
+ if (!bo->pin_count) {
+ /* move buffer into GTT */
+ struct ttm_operation_ctx ctx = { false, false };
+
+ amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+ r = ttm_bo_validate(>tbo, >placement, );
+ if (r)
+ return ERR_PTR(r);
+
+ } else if (!(amdgpu_mem_type_to_domain(bo->tbo.mem.mem_type) &
+AMDGPU_GEM_DOMAIN_GTT)) {
+ return ERR_PTR(-EBUSY);
+ }
sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
if (IS_ERR(sgt))
@@ -277,13 +318,9 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment
*attach,
struct sg_table *sgt,
enum dma_data_direction dir)
{
- struct drm_gem_object *obj = attach->dmabuf->priv;
- struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-
dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
sg_free_table(sgt);
kfree(sgt);
- amdgpu_bo_unpin(bo);
}
/**
@@ -330,6 +367,8 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
.dynamic_mapping = true,
.attach = amdgpu_dma_buf_attach,
.detach = amdgpu_dma_buf_detach,
+ .pin = amdgpu_dma_buf_pin,
+ .unpin = amdgpu_dma_buf_unpin,
.map_dma_buf = amdgpu_dma_buf_map,
.unmap_dma_buf = amdgpu_dma_buf_unmap,
.release = drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 6f60a581e3ba..8ae260822908 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
*/
#include
#include
+#include
#include
#include
@@ -1274,6 +1275,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
amdgpu_bo_kunmap(abo);
+ if (abo->tbo.base.dma_buf && !abo->tbo.base.import_attach &&
+ bo->mem.mem_type != TTM_PL_SYSTEM)
+ dma_buf_move_notify(abo->tbo.base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/amdgpu: use allowed_domains for exported DMA-bufs
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 80ba6dfc54e2..d938d458e22d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -417,7 +418,9 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
/* Don't move this buffer if we have depleted our allowance
* to move it. Don't move anything if the threshold is zero.
*/
- if (p->bytes_moved < p->bytes_moved_threshold) {
+ if (p->bytes_moved < p->bytes_moved_threshold &&
+ (!bo->tbo.base.dma_buf ||
+ list_empty(>tbo.base.dma_buf->attachments))) {
if (!amdgpu_gmc_vram_full_visible(>gmc) &&
(bo->flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)) {
/* And don't move a CPU_ACCESS_REQUIRED BO to limited
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 770baba621b3..48de7624d49c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct drm_device *dev, struct
dma_buf *dma_buf)
return ERR_PTR(ret);
}
+/**
+ * amdgpu_dma_buf_move_notify - _notify implementation
+ *
+ * @attach: the DMA-buf attachment
+ *
+ * Invalidate the DMA-buf attachment, making sure that the we re-create the
+ * mapping before the next use.
+ */
+static void
+amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
+{
+ struct drm_gem_object *obj = attach->importer_priv;
+ struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
+ struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ struct ttm_operation_ctx ctx = { false, false };
+ struct ttm_placement placement = {};
+ struct amdgpu_vm_bo_base *bo_base;
+ int r;
+
+ if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
+ return;
+
+ r = ttm_bo_validate(>tbo, , );
+ if (r) {
+ DRM_ERROR("Failed to invalidate DMA-buf import (%d))\n", r);
+ return;
+ }
+
+ for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
+ struct amdgpu_vm *vm = bo_base->vm;
+ struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
+
+ if (ticket) {
+ /* When we get an error here it means that somebody
+* else is holding the VM lock and updating page tables
+* So we can just continue here.
+*/
+ r = dma_resv_lock(resv, ticket);
+ if (r)
+ continue;
+
+ } else {
+ /* TODO: This is more problematic and we actually need
+* to allow page tables updates without holding the
+* lock.
+*/
+ if (!dma_resv_trylock(resv))
+ continue;
+ }
+
+ r = amdgpu_vm_clear_freed(adev, vm, NULL);
+ if (!r)
+ r = amdgpu_vm_handle_moved(adev, vm);
+
+ if (r && r != -EBUSY)
+ DRM_ERROR("Failed to invalidate VM page tables (%d))\n",
+ r);
+
+ dma_resv_unlock(resv);
+ }
+}
+
static const struct dma_buf_attach_ops amdgpu_dma_buf_attach_ops = {
+ .move_notify = amdgpu_dma_buf_move_notify
};
/**
@@ -489,7 +553,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct
drm_device *dev,
return obj;
attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
- _dma_buf_attach_ops, NULL);
+ _dma_buf_attach_ops, obj);
if (IS_ERR(attach)) {
drm_gem_object_put(obj);
return ERR_CAST(attach);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 8ae260822908..8c480c898b0d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -926,6 +926,9 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
return 0;
}
+ if (bo->tbo.base.import_attach)
+ dma_buf_pin(bo->tbo.base.import_attach);
+
bo->flags |= AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS;
/* force to pin into visible video ram */
if (!(bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS))
@@ -1009,6 +1012,9 @@ int amdgpu_bo_unpin(struct amdgpu_bo *bo)
amdgpu_bo_subtract_pin_size(bo);
+ if (bo->tbo.base.import_attach)
+ dma_buf_unpin(bo->tbo.base.import_attach);
+
for (i = 0; i < bo->placement.num_placement; i++) {
bo->placements[i].lpfn = 0;
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/ttm: remove the backing store if no placement is given
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 229205e499db..a56cb2a2b4ad 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1225,6 +1225,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
dma_resv_assert_held(bo->base.resv);
+
+ /*
+* Remove the backing store if no placement is given.
+*/
+ if (!placement->num_placement && !placement->num_busy_placement) {
+ ret = ttm_bo_pipeline_gutting(bo);
+ if (ret)
+ return ret;
+
+ return ttm_tt_create(bo, false);
+ }
+
/*
* Check whether we need to move buffer.
*/
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RFC: Unpinned DMA-buf handling
Hi everyone, hopefully the last iteration of those patches. For now I've addressed the issue of unmapping imported BOs from the amdgpu page tables immediately by locking the page tables in place. For HMM handling we are getting the ability to invalidate BOs without locking the VM anyway, so this last TODO will probably go away rather soon. Place comment, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] dma-buf: add dynamic DMA-buf handling v14
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by the exporter to inform the importers that their mappings should be
destroyed as soon as possible.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback
v4: use importer_priv field instead of mangling exporter priv.
v5: drop invalidation_supported flag
v6: squash together with pin/unpin changes
v7: pin/unpin takes an attachment now
v8: nuke dma_buf_attachment_(map|unmap)_locked,
everything is now handled backward compatible
v9: always cache when export/importer don't agree on dynamic handling
v10: minimal style cleanup
v11: drop automatically re-entry avoidance
v12: rename callback to move_notify
v13: add might_lock in appropriate places
v14: rebase on separated locking change
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 106 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 6 +-
include/linux/dma-buf.h | 78 --
3 files changed, 170 insertions(+), 20 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..ce293cee76ed 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -529,6 +529,10 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
exp_info->ops->dynamic_mapping))
return ERR_PTR(-EINVAL);
+ if (WARN_ON(!exp_info->ops->dynamic_mapping &&
+ (exp_info->ops->pin || exp_info->ops->unpin)))
+ return ERR_PTR(-EINVAL);
+
if (!try_module_get(exp_info->owner))
return ERR_PTR(-ENOENT);
@@ -653,7 +657,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* calls attach() of dma_buf_ops to allow device-specific attach functionality
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
- * @dynamic_mapping: [in]calling convention for map/unmap
+ * @importer_ops [in]importer operations for the attachment
+ * @importer_priv [in]importer private pointer for the attachment
*
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
@@ -669,7 +674,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
*/
struct dma_buf_attachment *
dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
- bool dynamic_mapping)
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -683,7 +689,8 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
attach->dev = dev;
attach->dmabuf = dmabuf;
- attach->dynamic_mapping = dynamic_mapping;
+ attach->importer_ops = importer_ops;
+ attach->importer_priv = importer_priv;
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
@@ -702,15 +709,19 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_is_dynamic(dmabuf)) {
struct sg_table *sgt;
- if (dma_buf_is_dynamic(attach->dmabuf))
+ if (dma_buf_is_dynamic(attach->dmabuf)) {
dma_resv_lock(attach->dmabuf->resv, NULL);
+ ret = dma_buf_pin(attach);
+ if (ret)
+ goto err_unlock;
+ }
sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL);
if (!sgt)
sgt = ERR_PTR(-ENOMEM);
if (IS_ERR(sgt)) {
ret = PTR_ERR(sgt);
- goto err_unlock;
+ goto err_unpin;
}
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -724,6 +735,10 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
kfree(attach);
return ERR_PTR(ret);
+err_unpin:
+ if (dma_buf_is_dynamic(attach->dmabuf))
+ dma_buf_unpin(attach);
+
err_unlock:
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
@@ -744,7 +759,7 @@ EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
Re: [PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset
Am 17.02.20 um 16:04 schrieb Nirmoy Das: Switch over to GEM VRAM's implementation to retrieve bo->offset Signed-off-by: Nirmoy Das Acked-by: Christian König --- drivers/gpu/drm/bochs/bochs_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index 8066d7d370d5..b8e1079f077e 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -38,7 +38,7 @@ static void bochs_plane_update(struct bochs_device *bochs, state->crtc_x, state->crtc_y, state->fb->pitches[0], -state->fb->offsets[0] + gbo->bo.offset); +state->fb->offsets[0] + drm_gem_vram_offset(gbo)); bochs_hw_setformat(bochs, state->fb->format); } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: temporary workaround to pass HDMI 2.0 compliance HF1-13
On Tue, Feb 18, 2020 at 01:41:39AM +0800, Lee Shawn C wrote:
> Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
> output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
> And check scrambling feature was disabled as well.
>
> But QD980 report it can support low rate scrambling. The vendor
> specific data block byte[6] was 0x88. If driver enabled scrambling
> rely on this info. Then HF1-13 would not get pass because DUT have
> to disable scrambling to run this case.
Sounds like a broken test to me.
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Clint Taylor
> Cc: Cooper Chiou
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/drm_edid.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..0b4badc20c35 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -85,6 +85,8 @@
> #define EDID_QUIRK_FORCE_10BPC (1 << 11)
> /* Non desktop display (i.e. HMD) */
> #define EDID_QUIRK_NON_DESKTOP (1 << 12)
> +/* Do not enable low rates scrambling */
> +#define EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING (1 << 13)
>
> struct detailed_mode_closure {
> struct drm_connector *connector;
> @@ -214,6 +216,9 @@ static const struct edid_quirk {
>
> /* OSVR HDK and HDK2 VR Headsets */
> { "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
> +
> + /* Quantumdata 980 test platform */
> + { "QDI", 0x03D4, EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING },
> };
>
> /*
> @@ -4710,10 +4715,11 @@ static void drm_parse_ycbcr420_deep_color_info(struct
> drm_connector *connector,
> }
>
> static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
> - const u8 *hf_vsdb)
> + const u8 *hf_vsdb, const struct edid *edid)
> {
> struct drm_display_info *display = >display_info;
> struct drm_hdmi_info *hdmi = >hdmi;
> + u32 quirks = edid_get_quirks(edid);
>
> display->has_hdmi_infoframe = true;
>
> @@ -4747,7 +4753,8 @@ static void drm_parse_hdmi_forum_vsdb(struct
> drm_connector *connector,
> scdc->scrambling.supported = true;
>
> /* Few sinks support scrambling for clocks < 340M */
> - if ((hf_vsdb[6] & 0x8))
> + if ((hf_vsdb[6] & 0x8) &&
> + !(quirks & EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING))
> scdc->scrambling.low_rates = true;
> }
> }
> @@ -4870,7 +4877,7 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> if (cea_db_is_hdmi_vsdb(db))
> drm_parse_hdmi_vsdb_video(connector, db);
> if (cea_db_is_hdmi_forum_vsdb(db))
> - drm_parse_hdmi_forum_vsdb(connector, db);
> + drm_parse_hdmi_forum_vsdb(connector, db, edid);
> if (cea_db_is_y420cmdb(db))
> drm_parse_y420cmdb_bitmap(connector, db);
> if (cea_db_is_vcdb(db))
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)
Den 17.02.2020 11.32, skrev Neil Armstrong: > Hi, > > On 16/02/2020 18:21, Noralf Trønnes wrote: >> Hi, >> >> A while back I had the idea to turn a Raspberry Pi Zero into a $5 >> USB to HDMI/SDTV/DSI/DPI display adapter. >> >> Thinking about how to represent the display to the driver I realised >> that hardware use registers as API. And Linux does have a generic >> register abstraction: regmap. Furthermore this means that if I can do a >> regmap over USB implementation, it will be easy to do other functions >> like gpio, adc and others. After a few iterations trying to understand >> the USB subsystem and satisfying driver requirements, I now have >> something that looks promising. >> >> I'm sending out an early version hoping to get feedback especially on >> the core parts that handles regmap and interrupts. >> >> Overview: >> >> USB Host : USB Device >> : >> -- : -- >> -- | mfd: mud | : | f_mud | -- >> | Driver | -- : || | Driver | >> -- | regmap-usb | : | (mud_regmap) | -- >> -- : -- >> > > The idea is really like ARA's greybus, but much simpler ! > Anyway nice idea, do you have good performance over USB2 and > RPi's awful DWC2 gagdet controller ? > Not as good as I was hoping for. If I disable compression I'm getting 5 fps for a 1.5MB framebuffer (7800 kB/s): $ modetest -M mud_drm -s 35:1024x768@RG16 -v setting mode 1024x768-60.00Hz@RG16 on connectors 35, crtc 33 freq: 5.07Hz When I tried reading I discovered that it was almost 3 times faster than writing. The zero gadget (loop testing) confirmed my findings: Device: $ sudo modprobe g_zero [ 44.221890] zero gadget: Gadget Zero, version: Cinco de Mayo 2008 [ 44.221906] zero gadget: zero ready [ 60.751451] zero gadget: high-speed config #3: source/sink Host: $ sudo ~/testusb -a -t -g 64 -s 16384 /dev/bus/usb/001/010 test 27, 107.230669 secs -> 1000 / 107 = 9MB/s /dev/bus/usb/001/010 test 28, 37.791292 secs -> 1000 / 37 = 27MB/s [73983.796552] usbtest 1-1.3:3.0: TEST 27: bulk write 1000Mbytes [74205.060204] usbtest 1-1.3:3.0: TEST 28: bulk read 1000Mbytes $ sudo ~/testusb -a -t -g 64 -s 16384 /dev/bus/usb/001/010 test 5, 107.421535 secs /dev/bus/usb/001/010 test 6, 38.189712 secs [74893.204170] usbtest 1-1.3:3.0: TEST 5: write 1000 sglists 64 entries of 16384 bytes [75012.59] usbtest 1-1.3:3.0: TEST 6: read 1000 sglists 64 entries of 16384 bytes I have tried Raspberry Pi1 and Pi4 as host (2 different controllers) and Pi Zero and Beaglebone Black as device, getting similar result. I found this post having the same issue: Re: Asymmetric speed results with testusb/usbtest/g_zero https://www.spinics.net/lists/linux-usb/msg100588.html I haven't got a usb analyzer, but adding printk to dwc2_assign_and_init_hc() showed that IN interrupts were 2-3 ms apart but OUT interrupts were ~8 ms apart. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206475] amdgpu under load drop signal to monitor until hard reset
https://bugzilla.kernel.org/show_bug.cgi?id=206475 Marco (rodomar...@protonmail.com) changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|OBSOLETE|--- --- Comment #6 from Marco (rodomar...@protonmail.com) --- (In reply to Marco from comment #5) > It seems that the problem was insufficient cooling, since the same happened > on a Windows VM. Instead I was wrong, tested Furmark on two different driver sets on W10 bare metal, no crashes for an hour (furmark on VM lasted for 30 seconds). This is a firmware/software problem. Please fix it. -- 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 6/7] drm/bochs: don't use ttm bo->offset
On 2/17/20 1:41 PM, Gerd Hoffmann wrote:
On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
Calculate GPU offset within bochs driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 8066d7d370d5..852ec7910d84 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -38,7 +38,8 @@ static void bochs_plane_update(struct bochs_device *bochs,
state->crtc_x,
state->crtc_y,
state->fb->pitches[0],
-state->fb->offsets[0] + gbo->bo.offset);
+state->fb->offsets[0] +
+(gbo->bo.mem.start << PAGE_SHIFT));
I'd suggest to use drm_gem_vram_offset() here ...
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 92a11bb42365..e7ef4cd8116d 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return gbo->bo.mem.start << PAGE_SHIFT;
... and move this to a separate patch. The vram helpers are used by
more drivers than just bochs.
Thanks for reviewing Gerd, will send next version with your suggestions
applied.
Regards,
Nirmoy
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/bochs: don't use ttm bo->offset
On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
> Calculate GPU offset within bochs driver itself without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 8066d7d370d5..852ec7910d84 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -38,7 +38,8 @@ static void bochs_plane_update(struct bochs_device *bochs,
>state->crtc_x,
>state->crtc_y,
>state->fb->pitches[0],
> - state->fb->offsets[0] + gbo->bo.offset);
> + state->fb->offsets[0] +
> + (gbo->bo.mem.start << PAGE_SHIFT));
I'd suggest to use drm_gem_vram_offset() here ...
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 92a11bb42365..e7ef4cd8116d 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -214,7 +214,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
> {
> if (WARN_ON_ONCE(!gbo->pin_count))
> return (s64)-ENODEV;
> - return gbo->bo.offset;
> + return gbo->bo.mem.start << PAGE_SHIFT;
... and move this to a separate patch. The vram helpers are used by
more drivers than just bochs.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/qxl: don't use ttm bo->offset
On Mon, Feb 17, 2020 at 11:18:39AM +0100, Nirmoy Das wrote: > This patch also removes slot->gpu_offset which is not required as > VRAM and PRIV slot are in separate PCI bar Well, gpu_offset is still in struct qxlslot ... Other than that the patch looks fine, and this is minor enough that I'll happily Acked-by: Gerd Hoffmann cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 6/9] regmap: Speed up _regmap_raw_write_impl() for large buffers
On Sun, Feb 16, 2020 at 06:21:14PM +0100, Noralf Trønnes wrote:
> When writing a 3MB buffer the unwritable check in _regmap_raw_write_impl()
> adds a ~20ms overhead on a Raspberry Pi 4.
> Amend this by avoiding the check if it's not necessary.
This is a generic optimization, why is it mixed in with the rest of this
series? There is no dependency either way :(
> /* Check for unwritable registers before we start */
> - for (i = 0; i < val_len / map->format.val_bytes; i++)
> - if (!regmap_writeable(map,
> - reg + regmap_get_offset(map, i)))
> - return -EINVAL;
> + if (map->max_register || map->writeable_reg || map->wr_table) {
> + for (i = 0; i < val_len / map->format.val_bytes; i++)
> + if (!regmap_writeable(map,
> + reg + regmap_get_offset(map, i)))
> + return -EINVAL;
> + }
This is going to break if there is any change to the implementation of
regmap_writeable(). The code should at least be next to that if not
actually shared so that this doesn't happen. I'd suggest implementing a
function regmap_writeable_range() and then making regmap_writeable()
call that.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/nouveau: don't use ttm bo->offset
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Acked-by: Christian König for this one and
patch #5 and #6 in this series.
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_abi16.c | 8
drivers/gpu/drm/nouveau/nouveau_bo.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.h| 3 +++
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..d06a93f2b38a 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -845,7 +845,7 @@ nv04_crtc_do_mode_set_base(struct drm_crtc *crtc,
fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->bo.offset;
+ nv_crtc->fb.offset = fb->nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
@@ -1013,7 +1013,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct
drm_file *file_priv,
nv04_cursor_upload(dev, cursor, nv_crtc->cursor.nvbo);
nouveau_bo_unmap(cursor);
- nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->bo.offset;
+ nv_crtc->cursor.offset = nv_crtc->cursor.nvbo->offset;
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
out:
@@ -1191,7 +1191,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
/* Initialize a page flip struct */
*s = (struct nv04_page_flip_state)
{ { }, event, crtc, fb->format->cpp[0] * 8, fb->pitches[0],
- new_bo->bo.offset };
+ new_bo->offset };
/* Keep vblanks on during flip, for the target crtc of this flip */
drm_crtc_vblank_get(crtc);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 44ee82d0c9b6..89a4ddfcc55f 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -151,7 +151,7 @@ nv04_display_init(struct drm_device *dev, bool resume, bool
runtime)
continue;
if (nv_crtc->cursor.set_offset)
- nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->bo.offset);
+ nv_crtc->cursor.set_offset(nv_crtc,
nv_crtc->cursor.nvbo->offset);
nv_crtc->cursor.set_pos(nv_crtc, nv_crtc->cursor_saved_x,
nv_crtc->cursor_saved_y);
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index a3a0a73ae8ab..9529bd9053e7 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -150,7 +150,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->bo.offset);
+ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@ -172,7 +172,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nv_fb->nvbo->bo.offset + fb->offsets[1]);
+ nv_fb->nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@ -396,7 +396,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nv_fb->nvbo->bo.offset);
+ nv_fb->nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4
Re: [RFC 1/9] regmap: Add USB support
On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
> Add support for regmap over USB for use with the Multifunction USB Device.
> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
> interface. The register index width is always 32-bit, but the register
> value can be 8, 16 or 32 bits wide. LZ4 compression is supported on bulk
> transfers.
This looks like a custom thing for some particular devices rather than a
thing that will work for any USB device? If that is the case then this
should have a more specific name.
> +++ b/drivers/base/regmap/regmap-usb.c
> @@ -0,0 +1,1026 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Register map access API - USB support
Why is this GPL-2.0-or-later? The rest of the code is just plain old
GPL-2.0.
Please also make the entire comment a C++ one so things look more
intentional.
> +
> + ktime_t start; /* FIXME: Temporary debug/perf aid */
Add tracepoints, most of your debugging stuff looks like you want to use
tracepoints - you can easily work out time differences with them by
postprocessing the log, they get very fine grained timestamps.
> + mutex_lock(_usb_interfaces_lock);
> + list_for_each_entry(entry, _usb_interfaces, link)
> + if (entry->interface == interface) {
> + ruif = entry;
> + ruif->refcount++;
> + goto out_unlock;
> + }
> +
You're missing some { } here.
> +static long mud_drm_throughput(ktime_t begin, ktime_t end, size_t len)
> +{
> + long throughput;
> +
> + throughput = ktime_us_delta(end, begin);
> + throughput = throughput ? (len * 1000) / throughput : 0;
> + throughput = throughput * 1000 / 1024;
Please write normal conditional statements to improve legibility.
> +static int regmap_usb_gather_write(void *context,
> +const void *reg, size_t reg_len,
> +const void *val, size_t val_len)
> +{
> + return regmap_usb_transfer(context, false, reg, (void *)val, val_len);
> +}
Why are we casting away a const here? If we really need to modify the
raw data that's being transmitted take a copy.
> +static int regmap_usb_write(void *context, const void *data, size_t count)
> +{
> + struct regmap_usb_context *ctx = context;
> + size_t val_len = count - sizeof(u32);
> + void *val;
> + int ret;
> +
> + /* buffer needs to be properly aligned for DMA use */
> + val = kmemdup(data + sizeof(u32), val_len, GFP_KERNEL);
> + if (!val)
> + return -ENOMEM;
> +
> + ret = regmap_usb_gather_write(ctx, data, sizeof(u32), val, val_len);
> + kfree(val);
> +
> + return ret;
> +}
This looks like you just don't support a straight write operation, if
you need to do this emulation push it up the stack.
> + regmap_usb_debugfs_init(map);
> +
> + return map;
> +}
> +EXPORT_SYMBOL(__devm_regmap_init_usb);
No, this needs to be EXPORT_SYMBOL_GPL - the regmap core is and this
isn't going to be useful without those bits of the code anyway.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4,04/36] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check
On Mon, Feb 17, 2020 at 11:55:50AM +0100, Andrzej Pietrasiewicz wrote:
> Hi James,
>
> Thank you for the review.
>
> Did you intentionally review patches from the v4 series or you simply
> didn't notice the v5? There are some differences, the most notable one
> is using proper way of subclassing a drm_framebuffer.
> The v5 series was sent on 17th December 2019.
Hi Andrzej:
Sorry, I did the review based pathwork:
https://patchwork.freedesktop.org/series/70889/#rev35
seems it has problem which only have V4.
I will re-do the review for V5 ASAP.
Sorry again.
James.
> Andrzej
>
> W dniu 17.02.2020 o�09:16, james qian wang (Arm Technology China) pisze:
> > Hi Andrzej:
> >
> > Really a good idea for introducing this custom size check, it's very
> > useful for some Komeda/malidp format, espcially pitch_multiplier, maybe
> > in future we can add it into into the drm_format_info.
> >
> > On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:
> > > The new version accepts a struct describing deviations from standard way
> > > of
> > > doing the size checks. The caller must provide the respective values.
> > >
> > > Signed-off-by: Andrzej Pietrasiewicz
> > > ---
> > > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47
> > > include/drm/drm_gem_framebuffer_helper.h | 16 +++
> > > 2 files changed, 55 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > index 787edb9a916b..4201dc1f32a5 100644
> > > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > > @@ -201,8 +201,9 @@ int drm_gem_fb_lookup(struct drm_device *dev,
> > > EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
> > > /**
> > > - * drm_gem_fb_size_check() - Helper function for use in
> > > - *_mode_config_funcs.fb_create
> > > implementations
> > > + * drm_gem_fb_size_check_special() - Helper function for use in
> > > + *_mode_config_funcs.fb_create
> > > + *implementations
> > >* @dev: DRM device
> > >* @mode_cmd: Metadata from the userspace framebuffer creation request
> > >*
> > > @@ -212,9 +213,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
> > >* Returns:
> > >* Zero on success or a negative error code on failure.
> > >*/
> > > -int drm_gem_fb_size_check(struct drm_device *dev,
> > > - const struct drm_mode_fb_cmd2 *mode_cmd,
> > > - struct drm_gem_object **objs)
> > > +int drm_gem_fb_size_check_special(struct drm_device *dev,
> >
> > How about name it to drm_gem_fb_custom_size_check()
> >
> > > + const struct drm_mode_fb_cmd2 *mode_cmd,
> > > + const struct drm_size_check *check,
> > > + struct drm_gem_object **objs)
> > > {
> > > const struct drm_format_info *info;
> > > int i;
> > > @@ -227,10 +229,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> > > unsigned int width = mode_cmd->width / (i ? info->hsub
> > > : 1);
> > > unsigned int height = mode_cmd->height / (i ?
> > > info->vsub : 1);
> > > unsigned int min_size;
> > > + u32 pitch = mode_cmd->pitches[i];
> > > +
> > > + if (check && check->use_pitch_multiplier)
> > > + if ((pitch * check->pitch_multiplier[i]) %
> > > + check->pitch_modulo)
> > > + return -EINVAL;
> > > - min_size = (height - 1) * mode_cmd->pitches[i]
> > > - + drm_format_info_min_pitch(info, i, width)
> > > - + mode_cmd->offsets[i];
> > > + if (check && check->use_min_size)
> > > + min_size = check->min_size[i];
> > > + else
> > > + min_size = (height - 1) * pitch
> > > + + drm_format_info_min_pitch(info, i, width)
> > > + + mode_cmd->offsets[i];
> > > if (objs[i]->size < min_size)
> > > return -EINVAL;
> > > @@ -239,6 +250,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
> > > return 0;
> > > }
> > > +EXPORT_SYMBOL_GPL(drm_gem_fb_size_check_special);
> > > +
> > > +/**
> > > + * drm_gem_fb_size_check() - Helper function for use in
> > > + *_mode_config_funcs.fb_create
> > > implementations
> > > + * @dev: DRM device
> > > + * @mode_cmd: Metadata from the userspace framebuffer creation request
> > > + *
> > > + * This function can be used to verify buffer sizes for all planes.
> > > + * It is caller's responsibility to put the objects on failure.
> > > + *
> > > + * Returns:
> > > + * Zero on success or a negative error code on failure.
> > > + */
> > > +int drm_gem_fb_size_check(struct
Re: [PATCH 3/7] drm/vmwgfx: don't use ttm bo->offset
On 2/17/20 12:09 PM, Christian König wrote: Am 17.02.20 um 11:18 schrieb Nirmoy Das: Calculate GPU offset within vmwgfx driver itself without depending on bo->offset Signed-off-by: Nirmoy Das --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- 4 files changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index 8b71bf6b58ef..a714582bb61c 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private *dev_priv, ret = ttm_bo_validate(bo, , ); /* For some reason we didn't end up at the start of vram */ - WARN_ON(ret == 0 && bo->offset != 0); + WARN_ON(ret == 0 && (bo->mem.start << PAGE_SHIFT) != 0); You could drop the (<< PAGE_SHIFT) part here. Thanks Christian! I will drop that in next version. Apart from that feel free to stick an Acked-by: Christian König on the patch. Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/vmwgfx: don't use ttm bo->offset
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
4 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 8b71bf6b58ef..a714582bb61c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -258,7 +258,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
ret = ttm_bo_validate(bo, , );
/* For some reason we didn't end up at the start of vram */
- WARN_ON(ret == 0 && bo->offset != 0);
+ WARN_ON(ret == 0 && (bo->mem.start << PAGE_SHIFT) != 0);
You could drop the (<< PAGE_SHIFT) part here.
Apart from that feel free to stick an Acked-by: Christian König
on the patch.
Christian.
if (!ret)
vmw_bo_pin_reserved(buf, true);
@@ -317,7 +317,7 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object *bo,
{
if (bo->mem.mem_type == TTM_PL_VRAM) {
ptr->gmrId = SVGA_GMR_FRAMEBUFFER;
- ptr->offset = bo->offset;
+ ptr->offset = bo->mem.start << PAGE_SHIFT;
} else {
ptr->gmrId = bo->mem.start;
ptr->offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 73489a45decb..72c2cf4053df 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3313,7 +3313,7 @@ static void vmw_apply_relocations(struct vmw_sw_context
*sw_context)
bo = >vbo->base;
switch (bo->mem.mem_type) {
case TTM_PL_VRAM:
- reloc->location->offset += bo->offset;
+ reloc->location->offset += bo->mem.start << PAGE_SHIFT;
reloc->location->gmrId = SVGA_GMR_FRAMEBUFFER;
break;
case VMW_PL_GMR:
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index e5252ef3812f..1cdc445b24c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -612,7 +612,7 @@ static int vmw_fifo_emit_dummy_legacy_query(struct
vmw_private *dev_priv,
if (bo->mem.mem_type == TTM_PL_VRAM) {
cmd->body.guestResult.gmrId = SVGA_GMR_FRAMEBUFFER;
- cmd->body.guestResult.offset = bo->offset;
+ cmd->body.guestResult.offset = bo->mem.start << PAGE_SHIFT;
} else {
cmd->body.guestResult.gmrId = bo->mem.start;
cmd->body.guestResult.offset = 0;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..e7134aebeb81 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -750,7 +750,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
@@ -763,7 +762,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
* slots as well as the bo size.
*/
man->func = _gmrid_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_CMA | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
man->default_caching = TTM_PL_FLAG_CACHED;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/amdgpu: move ttm bo->offset to amdgpu_bo
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 29 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
4 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index e3f16b49e970..04e78f783638 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -917,7 +917,7 @@ int amdgpu_bo_pin_restricted(struct amdgpu_bo *bo, u32
domain,
bo->pin_count++;
if (max_offset != 0) {
- u64 domain_start =
bo->tbo.bdev->man[mem_type].gpu_offset;
+ u64 domain_start = amdgpu_ttm_domain_start(adev,
mem_type);
WARN_ON_ONCE(max_offset <
(amdgpu_bo_gpu_offset(bo) - domain_start));
}
@@ -1445,7 +1445,25 @@ u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo)
WARN_ON_ONCE(bo->tbo.mem.mem_type == TTM_PL_VRAM &&
!(bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS));
- return amdgpu_gmc_sign_extend(bo->tbo.offset);
+ return amdgpu_bo_gpu_offset_no_check(bo);
+}
+
+/**
+ * amdgpu_bo_gpu_offset_no_check - return GPU offset of bo
+ * @bo:amdgpu object for which we query the offset
+ *
+ * Returns:
+ * current GPU offset of the object without raising warnings.
+ */
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo)
+{
+ struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+ uint64_t offset;
+
+offset = (bo->tbo.mem.start << PAGE_SHIFT) +
+amdgpu_ttm_domain_start(adev, bo->tbo.mem.mem_type);
+
+ return amdgpu_gmc_sign_extend(offset);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 36dec51d1ef1..1d86b4c7a1f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -279,6 +279,7 @@ void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence
*fence,
bool shared);
int amdgpu_bo_sync_wait(struct amdgpu_bo *bo, void *owner, bool intr);
u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
+u64 amdgpu_bo_gpu_offset_no_check(struct amdgpu_bo *bo);
int amdgpu_bo_validate(struct amdgpu_bo *bo);
int amdgpu_bo_restore_shadow(struct amdgpu_bo *shadow,
struct dma_fence **fence);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 3ab46d4647e4..e329a108e760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -97,7 +97,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_TT:
/* GTT memory */
man->func = _gtt_mgr_func;
- man->gpu_offset = adev->gmc.gart_start;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
@@ -105,7 +104,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _vram_mgr_func;
- man->gpu_offset = adev->gmc.vram_start;
man->flags = TTM_MEMTYPE_FLAG_FIXED |
TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
@@ -116,7 +114,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = _bo_manager_func;
- man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
@@ -264,7 +261,7 @@ static uint64_t amdgpu_mm_node_addr(struct
ttm_buffer_object *bo,
if (mm_node->start != AMDGPU_BO_INVALID_OFFSET) {
addr = mm_node->start << PAGE_SHIFT;
- addr += bo->bdev->man[mem->mem_type].gpu_offset;
+ addr += amdgpu_ttm_domain_start(amdgpu_ttm_adev(bo->bdev),
mem->mem_type);
}
return addr;
}
@@ -751,6 +748,27 @@ static unsigned long amdgpu_ttm_io_mem_pfn(struct
ttm_buffer_object *bo,
(offset >> PAGE_SHIFT);
}
+/**
+ * amdgpu_ttm_domain_start - Returns GPU
Re: [PATCHv4,05/36] drm/gem-fb-helper: Add generic afbc size checks
Hi Andrzej:
On Fri, Dec 13, 2019 at 04:58:36PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 10 +++-
> drivers/gpu/drm/drm_framebuffer.c| 3 +
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 60 ++--
> include/drm/drm_gem_framebuffer_helper.h | 16 ++
> 4 files changed, 82 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d14dd7c86020..9ac2175c5bee 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -323,8 +323,14 @@ drm_get_format_info(struct drm_device *dev,
> {
> const struct drm_format_info *info = NULL;
>
> - if (dev->mode_config.funcs->get_format_info)
> - info = dev->mode_config.funcs->get_format_info(mode_cmd);
> + /* bypass driver callback if afbc */
> + if (!drm_is_afbc(mode_cmd->modifier[0]))
> + if (dev->mode_config.funcs->get_format_info) {
> + const struct drm_mode_config_funcs *funcs;
> +
> + funcs = dev->mode_config.funcs;
> + info = funcs->get_format_info(mode_cmd);
> + }
>
> if (!info)
> info = drm_format_info(mode_cmd->pixel_format);
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index 57564318ceea..33b741cc73e8 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -204,6 +204,9 @@ static int framebuffer_check(struct drm_device *dev,
> unsigned int block_size = info->char_per_block[i];
> u64 min_pitch = drm_format_info_min_pitch(info, i, width);
>
> + if (drm_is_afbc(r->modifier[i]))
> + block_size = 0;
> +
> if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
> DRM_DEBUG_KMS("Format requires non-linear modifier for
> plane %d\n", i);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 4201dc1f32a5..e20f4d00b0a5 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -21,6 +21,11 @@
> #include
> #include
>
> +#define AFBC_HEADER_SIZE 16
> +#define AFBC_TH_LAYOUT_ALIGNMENT 8
> +#define AFBC_SUPERBLOCK_PIXELS 256
> +#define AFBC_SUPERBLOCK_ALIGNMENT128
> +
> /**
> * DOC: overview
> *
> @@ -200,6 +205,40 @@ int drm_gem_fb_lookup(struct drm_device *dev,
> }
> EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
>
> +static int drm_gem_afbc_min_size(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_afbc *afbc)
> +{
> + u32 n_blocks;
> +
> + if (!drm_afbc_get_superblock_wh(mode_cmd->modifier[0],
> + >block_width,
> + >block_height)) {
> + return -EINVAL;
> + }
> +
> + /* tiled header afbc */
> + if (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_TILED) {
> + afbc->block_width *= AFBC_TH_LAYOUT_ALIGNMENT;
> + afbc->block_height *= AFBC_TH_LAYOUT_ALIGNMENT;
> + }
> +
> + afbc->aligned_width = ALIGN(mode_cmd->width, afbc->block_width);
> + afbc->aligned_height = ALIGN(mode_cmd->height, afbc->block_height);
> + afbc->offset = mode_cmd->offsets[0];
> +
> + n_blocks = (afbc->aligned_width * afbc->aligned_height)
> + / AFBC_SUPERBLOCK_PIXELS;
> + afbc->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
> + afbc->alignment_header);
After check the references in malidp, rockchip and komeda, seems this
afbc->alignment_header is dedicated for komeda only.
This is not true. Per afbc HW spec alignment is essential for
all afbc usage. according to the spec the requiremnt are:
AFBC1.0/1.1: 64 byte alignment both for header and body buffer.
AFBC1.2 (tiled header enabled): 4096 alignment.
So this alignement is not a vendor specific value, but afbc feature
requirement, can be determined by afbc modifier.
(malidp and komeda obeys this spec, not sure about Rockchip, but I
think it should be)
But you may see, komeda uses 1024 (not 64) for none-tiled-header afbc,
that's because GPU(MALI) changed this value to 1024 for bus
performance (sorry I don't know the detail), and komeda changed to
1024 to follow.
Back to display alignment, I think we can just follow the spec, use 64
for none-tiled-header, 4096 for tiled-header, but no need to caller to
pass a value.
> +
> + afbc->afbc_size = afbc->offset_payload + n_blocks *
> + ALIGN(afbc->bpp * AFBC_SUPERBLOCK_PIXELS / 8,
> +
Re: [PATCHv4,04/36] drm/gem-fb-helper: Add special version of drm_gem_fb_size_check
Hi James,
Thank you for the review.
Did you intentionally review patches from the v4 series or you simply
didn't notice the v5? There are some differences, the most notable one
is using proper way of subclassing a drm_framebuffer.
The v5 series was sent on 17th December 2019.
Andrzej
W dniu 17.02.2020 o 09:16, james qian wang (Arm Technology China) pisze:
Hi Andrzej:
Really a good idea for introducing this custom size check, it's very
useful for some Komeda/malidp format, espcially pitch_multiplier, maybe
in future we can add it into into the drm_format_info.
On Fri, Dec 13, 2019 at 04:58:35PM +0100, Andrzej Pietrasiewicz wrote:
The new version accepts a struct describing deviations from standard way of
doing the size checks. The caller must provide the respective values.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 47
include/drm/drm_gem_framebuffer_helper.h | 16 +++
2 files changed, 55 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 787edb9a916b..4201dc1f32a5 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -201,8 +201,9 @@ int drm_gem_fb_lookup(struct drm_device *dev,
EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
/**
- * drm_gem_fb_size_check() - Helper function for use in
- * _mode_config_funcs.fb_create implementations
+ * drm_gem_fb_size_check_special() - Helper function for use in
+ * _mode_config_funcs.fb_create
+ * implementations
* @dev: DRM device
* @mode_cmd: Metadata from the userspace framebuffer creation request
*
@@ -212,9 +213,10 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_lookup);
* Returns:
* Zero on success or a negative error code on failure.
*/
-int drm_gem_fb_size_check(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object **objs)
+int drm_gem_fb_size_check_special(struct drm_device *dev,
How about name it to drm_gem_fb_custom_size_check()
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ const struct drm_size_check *check,
+ struct drm_gem_object **objs)
{
const struct drm_format_info *info;
int i;
@@ -227,10 +229,19 @@ int drm_gem_fb_size_check(struct drm_device *dev,
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
unsigned int min_size;
+ u32 pitch = mode_cmd->pitches[i];
+
+ if (check && check->use_pitch_multiplier)
+ if ((pitch * check->pitch_multiplier[i]) %
+ check->pitch_modulo)
+ return -EINVAL;
- min_size = (height - 1) * mode_cmd->pitches[i]
-+ drm_format_info_min_pitch(info, i, width)
-+ mode_cmd->offsets[i];
+ if (check && check->use_min_size)
+ min_size = check->min_size[i];
+ else
+ min_size = (height - 1) * pitch
++ drm_format_info_min_pitch(info, i, width)
++ mode_cmd->offsets[i];
if (objs[i]->size < min_size)
return -EINVAL;
@@ -239,6 +250,26 @@ int drm_gem_fb_size_check(struct drm_device *dev,
return 0;
}
+EXPORT_SYMBOL_GPL(drm_gem_fb_size_check_special);
+
+/**
+ * drm_gem_fb_size_check() - Helper function for use in
+ * _mode_config_funcs.fb_create implementations
+ * @dev: DRM device
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function can be used to verify buffer sizes for all planes.
+ * It is caller's responsibility to put the objects on failure.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int drm_gem_fb_size_check(struct drm_device *dev,
+ const struct drm_mode_fb_cmd2 *mode_cmd,
+ struct drm_gem_object **objs)
+{
+ return drm_gem_fb_size_check_special(dev, mode_cmd, NULL, objs);
+}
EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
/**
diff --git a/include/drm/drm_gem_framebuffer_helper.h
b/include/drm/drm_gem_framebuffer_helper.h
index c85d4b152e91..74304a268694 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -11,6 +11,18 @@ struct drm_mode_fb_cmd2;
struct drm_plane;
struct drm_plane_state;
struct drm_simple_display_pipe;
+struct drm_size_check;
+
+/**
+ * struct drm_size_check - Description of special requirements for size checks.
+ */
+struct
Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)
Hi, On 16/02/2020 18:21, Noralf Trønnes wrote: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DSI/DPI display adapter. > > Thinking about how to represent the display to the driver I realised > that hardware use registers as API. And Linux does have a generic > register abstraction: regmap. Furthermore this means that if I can do a > regmap over USB implementation, it will be easy to do other functions > like gpio, adc and others. After a few iterations trying to understand > the USB subsystem and satisfying driver requirements, I now have > something that looks promising. > > I'm sending out an early version hoping to get feedback especially on > the core parts that handles regmap and interrupts. > > Overview: > > USB Host : USB Device > : > -- : -- > -- | mfd: mud | : | f_mud | -- > | Driver | -- : || | Driver | > -- | regmap-usb | : | (mud_regmap) | -- > -- : -- > The idea is really like ARA's greybus, but much simpler ! Anyway nice idea, do you have good performance over USB2 and RPi's awful DWC2 gagdet controller ? Neil > > I've attached 2 drivers: > - gpio/pinctrl: is more or less finished > - display: needs a lot more work > > > USB3 device > I've only tested this with usb2 devices (Pi, BBB) so I should get myself > a usb3 gadget capable board. My searching didn't turn up much, so this > seems to be quite rare. ROCK960 has USB 3.0 type C OTG but the price is > $139 which is a bit expensive for this hobby project. Does anyone know > of a cheap board? > > Noralf. > > > Noralf Trønnes (9): > regmap: Add USB support > mfd: Add driver for Multifunction USB Device > usb: gadget: function: Add Multifunction USB Device support > pinctrl: Add Multifunction USB Device pinctrl driver > usb: gadget: function: mud: Add gpio support > regmap: Speed up _regmap_raw_write_impl() for large buffers > drm: Add Multifunction USB Device display driver > drm/client: Add drm_client_init_from_id() and drm_client_modeset_set() > usb: gadget: function: mud: Add display support > > drivers/base/regmap/Kconfig |8 +- > drivers/base/regmap/Makefile |1 + > drivers/base/regmap/regmap-usb.c | 1026 ++ > drivers/base/regmap/regmap.c | 10 +- > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/drm_client.c | 37 + > drivers/gpu/drm/drm_client_modeset.c | 52 + > drivers/gpu/drm/mud/Kconfig | 18 + > drivers/gpu/drm/mud/Makefile |4 + > drivers/gpu/drm/mud/mud_drm.c| 1198 ++ > drivers/gpu/drm/mud/mud_drm.h| 137 +++ > drivers/gpu/drm/mud/mud_drm_gadget.c | 889 > drivers/mfd/Kconfig |8 + > drivers/mfd/Makefile |1 + > drivers/mfd/mud.c| 580 +++ > drivers/pinctrl/Kconfig |9 + > drivers/pinctrl/Makefile |1 + > drivers/pinctrl/pinctrl-mud.c| 657 > drivers/pinctrl/pinctrl-mud.h| 89 ++ > drivers/usb/gadget/Kconfig | 36 + > drivers/usb/gadget/function/Makefile |6 + > drivers/usb/gadget/function/f_mud.c | 913 + > drivers/usb/gadget/function/f_mud.h | 210 > drivers/usb/gadget/function/f_mud_drm.c | 181 > drivers/usb/gadget/function/f_mud_pins.c | 962 + > drivers/usb/gadget/function/mud_regmap.c | 936 + > include/drm/drm_client.h |4 + > include/linux/mfd/mud.h | 16 + > include/linux/regmap.h | 23 + > include/linux/regmap_usb.h | 97 ++ > 31 files changed, 8107 insertions(+), 5 deletions(-) > create mode 100644 drivers/base/regmap/regmap-usb.c > create mode 100644 drivers/gpu/drm/mud/Kconfig > create mode 100644 drivers/gpu/drm/mud/Makefile > create mode 100644 drivers/gpu/drm/mud/mud_drm.c > create mode 100644 drivers/gpu/drm/mud/mud_drm.h > create mode 100644 drivers/gpu/drm/mud/mud_drm_gadget.c > create mode 100644 drivers/mfd/mud.c > create mode 100644 drivers/pinctrl/pinctrl-mud.c > create mode 100644 drivers/pinctrl/pinctrl-mud.h > create mode 100644 drivers/usb/gadget/function/f_mud.c > create mode 100644 drivers/usb/gadget/function/f_mud.h > create mode 100644 drivers/usb/gadget/function/f_mud_drm.c > create mode 100644 drivers/usb/gadget/function/f_mud_pins.c > create mode 100644 drivers/usb/gadget/function/mud_regmap.c > create mode 100644 include/linux/mfd/mud.h > create mode 100644 include/linux/regmap_usb.h >
Re: [PATCH v6 04/51] drm/bridge: Add connector-related bridge operations and data
On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval operations
> - Bitmask of supported operations
> - Bridge output type
> - I2C adapter for DDC access
>
> Add and document these.
>
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Boris Brezillon
> Reviewed-by: Sam Ravnborg
> ---
> Changes since v3:
>
> - Fix typos
>
> Changes since v2:
>
> - Add wrappers around the .detect(), .get_modes() and .get_edid()
> operations
> - Warn bridge drivers about valid usage of the connector argument to
> .get_modes() and .get_edid()
>
> Changes since v1:
>
> - Make .hpd_enable() and .hpd_disable() optional
> - Rename .lost_hotplug() to .hpd_notify()
> - Add ddc field to drm_bridge
> ---
> drivers/gpu/drm/drm_bridge.c | 162 +
> include/drm/drm_bridge.h | 192 ++-
> 2 files changed, 353 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 68ab933ee430..78d26a9a3ee6 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -71,6 +71,8 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> + mutex_init(>hpd_mutex);
> +
> mutex_lock(_lock);
> list_add_tail(>list, _list);
> mutex_unlock(_lock);
> @@ -87,6 +89,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> mutex_lock(_lock);
> list_del_init(>list);
> mutex_unlock(_lock);
> +
> + mutex_destroy(>hpd_mutex);
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> @@ -919,6 +923,164 @@ int drm_atomic_bridge_chain_check(struct drm_bridge
> *bridge,
> }
> EXPORT_SYMBOL(drm_atomic_bridge_chain_check);
>
> +/**
> + * drm_bridge_detect - check if anything is attached to the bridge output
> + * @bridge: bridge control structure
> + *
> + * If the bridge supports output detection, as reported by the
> + * DRM_BRIDGE_OP_DETECT bridge ops flag, call _bridge_funcs.detect for
> the
> + * bridge and return the connection status. Otherwise return
> + * connector_status_unknown.
> + *
> + * RETURNS:
> + * The detection status on success, or connector_status_unknown if the bridge
> + * doesn't support output detection.
> + */
> +enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_DETECT))
> + return connector_status_unknown;
> +
> + return bridge->funcs->detect(bridge);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_detect);
> +
> +/**
> + * drm_bridge_get_modes - fill all modes currently valid for the sink into
> the
> + * @connector
> + * @bridge: bridge control structure
> + * @connector: the connector to fill with modes
> + *
> + * If the bridge supports output modes retrieval, as reported by the
> + * DRM_BRIDGE_OP_MODES bridge ops flag, call _bridge_funcs.get_modes to
> + * fill the connector with all valid modes and return the number of modes
> + * added. Otherwise return 0.
> + *
> + * RETURNS:
> + * The number of modes added to the connector.
> + */
> +int drm_bridge_get_modes(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_MODES))
> + return 0;
> +
> + return bridge->funcs->get_modes(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> +
> +/**
> + * drm_bridge_get_edid - get the EDID data of the connected display
> + * @bridge: bridge control structure
> + * @connector: the connector to read EDID for
> + *
> + * If the bridge supports output EDID retrieval, as reported by the
> + * DRM_BRIDGE_OP_EDID bridge ops flag, call _bridge_funcs.get_edid to
> + * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> + *
> + * RETURNS:
> + * The retrieved EDID on success, or an error pointer otherwise.
> + */
> +struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> + return ERR_PTR(-ENOTSUPP);
> +
> + return bridge->funcs->get_edid(bridge, connector);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_get_edid);
> +
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call _bridge_funcs.hpd_enable if implemented and register the given
> @cb
> + * and @data as hot plug notification callback. From now on the @cb will be
> + * called
[PATCH] drm/edid: temporary workaround to pass HDMI 2.0 compliance HF1-13
Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
And check scrambling feature was disabled as well.
But QD980 report it can support low rate scrambling. The vendor
specific data block byte[6] was 0x88. If driver enabled scrambling
rely on this info. Then HF1-13 would not get pass because DUT have
to disable scrambling to run this case.
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Clint Taylor
Cc: Cooper Chiou
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/drm_edid.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..0b4badc20c35 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -85,6 +85,8 @@
#define EDID_QUIRK_FORCE_10BPC (1 << 11)
/* Non desktop display (i.e. HMD) */
#define EDID_QUIRK_NON_DESKTOP (1 << 12)
+/* Do not enable low rates scrambling */
+#define EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING (1 << 13)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -214,6 +216,9 @@ static const struct edid_quirk {
/* OSVR HDK and HDK2 VR Headsets */
{ "SVR", 0x1019, EDID_QUIRK_NON_DESKTOP },
+
+ /* Quantumdata 980 test platform */
+ { "QDI", 0x03D4, EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING },
};
/*
@@ -4710,10 +4715,11 @@ static void drm_parse_ycbcr420_deep_color_info(struct
drm_connector *connector,
}
static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
-const u8 *hf_vsdb)
+const u8 *hf_vsdb, const struct edid *edid)
{
struct drm_display_info *display = >display_info;
struct drm_hdmi_info *hdmi = >hdmi;
+ u32 quirks = edid_get_quirks(edid);
display->has_hdmi_infoframe = true;
@@ -4747,7 +4753,8 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
scdc->scrambling.supported = true;
/* Few sinks support scrambling for clocks < 340M */
- if ((hf_vsdb[6] & 0x8))
+ if ((hf_vsdb[6] & 0x8) &&
+ !(quirks & EDID_QUIRK_DISABLE_LOW_RATE_SCRAMBLING))
scdc->scrambling.low_rates = true;
}
}
@@ -4870,7 +4877,7 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
if (cea_db_is_hdmi_forum_vsdb(db))
- drm_parse_hdmi_forum_vsdb(connector, db);
+ drm_parse_hdmi_forum_vsdb(connector, db, edid);
if (cea_db_is_y420cmdb(db))
drm_parse_y420cmdb_bitmap(connector, db);
if (cea_db_is_vcdb(db))
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/51] drm/connector: Add helper to get a connector type name
On Sun, Feb 16, 2020 at 11:02:19PM +0200, Laurent Pinchart wrote:
> drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
> to name strings, but doesn't expose it. This leads to drivers having to
> store a similar map.
Maybe also a todo if there's many of these?
-Daniel
>
> Add a new drm_get_connector_type_name() helper function that return a
> name string for a connector type.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Boris Brezillon
> Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_connector.c | 15 +++
> include/drm/drm_connector.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f632ca05960e..644f0ad10671 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -111,6 +111,21 @@ void drm_connector_ida_destroy(void)
> ida_destroy(_connector_enum_list[i].ida);
> }
>
> +/**
> + * drm_get_connector_type_name - return a string for connector type
> + * @type: The connector type (DRM_MODE_CONNECTOR_*)
> + *
> + * Returns: the name of the connector type, or NULL if the type is not valid.
> + */
> +const char *drm_get_connector_type_name(unsigned int type)
> +{
> + if (type < ARRAY_SIZE(drm_connector_enum_list))
> + return drm_connector_enum_list[type].name;
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL(drm_get_connector_type_name);
> +
> /**
> * drm_connector_get_cmdline_mode - reads the user's cmdline mode
> * @connector: connector to quwery
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index b3815371c271..c3bd5262db9c 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1518,6 +1518,7 @@ drm_connector_is_unregistered(struct drm_connector
> *connector)
> DRM_CONNECTOR_UNREGISTERED;
> }
>
> +const char *drm_get_connector_type_name(unsigned int connector_type);
> const char *drm_get_connector_status_name(enum drm_connector_status status);
> const char *drm_get_subpixel_order_name(enum subpixel_order order);
> const char *drm_get_dpms_name(int val);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/9] Regmap over USB for Multifunction USB Device (gpio, display, ...)
On Sun, Feb 16, 2020 at 06:21:08PM +0100, Noralf Trønnes wrote: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DSI/DPI display adapter. > > Thinking about how to represent the display to the driver I realised > that hardware use registers as API. And Linux does have a generic > register abstraction: regmap. Furthermore this means that if I can do a > regmap over USB implementation, it will be easy to do other functions > like gpio, adc and others. After a few iterations trying to understand > the USB subsystem and satisfying driver requirements, I now have > something that looks promising. > > I'm sending out an early version hoping to get feedback especially on > the core parts that handles regmap and interrupts. > > Overview: > > USB Host : USB Device > : > -- : -- > -- | mfd: mud | : | f_mud | -- > | Driver | -- : || | Driver | > -- | regmap-usb | : | (mud_regmap) | -- > -- : -- > > > I've attached 2 drivers: > - gpio/pinctrl: is more or less finished > - display: needs a lot more work > > > USB3 device > I've only tested this with usb2 devices (Pi, BBB) so I should get myself > a usb3 gadget capable board. My searching didn't turn up much, so this > seems to be quite rare. ROCK960 has USB 3.0 type C OTG but the price is > $139 which is a bit expensive for this hobby project. Does anyone know > of a cheap board? > > Noralf. Pretty cool idea, and the drm side looks really tiny (after all your drm_client work that is). I think the important feedback here is for the usb and regmap stuff, that's totally out of my area. I've commented on the drm_client patch, but that's just minor stuff, imo looks good. Cheers, Daniel > > > Noralf Trønnes (9): > regmap: Add USB support > mfd: Add driver for Multifunction USB Device > usb: gadget: function: Add Multifunction USB Device support > pinctrl: Add Multifunction USB Device pinctrl driver > usb: gadget: function: mud: Add gpio support > regmap: Speed up _regmap_raw_write_impl() for large buffers > drm: Add Multifunction USB Device display driver > drm/client: Add drm_client_init_from_id() and drm_client_modeset_set() > usb: gadget: function: mud: Add display support > > drivers/base/regmap/Kconfig |8 +- > drivers/base/regmap/Makefile |1 + > drivers/base/regmap/regmap-usb.c | 1026 ++ > drivers/base/regmap/regmap.c | 10 +- > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/drm_client.c | 37 + > drivers/gpu/drm/drm_client_modeset.c | 52 + > drivers/gpu/drm/mud/Kconfig | 18 + > drivers/gpu/drm/mud/Makefile |4 + > drivers/gpu/drm/mud/mud_drm.c| 1198 ++ > drivers/gpu/drm/mud/mud_drm.h| 137 +++ > drivers/gpu/drm/mud/mud_drm_gadget.c | 889 > drivers/mfd/Kconfig |8 + > drivers/mfd/Makefile |1 + > drivers/mfd/mud.c| 580 +++ > drivers/pinctrl/Kconfig |9 + > drivers/pinctrl/Makefile |1 + > drivers/pinctrl/pinctrl-mud.c| 657 > drivers/pinctrl/pinctrl-mud.h| 89 ++ > drivers/usb/gadget/Kconfig | 36 + > drivers/usb/gadget/function/Makefile |6 + > drivers/usb/gadget/function/f_mud.c | 913 + > drivers/usb/gadget/function/f_mud.h | 210 > drivers/usb/gadget/function/f_mud_drm.c | 181 > drivers/usb/gadget/function/f_mud_pins.c | 962 + > drivers/usb/gadget/function/mud_regmap.c | 936 + > include/drm/drm_client.h |4 + > include/linux/mfd/mud.h | 16 + > include/linux/regmap.h | 23 + > include/linux/regmap_usb.h | 97 ++ > 31 files changed, 8107 insertions(+), 5 deletions(-) > create mode 100644 drivers/base/regmap/regmap-usb.c > create mode 100644 drivers/gpu/drm/mud/Kconfig > create mode 100644 drivers/gpu/drm/mud/Makefile > create mode 100644 drivers/gpu/drm/mud/mud_drm.c > create mode 100644 drivers/gpu/drm/mud/mud_drm.h > create mode 100644 drivers/gpu/drm/mud/mud_drm_gadget.c > create mode 100644 drivers/mfd/mud.c > create mode 100644 drivers/pinctrl/pinctrl-mud.c > create mode 100644 drivers/pinctrl/pinctrl-mud.h > create mode 100644 drivers/usb/gadget/function/f_mud.c > create mode 100644 drivers/usb/gadget/function/f_mud.h > create mode 100644 drivers/usb/gadget/function/f_mud_drm.c > create mode 100644 drivers/usb/gadget/function/f_mud_pins.c > create
Re: [RFC 8/9] drm/client: Add drm_client_init_from_id() and drm_client_modeset_set()
On Sun, Feb 16, 2020 at 06:21:16PM +0100, Noralf Trønnes wrote:
> drm_client_init_from_id() provides a way for clients to add a client based
> on the minor. drm_client_modeset_set() provides a way to set the modeset
> for clients that handles connectors and display mode on their own.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_client.c | 37
> drivers/gpu/drm/drm_client_modeset.c | 52
> include/drm/drm_client.h | 4 +++
> 3 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index d9a2e3695525..dbd73fe8d987 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -112,6 +112,43 @@ int drm_client_init(struct drm_device *dev, struct
> drm_client_dev *client,
> }
> EXPORT_SYMBOL(drm_client_init);
>
> +/**
> + * drm_client_init_from_id - Initialise a DRM client
> + * @minor_id: DRM minor id
> + * @client: DRM client
> + * @name: Client name
> + * @funcs: DRM client functions (optional)
> + *
> + * This function looks up the drm_device using the minor id and initializes
> the client.
> + * It also registeres the client to avoid a possible race with DRM device
> unregister.
I think another sentence here would be good, explaining that this is for
drivers outside of drm to expose a specific drm driver in some fashion,
and just outright mention your use-case as an example.
I'm also not sure whether lookup-by-minor is the greatest thing for
kernel-internal lookups like this, maybe Greg has some idea?
> + *
> + * See drm_client_init() and drm_client_register().
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_client_init_from_id(unsigned int minor_id, struct drm_client_dev
> *client,
> + const char *name, const struct drm_client_funcs
> *funcs)
> +{
> + struct drm_minor *minor;
> + int ret;
> +
> + minor = drm_minor_acquire(minor_id);
> + if (IS_ERR(minor))
> + return PTR_ERR(minor);
> +
> + mutex_lock(>dev->clientlist_mutex);
> + ret = drm_client_init(minor->dev, client, name, funcs);
> + if (!ret)
> + list_add(>list, >dev->clientlist);
> + mutex_unlock(>dev->clientlist_mutex);
> +
> + drm_minor_release(minor);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_client_init_from_id);
> +
> /**
> * drm_client_register - Register client
> * @client: DRM client
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 895b73f23079..9396267e646c 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -807,6 +807,58 @@ int drm_client_modeset_probe(struct drm_client_dev
> *client, unsigned int width,
> }
> EXPORT_SYMBOL(drm_client_modeset_probe);
>
> +/**
> + * drm_client_modeset_set() - Set modeset
> + * @client: DRM client
> + * @connector: Connector
> + * @mode: Display mode
> + * @fb: Framebuffer
> + *
> + * This function releases any current modeset info and sets the new modeset
> in
> + * the client's modeset array.
> + *
> + * Returns:
> + * Zero on success or negative error code on failure.
> + */
> +int drm_client_modeset_set(struct drm_client_dev *client, struct
> drm_connector *connector,
> +struct drm_display_mode *mode, struct
> drm_framebuffer *fb)
Hm, since you need the functionality would be kinda neat to wire this up
for the fbdev emulation too. Ofc without reallocating the framebuffer
(fbdev can't do that), so would be limited to lower resolutions than we
booted with.
-Daniel
> +{
> + struct drm_mode_set *modeset;
> + int ret = -ENOENT;
> +
> + mutex_lock(>modeset_mutex);
> +
> + drm_client_modeset_release(client);
> +
> + if (!connector || !mode || !fb) {
> + ret = 0;
> + goto unlock;
> + }
> +
> + drm_client_for_each_modeset(modeset, client) {
> + if (!connector_has_possible_crtc(connector, modeset->crtc))
> + continue;
> +
> + modeset->mode = drm_mode_duplicate(client->dev, mode);
> + if (!modeset->mode) {
> + ret = -ENOMEM;
> + break;
> + }
> +
> + drm_connector_get(connector);
> + modeset->connectors[modeset->num_connectors++] = connector;
> +
> + modeset->fb = fb;
> + ret = 0;
> + break;
> + }
> +unlock:
> + mutex_unlock(>modeset_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_client_modeset_set);
> +
> /**
> * drm_client_rotation() - Check the initial rotation value
> * @modeset: DRM modeset
> diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> index 5cf2c5dd8b1e..97e4157d07c5 100644
> --- a/include/drm/drm_client.h
> +++ b/include/drm/drm_client.h
> @@ -104,6 +104,8 @@ struct drm_client_dev {
>
>
Re: [PATCH 2/3] gpu/drm: ingenic: Switch emulated fbdev to 16bpp
On Sun, Feb 16, 2020 at 12:58:10PM -0300, Paul Cercueil wrote: > The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1 > based games at 16bpp (rgb565). Recent applications generally talk to > DRM directly, and can request their favourite pixel format; so we can > make everybody happy by switching the emulated fbdev to 16bpp. > > Signed-off-by: Paul Cercueil > --- > drivers/gpu/drm/ingenic/ingenic-drm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c > b/drivers/gpu/drm/ingenic/ingenic-drm.c > index 034961a40e98..9aa88fabbd2a 100644 > --- a/drivers/gpu/drm/ingenic/ingenic-drm.c > +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c > @@ -808,7 +808,7 @@ static int ingenic_drm_probe(struct platform_device *pdev) > goto err_devclk_disable; > } > > - ret = drm_fbdev_generic_setup(drm, 32); > + ret = drm_fbdev_generic_setup(drm, 16); If you're really bored, could we make everyone even more happy by exposing format switching in the drm fbdev emulation? Only for the drivers which have a full format list on the primary plane (gets too tricky otherwise). And obviously only formats that have lower bpp than the one we booted with (can't reallocate the framebuffer because fbdev). Just as an idea, this shouldn't be too horrible amounts of work to wire up. But ofc more than this oneliner :-) Cheers, Daniel > if (ret) > dev_warn(dev, "Unable to start fbdev emulation: %i", ret); > > -- > 2.25.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix a typo in Kconfig
On Sun, Feb 16, 2020 at 12:47:08PM +0100, Christophe JAILLET wrote: > A 'h' ismissing in' syncronization' > > Signed-off-by: Christophe JAILLET Applied, thanks for your patch. -Daniel > --- > drivers/dma-buf/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig > index 0613bb7770f5..e7d820ce0724 100644 > --- a/drivers/dma-buf/Kconfig > +++ b/drivers/dma-buf/Kconfig > @@ -6,7 +6,7 @@ config SYNC_FILE > default n > select DMA_SHARED_BUFFER > ---help--- > - The Sync File Framework adds explicit syncronization via > + The Sync File Framework adds explicit synchronization via > userspace. It enables send/receive 'struct dma_fence' objects to/from > userspace via Sync File fds for synchronization between drivers via > userspace components. It has been ported from Android. > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/format_helper: Dual licence the file in GPL 2 and MIT
On Sat, Feb 15, 2020 at 07:09:11PM +0100, Emmanuel Vadot wrote: > From: Emmanuel Vadot > > Contributors for this file are : > Gerd Hoffmann > Maxime Ripard > Noralf Trønnes > > Signed-off-by: Emmanuel Vadot Patch applied since we have all the acks we need. I think for the first one we still need a few more. -Daniel > --- > drivers/gpu/drm/drm_format_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_format_helper.c > b/drivers/gpu/drm/drm_format_helper.c > index 0897cb9aeaff..3b818f2b2392 100644 > --- a/drivers/gpu/drm/drm_format_helper.c > +++ b/drivers/gpu/drm/drm_format_helper.c > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +// SPDX-License-Identifier: GPL-2.0 or MIT > /* > * Copyright (C) 2016 Noralf Trønnes > * > -- > 2.25.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Correct typos in comments
On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish
> Co-authored-by: Thomas Klausner
Also, we need a s-o-b from every co-author, because of the dco:
https://developercertificate.org/
Thanks, Daniel
> ---
> drivers/gpu/drm/amd/include/atombios.h | 20 ++--
> drivers/gpu/drm/amd/include/atomfirmware.h | 4 ++--
> drivers/gpu/drm/radeon/atombios.h | 8
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
> 4 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/atombios.h
> b/drivers/gpu/drm/amd/include/atombios.h
> index 8ba21747b40a..2f124c1a9c8e 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6
> #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK 0x0c
> #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP 0x00
> #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP 0x04
> -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the
> correct defintion for 36bpp should be 2 for 36bpp(2:1)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the
> correct definition for 36bpp should be 2 for 36bpp(2:1)
> #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP 0x08
> -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the
> correct defintion for 30bpp should be 1 for 36bpp(5:4)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the
> correct definition for 30bpp should be 1 for 36bpp(5:4)
> #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP 0x0c
> #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10
> #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40
> @@ -2420,7 +2420,7 @@ typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS
> typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS_V2
> {
>USHORT usPixelClock; // in 10KHz; for bios convenient
> - UCHAR ucMisc;// see PANEL_ENCODER_MISC_xx defintions below
> + UCHAR ucMisc;// see PANEL_ENCODER_MISC_xx definitions below
>UCHAR ucAction; // 0: turn off encoder
> // 1: setup and turn on encoder
>UCHAR ucTruncate;// bit0=0: Disable truncate
> @@ -2873,7 +2873,7 @@ typedef struct _ATOM_MULTIMEDIA_CONFIG_INFO
> // Structures used in FirmwareInfoTable
>
> //
>
> -// usBIOSCapability Defintion:
> +// usBIOSCapability Definition:
> // Bit 0 = 0: Bios image is not Posted, =1:Bios image is Posted;
> // Bit 1 = 0: Dual CRTC is not supported, =1: Dual CRTC is supported;
> // Bit 2 = 0: Extended Desktop is not supported, =1: Extended Desktop is
> supported;
> @@ -4213,7 +4213,7 @@ typedef struct _ATOM_DPCD_INFO
> #define ATOM_DPCD_MAX_LANE_MASK0x1F
>
> /**/
> -// VRAM usage and their defintions
> +// VRAM usage and their definitions
>
> // One chunk of VRAM used by Bios are for HWICON surfaces,EDID data.
> // Current Mode timing and Dail Timing and/or STD timing data EACH device.
> They can be broken down as below.
> @@ -6753,7 +6753,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LITEAC 3
> #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LIT2AC 4
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S0_CRT1_MONOb0 0x01
> #define ATOM_S0_CRT1_COLORb00x02
> #define ATOM_S0_CRT1_MASKb0
> (ATOM_S0_CRT1_MONOb0+ATOM_S0_CRT1_COLORb0)
> @@ -6819,7 +6819,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S2_DISPLAY_ROTATION_ANGLE_MASK 0xC000L
>
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S2_TV1_STANDARD_MASKb0 0x0F
> #define ATOM_S2_CURRENT_BL_LEVEL_MASKb1 0xFF
> #define ATOM_S2_DEVICE_DPMS_STATEb2 0x01
> @@ -6871,7 +6871,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>
>
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S3_CRT1_ACTIVEb0 0x01
> #define ATOM_S3_LCD1_ACTIVEb0 0x02
> #define ATOM_S3_TV1_ACTIVEb00x04
> @@ -6910,7 +6910,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S4_LCD1_REFRESH_MASK 0xFF00L
> #define ATOM_S4_LCD1_REFRESH_SHIFT 8
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S4_LCD1_PANEL_ID_MASKb00x0FF
> #define ATOM_S4_LCD1_REFRESH_MASKb1 ATOM_S4_LCD1_PANEL_ID_MASKb0
> #define ATOM_S4_VRAM_INFO_MASKb2ATOM_S4_LCD1_PANEL_ID_MASKb0
> @@ -6989,7 +6989,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S6_VRI_BRIGHTNESS_CHANGE 0x4000L
> #define
Re: [PATCH] Correct typos in comments
On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish
> Co-authored-by: Thomas Klausner
> ---
> drivers/gpu/drm/amd/include/atombios.h | 20 ++--
> drivers/gpu/drm/amd/include/atomfirmware.h | 4 ++--
> drivers/gpu/drm/radeon/atombios.h | 8
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
Can you please split this up per-driver, and prefix the commit message
with the usual driver prefix? git log drivers/gpu/drm/$driver will tell
you what it usually is.
Thanks, Daniel
> 4 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/atombios.h
> b/drivers/gpu/drm/amd/include/atombios.h
> index 8ba21747b40a..2f124c1a9c8e 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -1987,9 +1987,9 @@ typedef struct _PIXEL_CLOCK_PARAMETERS_V6
> #define PIXEL_CLOCK_V6_MISC_HDMI_BPP_MASK 0x0c
> #define PIXEL_CLOCK_V6_MISC_HDMI_24BPP 0x00
> #define PIXEL_CLOCK_V6_MISC_HDMI_36BPP 0x04
> -#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the
> correct defintion for 36bpp should be 2 for 36bpp(2:1)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_36BPP_V6 0x08//for V6, the
> correct definition for 36bpp should be 2 for 36bpp(2:1)
> #define PIXEL_CLOCK_V6_MISC_HDMI_30BPP 0x08
> -#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the
> correct defintion for 30bpp should be 1 for 36bpp(5:4)
> +#define PIXEL_CLOCK_V6_MISC_HDMI_30BPP_V6 0x04//for V6, the
> correct definition for 30bpp should be 1 for 36bpp(5:4)
> #define PIXEL_CLOCK_V6_MISC_HDMI_48BPP 0x0c
> #define PIXEL_CLOCK_V6_MISC_REF_DIV_SRC 0x10
> #define PIXEL_CLOCK_V6_MISC_GEN_DPREFCLK0x40
> @@ -2420,7 +2420,7 @@ typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS
> typedef struct _LVDS_ENCODER_CONTROL_PARAMETERS_V2
> {
>USHORT usPixelClock; // in 10KHz; for bios convenient
> - UCHAR ucMisc;// see PANEL_ENCODER_MISC_xx defintions below
> + UCHAR ucMisc;// see PANEL_ENCODER_MISC_xx definitions below
>UCHAR ucAction; // 0: turn off encoder
> // 1: setup and turn on encoder
>UCHAR ucTruncate;// bit0=0: Disable truncate
> @@ -2873,7 +2873,7 @@ typedef struct _ATOM_MULTIMEDIA_CONFIG_INFO
> // Structures used in FirmwareInfoTable
>
> //
>
> -// usBIOSCapability Defintion:
> +// usBIOSCapability Definition:
> // Bit 0 = 0: Bios image is not Posted, =1:Bios image is Posted;
> // Bit 1 = 0: Dual CRTC is not supported, =1: Dual CRTC is supported;
> // Bit 2 = 0: Extended Desktop is not supported, =1: Extended Desktop is
> supported;
> @@ -4213,7 +4213,7 @@ typedef struct _ATOM_DPCD_INFO
> #define ATOM_DPCD_MAX_LANE_MASK0x1F
>
> /**/
> -// VRAM usage and their defintions
> +// VRAM usage and their definitions
>
> // One chunk of VRAM used by Bios are for HWICON surfaces,EDID data.
> // Current Mode timing and Dail Timing and/or STD timing data EACH device.
> They can be broken down as below.
> @@ -6753,7 +6753,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LITEAC 3
> #define ATOM_S0_SYSTEM_POWER_STATE_VALUE_LIT2AC 4
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S0_CRT1_MONOb0 0x01
> #define ATOM_S0_CRT1_COLORb00x02
> #define ATOM_S0_CRT1_MASKb0
> (ATOM_S0_CRT1_MONOb0+ATOM_S0_CRT1_COLORb0)
> @@ -6819,7 +6819,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S2_DISPLAY_ROTATION_ANGLE_MASK 0xC000L
>
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S2_TV1_STANDARD_MASKb0 0x0F
> #define ATOM_S2_CURRENT_BL_LEVEL_MASKb1 0xFF
> #define ATOM_S2_DEVICE_DPMS_STATEb2 0x01
> @@ -6871,7 +6871,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>
>
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S3_CRT1_ACTIVEb0 0x01
> #define ATOM_S3_LCD1_ACTIVEb0 0x02
> #define ATOM_S3_TV1_ACTIVEb00x04
> @@ -6910,7 +6910,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
> #define ATOM_S4_LCD1_REFRESH_MASK 0xFF00L
> #define ATOM_S4_LCD1_REFRESH_SHIFT 8
>
> -//Byte aligned defintion for BIOS usage
> +//Byte aligned definition for BIOS usage
> #define ATOM_S4_LCD1_PANEL_ID_MASKb00x0FF
> #define ATOM_S4_LCD1_REFRESH_MASKb1 ATOM_S4_LCD1_PANEL_ID_MASKb0
> #define ATOM_S4_VRAM_INFO_MASKb2ATOM_S4_LCD1_PANEL_ID_MASKb0
> @@ -6989,7 +6989,7 @@ typedef struct _ATOM_ASIC_INTERNAL_SS_INFO_V3
>
[PATCH v1 3/3] drm/mediatek: move gce event property to mutex device node
According mtk hardware design, stream_done0 and stream_done1 are generated by mutex, so we move gce event property to mutex device mode. Signed-off-by: Bibby Hsieh Reviewed-by: CK Hu --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c index e35b66c5ba0f..e1cc7703a312 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c @@ -820,7 +820,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev, drm_crtc_index(_crtc->base)); mtk_crtc->cmdq_client = NULL; } - ret = of_property_read_u32_index(dev->of_node, "mediatek,gce-events", + ret = of_property_read_u32_index(priv->mutex_node, "mediatek,gce-events", drm_crtc_index(_crtc->base), _crtc->cmdq_event); if (ret) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/3] arm64: dts: mt8183: Add gce setting in display node
In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
This patch depends on ptach:
[RESEND,v6,02/17] arm64: dts: add display nodes for mt8183
https://patchwork.kernel.org/patch/11316277/
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index be4428c92f35..8b522b039a37 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "mt8183-pinfunc.h"
/ {
@@ -664,6 +665,9 @@
reg = <0 0x1400 0 0x1000>;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
+ mboxes = < 0 CMDQ_THR_PRIO_HIGHEST>,
+< 1 CMDQ_THR_PRIO_HIGHEST>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0
0x1000>;
};
ovl0: ovl@14008000 {
@@ -672,6 +676,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x8000
0x1000>;
};
ovl_2l0: ovl@14009000 {
@@ -680,6 +685,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0_2L>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x9000
0x1000>;
};
ovl_2l1: ovl@1400a000 {
@@ -688,6 +694,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL1_2L>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xa000
0x1000>;
};
rdma0: rdma@1400b000 {
@@ -697,6 +704,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_RDMA0>;
mediatek,rdma_fifo_size = <5120>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xb000
0x1000>;
};
rdma1: rdma@1400c000 {
@@ -706,6 +714,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_RDMA1>;
mediatek,rdma_fifo_size = <2048>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xc000
0x1000>;
};
color0: color@1400e000 {
@@ -715,6 +724,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_COLOR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xe000
0x1000>;
};
ccorr0: ccorr@1400f000 {
@@ -723,6 +733,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_CCORR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xf000
0x1000>;
};
aal0: aal@1401 {
@@ -732,6 +743,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_AAL0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0
0x1000>;
};
gamma0: gamma@14011000 {
@@ -741,6 +753,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_GAMMA0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0x1000
0x1000>;
};
dither0: dither@14012000 {
@@ -749,6 +762,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_DITHER0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0x2000
0x1000>;
};
mutex: mutex@14016000 {
@@ -756,6 +770,8 @@
reg = <0 0x14016000 0 0x1000>;
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ mediatek,gce-events = ,
+ ;
};
smi_common: smi@14019000 {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH v1 2/3] drm/mediatek: make sure previous message done or be aborted before send
Mediatek CMDQ driver removed atomic parameter and implementation
related to atomic. DRM driver need to make sure previous message
done or be aborted before we send next message.
If previous message is still waiting for event, it means the
setting hasn't been updated into display hardware register,
we can abort the message and send next message to update the
newest setting into display hardware.
If previous message already started, we have to wait it until
transmission has been completed.
So we flush mbox client before we send new message to controller
driver.
This patch depends on ptach:
[0/3] Remove atomic_exec
https://patchwork.kernel.org/cover/11381677/
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 3c53ea22208c..e35b66c5ba0f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -491,6 +491,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
}
#if IS_ENABLED(CONFIG_MTK_CMDQ)
if (mtk_crtc->cmdq_client) {
+ mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] Dual licence some files in GPL-2.0 and MIT
Hi Am 15.02.20 um 19:09 schrieb Emmanuel Vadot: > Hello all, > > We had a discussion a while back with Noralf where he said that he wouldn't > mind dual licence his work under GPL-2 and MIT. > Those files are a problem with BSDs as we cannot include them. > For drm_client.c the main contributors are Noralf Trønnes and Thomas > Zimmermann, the other commits are just catch ups from changes elsewhere > (return values, struct member names, function renames etc ...). > For drm_format_helper the main contributors are Noralf Trønnes and > Gerd Hoffmann. Same comment as for drm_client.c for the other commits. > > Emmanuel Vadot (2): > drm/client: Dual licence the file in GPL-2 and MIT > drm/format_helper: Dual licence the file in GPL 2 and MIT > > drivers/gpu/drm/drm_client.c| 2 +- > drivers/gpu/drm/drm_format_helper.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > For the patches I contributed: Acked-by: Thomas Zimmermann Best regards Thomas -- 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 signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 02/11] drm/bridge: dw-hdmi: add max bpc connector property
Hi! Dne četrtek, 06. februar 2020 ob 20:18:25 CET je Neil Armstrong napisal(a): > From: Jonas Karlman > > Add the max_bpc property to the dw-hdmi connector to prepare support > for 10, 12 & 16bit output support. > > Signed-off-by: Jonas Karlman > Signed-off-by: Neil Armstrong > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index > 9e0927d22db6..051001f77dd4 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -2406,6 +2406,10 @@ static int dw_hdmi_bridge_attach(struct drm_bridge > *bridge) DRM_MODE_CONNECTOR_HDMIA, > hdmi->ddc); > > + drm_atomic_helper_connector_reset(connector); Why is this reset needed? Best regards, Jernej > + > + drm_connector_attach_max_bpc_property(connector, 8, 16); > + > if (hdmi->version >= 0x200a && hdmi->plat_data->use_drm_infoframe) > drm_object_attach_property(>base, > connector->dev- >mode_config.hdr_output_metadata_property, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/sun4i: Support clock and data polarities on LVDS output
Hi, The Allwinner LVDS encoder allows to change the polarity of clocks and data lanes, so let's add the needed bus flags to DRM, panel-lvds and our encoder driver. Let me know what you think, Maxime Maxime Ripard (4): drm/connector: Add data polarity flags dt-bindings: panel: lvds: Add properties for clock and data polarities drm/panel: lvds: Support data and clock polarity flags drm/sun4i: lvds: Support data and clock polarity flags Documentation/devicetree/bindings/display/panel/lvds.yaml | 10 +++- drivers/gpu/drm/panel/panel-lvds.c| 25 +++- drivers/gpu/drm/sun4i/sun4i_tcon.c| 16 - include/drm/drm_connector.h | 4 +- 4 files changed, 49 insertions(+), 6 deletions(-) base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] ARM: sun7i: dts: Add LVDS panel support on A20
On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > This will create a spurious warning message for TCON1, since we
> > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > reset line, so we need to make it finer grained.
> >
> > Yes, I can attribute two of the messages in my dmesg log [1] to this
> > ("Missing LVDS properties" and "LVDS output disabled". "sun4i-tcon
> > 1c0d000.lcd-controller" is indeed tcon1). And yes, I can see how they
> > can be confusing to someone.
> >
> > I'd need some pointers on how to deal with that though (if we want to do
> > it in this scope).
>
> Like I was mentionning, you could introduce a new compatible for each
> TCON (tcon0 and tcon1) and only set the support_lvds flag for tcon0
Can you give me an idea how that compatible might look like?
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun7i-a20-tcon",
"allwinner,lvds";
or
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun7i-a20-tcon",
"allwinner,tcon0";
? Or something completely different?
--
Andrey Lebedev aka -.- . -.. -.. . .-.
Software engineer
Homepage: http://lebedev.lt/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
