Re: [PATCH v9 3/5] drm/kmb: Add support for KeemBay Display
On Thu, Oct 08, 2020 at 06:04:01PM -0700, Anitha Chrisanthus wrote:
> This is a basic KMS atomic modesetting display driver for KeemBay family of
> SOCs. Driver has no 2D or 3D graphics.It calls into the ADV bridge
> driver at the connector level.
>
> Single CRTC with LCD controller->mipi DSI-> ADV bridge
>
> Only 1080p resolution and single plane is supported at this time.
>
> v2: moved extern to .h, removed license text
> use drm_dev_init, upclassed dev_private, removed HAVE_IRQ.(Sam)
>
> v3: Squashed all 59 commits to one
>
> v4: review changes from Sam Ravnborg
> renamed dev_p to kmb
> moved clocks under kmb_clock, consolidated clk initializations
> use drmm functions
> use DRM_GEM_CMA_DRIVER_OPS_VMAP
>
> v5: corrected spellings
> v6: corrected checkpatch warnings
> v7: review changes Sam Ravnborg and Thomas Zimmerman
> removed kmb_crtc.h kmb_crtc_cleanup (Thomas)
> renamed mode_set, kmb_load, inlined unload (Thomas)
> moved remaining logging to drm_*(Thomas)
> re-orged driver initialization (Thomas)
> moved plane_status to drm_private (Sam)
> removed unnecessary logs and defines and ifdef codes (Sam)
> call helper_check in plane_atomic_check (Sam)
> renamed set to get for bpp and format functions(Sam)
> use drm helper functions for reset, duplicate/destroy state instead
> of kmb functions (Sam)
> removed kmb_priv from kmb_plane and removed kmb_plane_state (Sam)
> v8: get clk_pll0 from display node in dt
> v9: moved csc_coef_lcd to plane.c (Daniel Vetter)
> call drm_atomic_helper_shutdown in remove (Daniel V)
> use drm_crtc_handle_vblank (Daniel V)
> renamed kmb_dsi_hw_init to kmb_dsi_mode_set (Daniel V)
> complimentary changes to device tree changes (Rob)
>
> Cc: Sam Ravnborg
> Signed-off-by: Anitha Chrisanthus
> Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/kmb/kmb_crtc.c | 224 +
> drivers/gpu/drm/kmb/kmb_drv.c | 676
>
> drivers/gpu/drm/kmb/kmb_drv.h | 170 ++
> drivers/gpu/drm/kmb/kmb_plane.c | 488 +
> drivers/gpu/drm/kmb/kmb_plane.h | 102 ++
> 5 files changed, 1660 insertions(+)
> create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
> create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
> create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
> create mode 100644 drivers/gpu/drm/kmb/kmb_plane.c
> create mode 100644 drivers/gpu/drm/kmb/kmb_plane.h
>
> diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
> new file mode 100644
> index 000..72dcbdf
> --- /dev/null
> +++ b/drivers/gpu/drm/kmb/kmb_crtc.c
> @@ -0,0 +1,224 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright © 2018-2020 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "kmb_drv.h"
> +#include "kmb_dsi.h"
> +#include "kmb_plane.h"
> +#include "kmb_regs.h"
> +
> +struct kmb_crtc_timing {
> + u32 vfront_porch;
> + u32 vback_porch;
> + u32 vsync_len;
> + u32 hfront_porch;
> + u32 hback_porch;
> + u32 hsync_len;
> +};
> +
> +static int kmb_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct kmb_drm_private *kmb = to_kmb(dev);
> +
> + /* Clear interrupt */
> + kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
> + /* Set which interval to generate vertical interrupt */
> + kmb_write_lcd(kmb, LCD_VSTATUS_COMPARE,
> + LCD_VSTATUS_COMPARE_VSYNC);
> + /* Enable vertical interrupt */
> + kmb_set_bitmask_lcd(kmb, LCD_INT_ENABLE,
> + LCD_INT_VERT_COMP);
> + return 0;
> +}
> +
> +static void kmb_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct kmb_drm_private *kmb = to_kmb(dev);
> +
> + /* Clear interrupt */
> + kmb_write_lcd(kmb, LCD_INT_CLEAR, LCD_INT_VERT_COMP);
> + /* Disable vertical interrupt */
> + kmb_clr_bitmask_lcd(kmb, LCD_INT_ENABLE,
> + LCD_INT_VERT_COMP);
> +}
> +
> +static const struct drm_crtc_funcs kmb_crtc_funcs = {
> + .destroy = drm_crtc_cleanup,
> + .set_config = drm_atomic_helper_set_config,
> + .page_flip = drm_atomic_helper_page_flip,
> + .reset = drm_atomic_helper_crtc_reset,
> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .enable_vblank = kmb_crtc_enable_vblank,
> + .disable_vblank = kmb_crtc_disable_vblank,
> +};
> +
> +static void kmb_crtc_set_mode(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct drm_display_mode *m = &crtc->state->adjusted_mod
Re: [PATCH][next] drm/amdgpu: Use struct_size() helper in kmalloc()
Am 08.10.20 um 16:23 schrieb Gustavo A. R. Silva: Make use of the new struct_size() helper instead of the offsetof() idiom. Signed-off-by: Gustavo A. R. Silva Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c index 5da487b64a66..30192dce7775 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c @@ -239,8 +239,7 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo, if (!old) return 0; - new = kmalloc(offsetof(typeof(*new), shared[old->shared_max]), - GFP_KERNEL); + new = kmalloc(struct_size(new, shared, old->shared_max), GFP_KERNEL); if (!new) return -ENOMEM; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] amd/amdgpu_ctx: Use struct_size() helper and kmalloc()
Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva: Make use of the new struct_size() helper instead of the offsetof() idiom. Also, use kmalloc() instead of kcalloc(). Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c index c80d8339f58c..5be125f3b92a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c @@ -100,7 +100,7 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip, enum drm_sched_priority priority; int r; - entity = kcalloc(1, offsetof(typeof(*entity), fences[amdgpu_sched_jobs]), + entity = kmalloc(struct_size(entity, fences, amdgpu_sched_jobs), NAK. You could use kzalloc() here, but kmalloc won't zero initialize the memory which could result in unforeseen consequences. Christian. GFP_KERNEL); if (!entity) return -ENOMEM; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Re:
Hi Am 09.10.20 um 08:47 schrieb Thomas Zimmermann: > NACK for the entire lack of any form of commit description. Please see the documentation at [1] on how to describe the changes and getting your patches merged. Best regards Thomas [1] https://dri.freedesktop.org/docs/drm/process/submitting-patches.html#describe-your-changes > > Am 08.10.20 um 20:16 schrieb sandy.8...@gmail.com: >> Signed-off-by: Sandeep Raghuraman >> >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer 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 1/4] mm: introduce vma_set_file function v2
Am 08.10.20 um 16:12 schrieb Daniel Vetter:
On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 16 +---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++--
drivers/gpu/drm/msm/msm_gem.c | 4 +---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 +--
drivers/gpu/drm/vgem/vgem_drv.c| 3 +--
drivers/staging/android/ashmem.c | 5 ++---
include/linux/mm.h | 2 ++
mm/mmap.c | 16
10 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6ba4d598f0e..e4316aa7e0f4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1163,20 +1163,14 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- get_file(dmabuf->file);
- oldfile = vma->vm_file;
- vma->vm_file = dmabuf->file;
+ oldfile = vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
ret = dmabuf->ops->mmap(dmabuf, vma);
- if (ret) {
- /* restore old parameters on failure */
- vma->vm_file = oldfile;
- fput(dmabuf->file);
- } else {
- if (oldfile)
- fput(oldfile);
- }
+ /* restore old parameters on failure */
+ if (ret)
+ vma_set_file(vma, oldfile);
I think these two lines here are cargo-cult: If this fails, the mmap fails
and therefore the vma structure is kfreed. No point at all in restoring
anything.
This was explicitly added with this patch to fix a problem:
commit 495c10cc1c0c359871d5bef32dd173252fc17995
Author: John Sheu
Date: Mon Feb 11 17:50:24 2013 -0800
CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
With that: Reviewed-by: Daniel Vetter
Can I keep that even with the error handling working? :)
Christian.
+
return ret;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 312e9d58d5a7..10ce267c0947 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -145,10 +145,8 @@ static int etnaviv_gem_mmap_obj(struct etnaviv_gem_object
*etnaviv_obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(etnaviv_obj->base.filp);
vma->vm_pgoff = 0;
- vma->vm_file = etnaviv_obj->base.filp;
+ vma_set_file(vma, etnaviv_obj->base.filp);
vma->vm_page_prot = vm_page_prot;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fec0e1e3dc3e..8ce4c9e28b87 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -119,8 +119,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
if (ret)
return ret;
- fput(vma->vm_file);
- vma->vm_file = get_file(obj->base.filp);
+ vma_set_file(vma, obj->base.filp);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..c9d5f1a38af3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -893,8 +893,8 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
* requires avoiding extraneous references to their filp, hence why
* we prefer to use an anonymous file for their mmaps.
*/
- fput(vma->vm_file);
- vma->vm_file = anon;
+ vma_set_file(vma, anon);
+ fput(anon);
switch (mmo->mmap_type) {
case I915_MMAP_TYPE_WC:
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index de915ff6f4b4..a71f42870d5e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -223,10 +223,8 @@ int msm_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(obj->filp);
vma->vm_pg
[PATCH v2 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.
In order to allow that, let's pass the full DRM state to atomic_enable and
atomic_disable. The conversion was done using the coccinelle script below,
built tested on all the drivers and actually tested on vc4.
virtual report
@@
struct drm_crtc_helper_funcs *FUNCS;
identifier dev, state;
identifier crtc, crtc_state;
@@
disable_outputs(struct drm_device *dev, struct drm_atomic_state *state)
{
<...
- FUNCS->atomic_disable(crtc, crtc_state);
+ FUNCS->atomic_disable(crtc, state);
...>
}
@@
struct drm_crtc_helper_funcs *FUNCS;
identifier dev, state;
identifier crtc, crtc_state;
@@
drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, struct
drm_atomic_state *state)
{
<...
- FUNCS->atomic_enable(crtc, crtc_state);
+ FUNCS->atomic_enable(crtc, state);
...>
}
@@
identifier crtc, old_state;
@@
struct drm_crtc_helper_funcs {
...
- void (*atomic_enable)(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+ void (*atomic_enable)(struct drm_crtc *crtc, struct drm_atomic_state
*state);
...
- void (*atomic_disable)(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+ void (*atomic_disable)(struct drm_crtc *crtc, struct drm_atomic_state
*state);
...
}
@ crtc_atomic_func @
identifier helpers;
identifier func;
@@
(
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_enable = func,
...,
};
|
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
};
)
@ ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@
void func(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
... when != old_state
}
@ adds_old_state depends on crtc_atomic_func && !ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@
void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
crtc);
...
}
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
expression E;
type T;
@@
void func(...)
{
...
- T state = E;
+ T crtc_state = E;
<+...
- state
+ crtc_state
...+>
}
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
type T;
@@
void func(...)
{
...
- T state;
+ T crtc_state;
<+...
- state
+ crtc_state
...+>
}
@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
identifier old_state;
identifier crtc;
@@
void func(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state
+ struct drm_atomic_state *state
)
{ ... }
@ include depends on adds_old_state @
@@
#include
@ no_include depends on !include && adds_old_state @
@@
+ #include
#include
Acked-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/arc/arcpgu_crtc.c| 4 ++--
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 8 ++--
drivers/gpu/drm/arm/hdlcd_crtc.c | 4 ++--
drivers/gpu/drm/arm/malidp_crtc.c| 6 --
drivers/gpu/drm/armada/armada_crtc.c | 8 ++--
drivers/gpu/drm/ast/ast_mode.c | 6 --
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 ++--
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 ++--
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 6 --
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 ++--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 ++--
drivers/gpu/drm/imx/dcss/dcss-crtc.c | 9 +++--
drivers/gpu/drm/imx/ipuv3-crtc.c | 6 --
drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 4 ++--
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++--
drivers/gpu/drm/meson/meson_crtc.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 +--
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c| 4 ++--
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 4 ++--
drivers/gpu/drm/mxsfb/mxsfb_kms.c| 4 ++--
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 ++--
drivers/gpu/drm/qxl/qxl_display.c| 4 ++--
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 --
drivers/gpu/drm/sti/sti_crtc.c | 4 ++--
drivers/gpu/drm/stm/ltdc.c | 4 ++--
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On Tue, Oct 06, 2020 at 08:23:06AM +0100, Christoph Hellwig wrote: > If people want to use the "raw" IOMMU API with not cache coherent > devices we'll need a cache maintainance API that goes along with it. > It could either be formally part of the IOMMU API or be separate. The IOMMU-API does not care about the caching effects of DMA, is manages IO address spaces for devices. I also don't know how this would be going to be implemented, the IOMMU-API does not have the concept of handles for mapped ranges and does not care about CPU virtual addresses (which are needed for cache flushes) of the memory it maps into IO page-tables. So I think a cache management API should be separate from the IOMMU-API. Regards, Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/vc4: kms: Fix VBLANK reporting on a disabled CRTC
If a CRTC is enabled but not active, and that we're then doing a page flip
on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state
into the global state, and will make us wait for its vblank as well, even
though that might never occur.
Fix this by considering all the enabled CRTCs by either using their new
state in the global state, or using their current state if they aren't part
of the new state being checked, to remove their assigned channel from the
pool before started to assign channels to CRTCs enabled by the state.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index c9dfd5535a7e..0751ce5c6467 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -645,6 +645,14 @@ static const struct drm_private_state_funcs
vc4_load_tracker_state_funcs = {
* need to consider all the running CRTCs in the DRM device to assign
* a FIFO, not just the one in the state.
*
+ * - To fix the above, we can't use drm_atomic_get_crtc_state on all
+ * enabled CRTCs to pull their CRTC state into the global state, since
+ * a page flip would start considering their vblank to complete. Since
+ * we don't have a guarantee that they are actually active, that
+ * vblank might never happen, and shouldn't even be considered if we
+ * want to do a page flip on a single CRTC. That can be tested by
+ * doing a modetest -v first on HDMI1 and then on HDMI0.
+ *
* - Since we need the pixelvalve to be disabled and enabled back when
* the FIFO is changed, we should keep the FIFO assigned for as long
* as the CRTC is enabled, only considering it free again once that
@@ -656,6 +664,7 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
{
unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
@@ -667,15 +676,14 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
* the same CRTCs, instead of evaluating only the CRTC being
* modified.
*/
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
- struct drm_crtc_state *crtc_state;
+ for_each_new_or_current_crtc_state(state, crtc, crtc_state) {
+ struct vc4_crtc_state *vc4_crtc_state;
- if (!crtc->state->enable)
+ if (!crtc_state->enable)
continue;
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state))
- return PTR_ERR(crtc_state);
+ vc4_crtc_state = to_vc4_crtc_state(crtc_state);
+ unassigned_channels &= ~BIT(vc4_crtc_state->assigned_channel);
}
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -690,10 +698,8 @@ static int vc4_pv_muxing_atomic_check(struct drm_device
*dev,
if (!new_crtc_state->enable)
continue;
- if (new_vc4_crtc_state->assigned_channel !=
VC4_HVS_CHANNEL_DISABLED) {
- unassigned_channels &=
~BIT(new_vc4_crtc_state->assigned_channel);
+ if (new_vc4_crtc_state->assigned_channel !=
VC4_HVS_CHANNEL_DISABLED)
continue;
- }
/*
* The problem we have to solve here is that we have
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/13] PCI: revoke mappings like devmem
On Thu, Oct 08, 2020 at 12:49:54AM -0700, Dan Williams wrote: > > This is what got me thinking maybe this needs to be a bit bigger > > generic infrastructure - eg enter this scheme from fops mmap and > > everything else is in mm/user_iomem.c > > It still requires every file that can map physical memory to have its > ->open fop do Common infrastructure would have to create a dummy struct file at mmap time with the global inode and attach that to the VMA. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Dave, sorry for the late reply. On Tue, 2020-10-06 at 18:14 +0100, Dave Stevenson wrote: > Hi Maxime > > On Tue, 6 Oct 2020 at 16:26, Maxime Ripard wrote: > > Hi Dave, > > > > On Fri, Oct 02, 2020 at 04:57:05PM +0100, Dave Stevenson wrote: > > > Hi Maxime > > > > > > On Fri, 2 Oct 2020 at 16:19, Maxime Ripard wrote: > > > > Hi Tim, > > > > > > > > On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote: > > > > > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC > > > > > VCO to support a core-frequency of 550 MHz which is the minimum > > > > > frequency required by the HVS at 4Kp60. The side effect is that if the > > > > > display clock requirements are lower than 4Kp60 then you will see > > > > > different core frequencies selected by DVFS. > > > > > > > > > > If enable_uart=1 and the mini-uart is selected (default unless > > > > > bluetooth is disabled) then the firmware will pin the core-frequency > > > > > to either core_freq max (500 or 550). Although, I think there is a way > > > > > of pinning it to a lower fixed frequency. > > > > > > > > > > The table in overclocking.md defines options for setting the maximum > > > > > core frequency but unless core_freq_min is specified DVFS will > > > > > automatically pick the lowest idle frequency required by the display > > > > > resolution. > > > > > > > > I'm wondering if there's some way to detect this from Linux? I guess it > > > > would be nice to be able to at least detect a broken config to warn / > > > > prevent an user that their situation is not going to be reliable / work > > > > really well (like if they have a 4k display without hdmi_enable_4kp60 > > > > set, or the issue we're discussing here) > > > > > > The main filter in the firmware is the parameter > > > hdmi_pixel_freq_limit. That can either be set manually from > > > config.txt, or defaults appropriately based on hdmi_enable_4kp60. > > > Under firmware_kms [1] I read back those values to use as a filter > > > within crtc_mode_valid[2]. > > > I can't think of a nice way of exposing that without the vc4 driver > > > gaining a DT link to the firmware, and that starts to get ugly. > > > > I had in mind something like if the clock driver can infer that somehow > > through some the boundaries reported by the firmware maybe? IIRC, > > hdmi_enable_4kp60 will already change the max frequency reported to > > 550MHz instead of 500MHz > > Yes, that's plausible, but I don't know enough about the clock > infrastructure for advertising limits to know what works there. > Tell me what you need from the mailbox service and I'll see what I can do. > > We do already have RPI_FIRMWARE_GET_MAX_CLOCK_RATE and > RPI_FIRMWARE_GET_MIN_CLOCK_RATE. It'd take a few minutes of staring at > the code (or a quick test) to confirm if they definitely are changed > for CORE clock by hdmi_enable_4kp60 - I think it does. Tim commented earlier that you meant to pin CORE frequency when enable_uart=1. In practice it doesn't seem to be the case, but it would solve the UART problem for most use cases. Would that be feasible? If we have to change the CORE frequency during runtime we could, while we search for a proper solution, print a warning that we're about to break the low speed peripherals. Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] drm/vc4: hdmi: Support the 10/12 bit output
Hi, Here's some patches to enable the HDR output in the RPi4 HDMI controller. This needed a quite intrusive rework in the first patch to allow a CRTC to have access to the whole DRM state at atomic_enable / atomic_disable time. Let me know what you think, Maxime Changes from v1: - Added the coccinelle script to the first patch - Fixed the pixel_rate ramp up Maxime Ripard (6): drm/atomic: Pass the full state to CRTC atomic enable/disable drm/vc4: hvs: Align the HVS atomic hooks to the new API drm/vc4: Pass the atomic state to encoder hooks drm/vc4: hdmi: Create a custom connector state drm/vc4: hdmi: Store pixel frequency in the connector state drm/vc4: hdmi: Enable 10/12 bpc output drivers/gpu/drm/arc/arcpgu_crtc.c| 4 +- drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 8 +- drivers/gpu/drm/arm/hdlcd_crtc.c | 4 +- drivers/gpu/drm/arm/malidp_crtc.c| 6 +- drivers/gpu/drm/armada/armada_crtc.c | 8 +- drivers/gpu/drm/ast/ast_mode.c | 6 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 4 +- drivers/gpu/drm/drm_atomic_helper.c | 4 +- drivers/gpu/drm/drm_simple_kms_helper.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 6 +- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 4 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +- drivers/gpu/drm/imx/dcss/dcss-crtc.c | 9 +- drivers/gpu/drm/imx/ipuv3-crtc.c | 6 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 4 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/meson/meson_crtc.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c| 4 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 4 +- drivers/gpu/drm/mxsfb/mxsfb_kms.c| 4 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +- drivers/gpu/drm/qxl/qxl_display.c| 4 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +- drivers/gpu/drm/sti/sti_crtc.c | 4 +- drivers/gpu/drm/stm/ltdc.c | 4 +- drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 +- drivers/gpu/drm/tegra/dc.c | 8 +- drivers/gpu/drm/tidss/tidss_crtc.c | 6 +- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +- drivers/gpu/drm/vboxvideo/vbox_mode.c| 4 +- drivers/gpu/drm/vc4/vc4_crtc.c | 26 +-- drivers/gpu/drm/vc4/vc4_drv.h| 14 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 154 +++- drivers/gpu/drm/vc4/vc4_hdmi.h | 12 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 +- drivers/gpu/drm/vc4/vc4_hvs.c| 8 +- drivers/gpu/drm/vc4/vc4_txp.c| 9 +- drivers/gpu/drm/virtio/virtgpu_display.c | 4 +- drivers/gpu/drm/vkms/vkms_crtc.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +- drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 +- drivers/gpu/drm/zte/zx_vou.c | 4 +- include/drm/drm_modeset_helper_vtables.h | 13 +- 48 files changed, 316 insertions(+), 129 deletions(-) base-commit: 1a11a88cfd9a97e13be8bc880c4795f9844fbbec -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/vc4: kms: Don't disable the muxing of an active CRTC
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.
However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new state.
Fix this by considering all the CRTCs in the state and the ones with a
state and active.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 3b5e62842901..c9dfd5535a7e 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -185,6 +185,23 @@ static void vc4_hvs_pv_muxing_commit(struct vc4_dev *vc4,
}
}
+static struct drm_crtc_state *
+drm_atomic_get_new_or_current_crtc_state(struct drm_atomic_state *state,
+struct drm_crtc *crtc)
+{
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (crtc_state)
+ return crtc_state;
+
+ return crtc->state;
+}
+
+#define for_each_new_or_current_crtc_state(__state, crtc, crtc_state) \
+ list_for_each_entry(crtc, &__state->dev->mode_config.crtc_list, head) \
+ for_each_if(crtc_state =
drm_atomic_get_new_or_current_crtc_state(__state, crtc))
+
static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
struct drm_atomic_state *state)
{
@@ -194,16 +211,16 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
unsigned char dsp3_mux = 3;
unsigned char dsp4_mux = 3;
unsigned char dsp5_mux = 3;
- unsigned int i;
u32 reg;
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- struct vc4_crtc_state *vc4_state =
to_vc4_crtc_state(crtc_state);
+ for_each_new_or_current_crtc_state(state, crtc, crtc_state) {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+ struct vc4_crtc_state *vc4_state;
if (!crtc_state->active)
continue;
+ vc4_state = to_vc4_crtc_state(crtc_state);
switch (vc4_crtc->data->hvs_output) {
case 2:
dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/6] drm/vc4: hdmi: Store pixel frequency in the connector state
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 44 ++-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5e4ebb51a750..21d20c8494e8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,6 +192,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -609,9 +610,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -623,7 +644,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK)
? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -788,6 +809,26 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
*encoder)
{
}
+static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct drm_display_mode *mode = &crtc_state->adjusted_mode;
+ struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ unsigned long long pixel_rate = mode->clock * 1000;
+
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate *= 2;
+
+ if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
+ return -EINVAL;
+
+ vc4_state->pixel_rate = pixel_rate;
+
+ return 0;
+}
+
static enum drm_mode_status
vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode *mode)
@@ -801,6 +842,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
}
static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs = {
+ .atomic_check = vc4_hdmi_encoder_atomic_check,
.mode_valid = vc4_hdmi_encoder_mode_valid,
.disable = vc4_hdmi_encoder_disable,
.enable = vc4_hdmi_encoder_enable,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index d53d9fd88bfe..dbe2393ae043 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -171,6 +171,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
On Wed, Sep 16, 2020 at 06:57:05PM +0200, Maxime Ripard wrote: > On Mon, Sep 14, 2020 at 07:14:11PM +0900, Hoegeun Kwon wrote: > > Hi Maxime, > > > > On 9/8/20 9:00 PM, Maxime Ripard wrote: > > > Hi Hoegeun, > > > > > > On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote: > > >> On 9/3/20 5:00 PM, Maxime Ripard wrote: > > >>> Hi everyone, > > >>> > > >>> Here's a (pretty long) series to introduce support in the VC4 DRM driver > > >>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi > > >>> 4). > > >>> > > >>> The main differences are that there's two HDMI controllers and that > > >>> there's > > >>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that > > >>> still > > >>> have only 3 FIFOs. Both of those differences are breaking a bunch of > > >>> expectations in the driver, so we first need a good bunch of cleanup and > > >>> reworks to introduce support for the new controllers. > > >>> > > >>> Similarly, the HDMI controller has all its registers shuffled and split > > >>> in > > >>> multiple controllers now, so we need a bunch of changes to support this > > >>> as > > >>> well. > > >>> > > >>> Only the HDMI support is enabled for now (even though the DPI and DSI > > >>> outputs have been tested too). > > >>> > > >>> Let me know if you have any comments > > >>> Maxime > > >>> > > >>> Cc: bcm-kernel-feedback-l...@broadcom.com > > >>> Cc: devicet...@vger.kernel.org > > >>> Cc: Kamal Dasu > > >>> Cc: Philipp Zabel > > >>> Cc: Rob Herring > > >>> Cc: Stephen Boyd > > >>> > > >>> Changes from v4: > > >>> - Rebased on top of next-20200828 > > >>> - Collected the various tags > > >>> - Fixed some issues with 4k support and dual output (thanks > > >>> Hoegeun!) > > >> Thanks for your v5 patchset. > > >> > > >> I tested all patches based on the next-20200812. > > > Thanks again for testing all the patches > > > > > >> Everything else is fine, but the dual hdmi modetest doesn't work well in > > >> my > > >> environment... > > >> > > >> In my environment, dsi is not connected, I have seen your answer[1]. > > > Can you share a bit more your setup? What monitors are being connected > > > to each HDMI port? Do you hotplug any? > > Yes, Monitors are being connected to each HDMI ports. (did not use hotplug) > > > > When booting, both HDMI-0 and 1 are recognized and the kernel log is output. > > But after run modetest on HDMI-0(works) and modetest on HDMI-1(works), > > crtc timed out occurs on HDMI-0 and does not work. > > > > When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin > > after about 40 sec. > > > > Below is the log for modetest. > > > > > > root:~> modetest -Mvc4 -s 32:1280x720 - HDMI-0 works > > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > > failed to set gamma: Invalid argument > > > > root:~> modetest -Mvc4 -s 32:1280x720 - HDMI-0 works > > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > > failed to set gamma: Invalid argument > > > > root:~> modetest -Mvc4 -s 38:1280x720 - HDMI-1 works > > setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69 > > failed to set gamma: Invalid argument > > > > - Crtc timed out occurs on HDMI-0 and > > does not work. > > > > [ 71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > [ 81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > [ 91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CONNECTOR:32:HDMI-A-1] flip_done timed out > > [ 101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [PLANE:60:plane-3] flip_done timed out > > > > [ 112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > [ 122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > > > root:~> modetest -Mvc4 -s 32:1280x720 > > [ 132.830309] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CONNECTOR:32:HDMI-A-1] flip_done timed out > > [ 143.070307] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [PLANE:60:plane-3] flip_done timed out > > [ 153.310303] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > > [ 163.550340] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CRTC:64:crtc-3] flip_done timed out > > [ 173.790277] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [CONNECTOR:32:HDMI-A-1] flip_done timed out > > [ 184.030286] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > > [PLANE:60:plane-3] flip_done timed out > > failed to set gamma: Invalid argument - HDMI-0 works > > Thanks :) > > I was able to reproduce it just by also letting X boot. I'm on a good > path to fix it and found a w
[PATCH v2 4/6] drm/vc4: hdmi: Create a custom connector state
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 7d2593398094..5e4ebb51a750 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,16 +170,39 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 63c6f8bddf1d..d53d9fd88bfe 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -169,6 +169,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/vc4: hdmi: Enable 10/12 bpc output
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 21d20c8494e8..3ff72fab4c40 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,6 +76,17 @@
#define VC5_HDMI_VERTB_VSPO_SHIFT 16
#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10, 8)
+
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
+#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
+
+#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
+
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
+#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
+
# define VC4_HD_M_SW_RST BIT(2)
# define VC4_HD_M_ENABLE BIT(0)
@@ -177,6 +188,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
kfree(connector->state);
+ conn_state->base.max_bpc = 8;
+ conn_state->base.max_requested_bpc = 8;
+
__drm_atomic_helper_connector_reset(connector, &conn_state->base);
drm_atomic_helper_connector_tv_reset(connector);
}
@@ -224,12 +238,20 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
vc4_hdmi->ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
+ /*
+* Some of the properties below require access to state, like bpc.
+* Allocate some default initial connector state with our reset helper.
+*/
+ if (connector->funcs->reset)
+ connector->funcs->reset(connector);
+
/* Create and attach TV margin props to this connector. */
ret = drm_mode_create_tv_margin_properties(dev);
if (ret)
return ret;
drm_connector_attach_tv_margin_properties(connector);
+ drm_connector_attach_max_bpc_property(connector, 8, 16);
connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT);
@@ -495,6 +517,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
bool enable)
}
static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -538,7 +561,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
}
+
static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
+struct drm_connector_state *state,
struct drm_display_mode *mode)
{
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
@@ -558,6 +583,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
mode->crtc_vsync_end -
interlaced,
VC4_HDMI_VERTB_VBP));
+ unsigned char gcp;
+ bool gcp_en;
+ u32 reg;
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
HDMI_WRITE(HDMI_HORZA,
@@ -583,6 +611,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VERTB0, vertb_even);
HDMI_WRITE(HDMI_VERTB1, vertb);
+ switch (state->max_bpc) {
+ case 12:
+ gcp = 6;
+ gcp_en = true;
+ break;
+ case 10:
+ gcp = 5;
+ gcp_en = true;
+ break;
+ case 8:
+ default:
+ gcp = 4;
+ gcp_en = false;
+ break;
+ }
+
+ reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
+ reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
+VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
+ reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE) |
+ VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
+ HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_WORD_1);
+ reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+ reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+ HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+ reg = HDMI_READ(HDMI_GCP_CONFIG);
+ reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENABLE;
+ reg |= gcp_en ? VC5_HDMI_GCP_CONFIG_GCP_ENABLE : 0;
+
[PATCH 2/4] drm/vc4: kms: Document the muxing corner cases
We've had a number of muxing corner-cases with specific ways to reproduce
them, so let's document them to make sure they aren't lost and introduce
regressions later on.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 846fe8b3cb7a..3b5e62842901 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -612,6 +612,28 @@ static const struct drm_private_state_funcs
vc4_load_tracker_state_funcs = {
#define NUM_OUTPUTS 6
#define NUM_CHANNELS 3
+/*
+ * The BCM2711 HVS has up to 7 output connected to the pixelvalves and
+ * the TXP (and therefore all the CRTCs found on that platform).
+ *
+ * The naive (and our initial) implementation would just iterate over
+ * all the active CRTCs, try to find a suitable FIFO, and then remove it
+ * from the available FIFOs pool. However, there's a few corner cases
+ * that need to be considered:
+ *
+ * - When running in a dual-display setup (so with two CRTCs involved),
+ * we can update the state of a single CRTC (for example by changing
+ * its mode using xrandr under X11) without affecting the other. In
+ * this case, the other CRTC wouldn't be in the state at all, so we
+ * need to consider all the running CRTCs in the DRM device to assign
+ * a FIFO, not just the one in the state.
+ *
+ * - Since we need the pixelvalve to be disabled and enabled back when
+ * the FIFO is changed, we should keep the FIFO assigned for as long
+ * as the CRTC is enabled, only considering it free again once that
+ * CRTC has been disabled. This can be tested by booting X11 on a
+ * single display, and changing the resolution down and then back up.
+ */
static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
{
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: introduce vma_set_file function v2
On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
> drivers/dma-buf/dma-buf.c | 16 +---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++--
> drivers/gpu/drm/msm/msm_gem.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 +--
> drivers/gpu/drm/vgem/vgem_drv.c| 3 +--
> drivers/staging/android/ashmem.c | 5 ++---
...
> +++ b/mm/mmap.c
> @@ -136,6 +136,22 @@ void vma_set_page_prot(struct vm_area_struct *vma)
> WRITE_ONCE(vma->vm_page_prot, vm_page_prot);
> }
>
> +/*
> + * Change backing file, only valid to use during initial VMA setup.
> + */
> +struct file *vma_set_file(struct vm_area_struct *vma, struct file *file)
> +{
> + if (file)
> + get_file(file);
> +
> + swap(vma->vm_file, file);
> +
> + if (file)
> + fput(file);
> +
> + return file;
> +}
> +
These users are all potentially modules. You need an EXPORT_SYMBOL()?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/vc4: kms: Split the HVS muxing check in a separate function
The code that assigns HVS channels during atomic_check is starting to grow
a bit big, let's move it into a separate function.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 149825ff5df8..846fe8b3cb7a 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -612,13 +612,13 @@ static const struct drm_private_state_funcs
vc4_load_tracker_state_funcs = {
#define NUM_OUTPUTS 6
#define NUM_CHANNELS 3
-static int
-vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
+static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc *crtc;
- int i, ret;
+ unsigned int i;
/*
* Since the HVS FIFOs are shared across all the pixelvalves and
@@ -691,6 +691,18 @@ vc4_atomic_check(struct drm_device *dev, struct
drm_atomic_state *state)
}
}
+ return 0;
+}
+
+static int
+vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = vc4_pv_muxing_atomic_check(dev, state);
+ if (ret)
+ return ret;
+
ret = vc4_ctm_atomic_check(dev, state);
if (ret < 0)
return ret;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Update entry for st7703 driver after the rename
On Wed, 1 Jul 2020, Ondrej Jirman wrote: > The driver was renamed, change the path in the MAINTAINERS file. > > Signed-off-by: Ondrej Jirman This minor non-urgent cleanup patch has not been picked up yet by anyone. Hence, ./scripts/get_maintainers.pl --self-test=patterns continues to complain: warning: no file matches F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt warning: no file matches F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c This patch cleanly applies on next-20201008 and resolves the issue above. Reviewed-by: Lukas Bulwahn Lukas > --- > MAINTAINERS | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5f186a661a9b..f5183eae08df 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5487,12 +5487,13 @@ S:Maintained > F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml > F: drivers/gpu/drm/panel/panel-raydium-rm67191.c > > -DRM DRIVER FOR ROCKTECH JH057N00900 PANELS > +DRM DRIVER FOR SITRONIX ST7703 PANELS > M: Guido Günther > R: Purism Kernel Team > +R: Ondrej Jirman > S: Maintained > -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c > +F: > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c > > DRM DRIVER FOR SAVAGE VIDEO CARDS > S: Orphan / Obsolete > -- > 2.27.0 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] drm/vc4: hvs: Align the HVS atomic hooks to the new API
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_hvs.c | 8 +---
drivers/gpu/drm/vc4/vc4_txp.c | 8 ++--
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 97b1f1f7aa18..b5deacfe16cd 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
*/
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index a22478a35199..92996c99600d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -912,8 +912,8 @@ extern struct platform_driver vc4_hvs_driver;
void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
-void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
-void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
*old_state);
+void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state
*state);
void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
void vc4_hvs_dump_state(struct drm_device *dev);
void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 4d0a833366ce..22403ab2a430 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
}
void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
- struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+ struct drm_crtc_state *new_crtc_state =
drm_atomic_get_new_crtc_state(state, crtc);
+ struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
}
void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
- struct drm_crtc_state *old_state)
+ struct drm_atomic_state *state)
{
struct drm_device *dev = crtc->dev;
+ struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index e0e0b72ea65c..9fc8328f505c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -404,23 +404,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
- vc4_hvs_atomic_enable(crtc, old_state);
+ vc4_hvs_atomic_enable(crtc, state);
}
static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
- struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
/* Disable vblank irq handling
[PATCH v2 3/6] drm/vc4: Pass the atomic state to encoder hooks
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index b5deacfe16cd..4204c5e37ffe 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 92996c99600d..30dfe113dfd0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -442,12 +442,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 03825596a308..7d2593398094 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
+static void vc4_hdmi
[PATCH 0/6] spelling: Fix typo related to "arbitrary"
I found some typos related to "arbitrary". s/abitrary/arbitrary/ s/arbitary/arbitrary/ This series fixes them. These typos have been reported in the past in other codes, but correction 'abitrary||arbitrary' wasn't added to scripts/spelling.txt. Therefore, PATCH #6 adds it to spelling.txt. Naoki Hayama (6): net: tlan: Fix typo abitrary dt-bindings: pinctrl: qcom: Fix typo abitrary dt-bindings: pinctrl: sirf: Fix typo abitrary ALSA: hdspm: Fix typo arbitary drm/etnaviv: Fix typo arbitary scripts/spelling.txt: Add arbitrary correction Documentation/devicetree/bindings/pinctrl/pinctrl-atlas7.txt| 2 +- .../devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt| 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- drivers/net/ethernet/ti/tlan.c | 2 +- scripts/spelling.txt| 1 + sound/pci/rme9652/hdspm.c | 2 +- 6 files changed, 6 insertions(+), 5 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/i915/dpcd_bl: Skip testing control capability with force DPCD quirk
Kevin Chowski said he would be geting to working on upstreaming a version
of that which was in the ChromeOS tree here:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2344844
when I last spoke to hi
(This was two weeks ago.)
Kevin - do you have any input on this?
Satadru
On Thu, Oct 8, 2020 at 1:07 PM Lyude Paul wrote:
> oh hold on, I misspoke. Here's the patch I was thinking of:
>
> https://patchwork.freedesktop.org/series/82041/
>
> On Thu, 2020-10-08 at 10:32 +0800, Kai-Heng Feng wrote:
> > Hi Lyude,
> >
> > > On Oct 8, 2020, at 05:53, Lyude Paul wrote:
> > >
> > > Hi! I thought this patch rang a bell, we actually already had some
> > > discussion
> > > about this since there's a couple of other systems this was causing
> issues
> > > for.
> > > Unfortunately it never seems like that patch got sent out. Satadru?
> > >
> > > (if I don't hear back from them soon, I'll just send out a patch for
> this
> > > myself)
> > >
> > > JFYI - the proper fix here is to just drop the
> > > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP check from the code entirely.
> As
> > > long as
> > > the backlight supports AUX_SET_CAP, that should be enough for us to
> control
> > > it.
> >
> > Does the proper fix include dropping DP_QUIRK_FORCE_DPCD_BACKLIGHT
> entirely?
> >
> > Kai-Heng
> >
> > >
> > > On Wed, 2020-10-07 at 14:58 +0800, Kai-Heng Feng wrote:
> > > > HP DreamColor panel needs to be controlled via AUX interface.
> However,
> > > > it has both DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and
> > > > DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP set, so it fails to pass
> > > > intel_dp_aux_display_control_capable() test.
> > > >
> > > > Skip the test if the panel has force DPCD quirk.
> > > >
> > > > Signed-off-by: Kai-Heng Feng
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 ++
> > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > index acbd7eb66cbe..acf2e1c65290 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > @@ -347,9 +347,13 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > > intel_connector *intel_connector)
> > > > struct intel_panel *panel = &intel_connector->panel;
> > > > struct intel_dp *intel_dp =
> enc_to_intel_dp(intel_connector->encoder);
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > + bool force_dpcd;
> > > > +
> > > > + force_dpcd = drm_dp_has_quirk(&intel_dp->desc,
> intel_dp->edid_quirks,
> > > > + DP_QUIRK_FORCE_DPCD_BACKLIGHT);
> > > >
> > > > if (i915->params.enable_dpcd_backlight == 0 ||
> > > > - !intel_dp_aux_display_control_capable(intel_connector))
> > > > + (!force_dpcd &&
> > > > !intel_dp_aux_display_control_capable(intel_connector)))
> > > > return -ENODEV;
> > > >
> > > > /*
> > > > @@ -358,9 +362,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> > > > intel_connector *intel_connector)
> > > >*/
> > > > if (i915->vbt.backlight.type !=
> > > > INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
> > > > - i915->params.enable_dpcd_backlight != 1 &&
> > > > - !drm_dp_has_quirk(&intel_dp->desc, intel_dp->edid_quirks,
> > > > - DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
> > > > + i915->params.enable_dpcd_backlight != 1 && !force_dpcd) {
> > > > drm_info(&i915->drm,
> > > >"Panel advertises DPCD backlight support, but "
> > > >"VBT disagrees. If your backlight controls "
> > > --
> > > Sincerely,
> > > Lyude Paul (she/her)
> > > Software Engineer at Red Hat
> --
> Sincerely,
> Lyude Paul (she/her)
> Software Engineer at Red Hat
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/etnaviv: Fix typo arbitary
Fix comment typo. s/arbitary/arbitrary/ Signed-off-by: Naoki Hayama --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index c6404b8d067f..5077004f7fbf 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -1811,7 +1811,7 @@ static int etnaviv_gpu_platform_probe(struct platform_device *pdev) /* * We treat the device as initially suspended. The runtime PM -* autosuspend delay is rather arbitary: no measurements have +* autosuspend delay is rather arbitrary: no measurements have * yet been performed to determine an appropriate value. */ pm_runtime_use_autosuspend(gpu->dev); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/13] s390/pci: Remove races against pte updates
On Wed, 7 Oct 2020 18:44:21 +0200
Daniel Vetter wrote:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range when buffers get moved
>
> - contiguous dma allocations have moved from dedicated carvetouts to
> cma regions. This means if we miss the unmap the pfn might contain
> pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
>
> - even /dev/mem now invalidates mappings when the kernel requests that
> iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
> ("/dev/mem: Revoke mappings when a driver claims the region")
>
> Accessing pfns obtained from ptes without holding all the locks is
> therefore no longer a good idea. Fix this.
>
> Since zpci_memcpy_from|toio seems to not do anything nefarious with
> locks we just need to open code get_pfn and follow_pfn and make sure
> we drop the locks only after we've done. The write function also needs
> the copy_from_user move, since we can't take userspace faults while
> holding the mmap sem.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Dan Williams
> Cc: Kees Cook
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Niklas Schnelle
> Cc: Gerald Schaefer
> Cc: linux-s...@vger.kernel.org
> ---
> arch/s390/pci/pci_mmio.c | 98 +++-
> 1 file changed, 57 insertions(+), 41 deletions(-)
Looks good, thanks. Also survived some basic function test. Only some
minor nitpick, see below.
Reviewed-by: Gerald Schaefer
>
> diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> index 401cf670a243..4d194cb09372 100644
> --- a/arch/s390/pci/pci_mmio.c
> +++ b/arch/s390/pci/pci_mmio.c
> @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
> *dst,
> return rc;
> }
>
> -static long get_pfn(unsigned long user_addr, unsigned long access,
> - unsigned long *pfn)
> -{
> - struct vm_area_struct *vma;
> - long ret;
> -
> - mmap_read_lock(current->mm);
> - ret = -EINVAL;
> - vma = find_vma(current->mm, user_addr);
> - if (!vma)
> - goto out;
> - ret = -EACCES;
> - if (!(vma->vm_flags & access))
> - goto out;
> - ret = follow_pfn(vma, user_addr, pfn);
> -out:
> - mmap_read_unlock(current->mm);
> - return ret;
> -}
> -
> SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> const void __user *, user_buffer, size_t, length)
> {
> u8 local_buf[64];
> void __iomem *io_addr;
> void *buf;
> - unsigned long pfn;
> + struct vm_area_struct *vma;
> + pte_t *ptep;
> + spinlock_t *ptl;
> long ret;
>
> if (!zpci_is_enabled())
> @@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
> mmio_addr,
>* We only support write access to MIO capable devices if we are on
>* a MIO enabled system. Otherwise we would have to check for every
>* address if it is a special ZPCI_ADDR and would have to do
> - * a get_pfn() which we don't need for MIO capable devices. Currently
> + * a pfn lookup which we don't need for MIO capable devices. Currently
>* ISM devices are the only devices without MIO support and there is no
>* known need for accessing these from userspace.
>*/
> @@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
> mmio_addr,
> } else
> buf = local_buf;
>
> - ret = get_pfn(mmio_addr, VM_WRITE, &pfn);
> + ret = -EFAULT;
> + if (copy_from_user(buf, user_buffer, length))
> + goto out_free;
> +
> + mmap_read_lock(current->mm);
> + ret = -EINVAL;
> + vma = find_vma(current->mm, mmio_addr);
> + if (!vma)
> + goto out_unlock_mmap;
> + ret = -EACCES;
> + if (!(vma->vm_flags & VM_WRITE))
> + goto out_unlock_mmap;
> + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
> + goto out_unlock_mmap;
That check for VM_IO | VM_PFNMAP was previously hidden inside follow_pfn(),
and that would have returned -EINVAL in this case. With your change, we
now return -EACCES. Not sure how important that is, but it feels wrong.
Maybe move the VM_IO | VM_PFNMAP check up, before the ret = -EACCES?
[...]
> @@ -306,22 +306,38 @@ SYSCALL_DEFINE3(s390_pci_mmio_read, unsigned long,
> mmio_addr,
> buf = local_buf;
> }
>
> - ret = get_pfn(mmio_addr, VM_READ, &pfn);
> + mmap_read_lock(current->mm);
> + ret = -EINVAL;
> + vma = find_vma(current->mm, mmio_addr);
> + if (!vma)
> + goto out_unlock_mmap;
> + ret = -EACCES;
> +
Patch "drm/nouveau/device: return error for unknown chipsets" has been added to the 5.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/nouveau/device: return error for unknown chipsets
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-device-return-error-for-unknown-chipsets.patch
and it can be found in the queue-5.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From c3e0276c31ca8c7b8615da890727481260d4676f Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Wed, 7 Oct 2020 00:05:27 +0200
Subject: drm/nouveau/device: return error for unknown chipsets
From: Karol Herbst
commit c3e0276c31ca8c7b8615da890727481260d4676f upstream.
Previously the code relied on device->pri to be NULL and to fail probing
later. We really should just return an error inside nvkm_device_ctor for
unsupported GPUs.
Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid
of second map")
Signed-off-by: Karol Herbst
Cc: dann frazier
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Reviewed-by: Jeremy Cline
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -3149,6 +3149,7 @@ nvkm_device_ctor(const struct nvkm_devic
case 0x168: device->chip = &nv168_chipset; break;
default:
nvdev_error(device, "unknown chipset (%08x)\n", boot0);
+ ret = -ENODEV;
goto done;
}
Patches currently in stable-queue which might be from kher...@redhat.com are
queue-5.8/drm-nouveau-device-return-error-for-unknown-chipsets.patch
queue-5.8/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: introduce vma_set_file function v2
Am 08.10.20 um 23:49 schrieb John Hubbard: On 10/8/20 4:23 AM, Christian König wrote: Add the new vma_set_file() function to allow changing vma->vm_file with the necessary refcount dance. v2: add more users of this. Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 16 +--- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +--- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++-- drivers/gpu/drm/msm/msm_gem.c | 4 +--- drivers/gpu/drm/omapdrm/omap_gem.c | 3 +-- drivers/gpu/drm/vgem/vgem_drv.c | 3 +-- drivers/staging/android/ashmem.c | 5 ++--- include/linux/mm.h | 2 ++ mm/mmap.c | 16 10 files changed, 32 insertions(+), 28 deletions(-) Looks like a nice cleanup. Two comments below. ... diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 3d69e51f3e4d..c9d5f1a38af3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -893,8 +893,8 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma) * requires avoiding extraneous references to their filp, hence why * we prefer to use an anonymous file for their mmaps. */ - fput(vma->vm_file); - vma->vm_file = anon; + vma_set_file(vma, anon); + fput(anon); That's one fput() too many, isn't it? No, the other cases were replacing the vm_file with something pre-allocated and also grabbed a new reference. But this case here uses the freshly allocated anon file and so vma_set_file() grabs another extra reference which we need to drop. The alternative is to just keep it as it is. Opinions? ... diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 10b4be1f3e78..a51dc089896e 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -450,9 +450,8 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma) vma_set_anonymous(vma); } - if (vma->vm_file) - fput(vma->vm_file); - vma->vm_file = asma->file; + vma_set_file(vma, asma->file); + fput(asma->file); Same here: that fput() seems wrong, as it was already done within vma_set_file(). No, that case is correct as well. The Android code here has the matching get_file() a few lines up, see the surrounding code. I didn't wanted to replace that since it does some strange error handling here, so the result is that we need to drop the extra reference as again. We could also keep it like it is or maybe better put a TODO comment on it. Regards, Christian. thanks, ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/nouveau/mem: guard against NULL pointer access in mem_del" has been added to the 5.8-stable tree
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 5.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
and it can be found in the queue-5.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d10285a25e29f13353bbf7760be8980048c1ef2f Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Wed, 7 Oct 2020 00:05:28 +0200
Subject: drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
Patches currently in stable-queue which might be from kher...@redhat.com are
queue-5.8/drm-nouveau-device-return-error-for-unknown-chipsets.patch
queue-5.8/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: introduce vma_set_file function v2
On 10/9/20 12:33 AM, Christian König wrote: Am 08.10.20 um 23:49 schrieb John Hubbard: On 10/8/20 4:23 AM, Christian König wrote: ... diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 3d69e51f3e4d..c9d5f1a38af3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -893,8 +893,8 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma) * requires avoiding extraneous references to their filp, hence why * we prefer to use an anonymous file for their mmaps. */ - fput(vma->vm_file); - vma->vm_file = anon; + vma_set_file(vma, anon); + fput(anon); That's one fput() too many, isn't it? No, the other cases were replacing the vm_file with something pre-allocated and also grabbed a new reference. But this case here uses the freshly allocated anon file and so vma_set_file() grabs another extra reference which we need to drop. The alternative is to just keep it as it is. Opinions? I think just a small comment for these cases, is probably about right. ... diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c index 10b4be1f3e78..a51dc089896e 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -450,9 +450,8 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma) vma_set_anonymous(vma); } - if (vma->vm_file) - fput(vma->vm_file); - vma->vm_file = asma->file; + vma_set_file(vma, asma->file); + fput(asma->file); Same here: that fput() seems wrong, as it was already done within vma_set_file(). No, that case is correct as well. The Android code here has the matching get_file() a few lines up, see the surrounding code. I didn't wanted to replace that since it does some strange error handling here, so the result is that we need to drop the extra reference as again. We could also keep it like it is or maybe better put a TODO comment on it. Yeah, I think a comment is a good way to go. thanks, -- John Hubbard NVIDIA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/prime: document that use the page array is deprecated
Am 08.10.20 um 16:14 schrieb Daniel Vetter: On Thu, Oct 08, 2020 at 04:09:14PM +0200, Daniel Vetter wrote: On Thu, Oct 08, 2020 at 01:23:40PM +0200, Christian König wrote: We have reoccurring requests on this so better document that this approach doesn't work and dma_buf_mmap() needs to be used instead. Signed-off-by: Christian König --- drivers/gpu/drm/drm_prime.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 4910c446db83..16fa2bfc271e 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -956,7 +956,7 @@ EXPORT_SYMBOL(drm_gem_prime_import); /** * drm_prime_sg_to_page_addr_arrays - convert an sg table into a page array * @sgt: scatter-gather table to convert - * @pages: optional array of page pointers to store the page array in + * @pages: deprecated array of page pointers to store the page array in * @addrs: optional array to store the dma bus address of each page * @max_entries: size of both the passed-in arrays * @@ -965,6 +965,11 @@ EXPORT_SYMBOL(drm_gem_prime_import); * * Drivers can use this in their &drm_driver.gem_prime_import_sg_table * implementation. + * + * Specifying the pages array is deprecated and strongly discouraged for new + * drivers. The pages array is only useful for page faults and those can + * corrupt fields in the struct page if they are not handled by the exporting + * driver. */ I'd make this a _lot_ stronger: Aside from amdgpu and radeon all drivers using this only need it for the pages array. Imo just open-code the sg table walking loop in amdgpu/radeon (it's really not much code), and then drop the dma_addr_t parameter from this function here (it's set to NULL by everyone else). And then deprecate this entire function here with a big warning that a) dma_buf_map_attachment is allowed to leave the struct page pointers NULL and b) this breaks mmap, users must call dma_buf_mmap instead. Also maybe make it an uppercase DEPRECATED or something like that :-) OK I just realized I missed nouveau. That would be 3 places where we need to stuff the dma_addr_t list into something ttm can take. Still feels better than this half-deprecated function kludge ... Mhm, I don't see a reason why nouveau would need the struct page either. How about we split that up into two function? One for converting the sg_table into a linear dma_addr array. And one for converting the sg_table into a linear struct page array with a __deprecated attribute on it? Christian. -Daniel -Daniel int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages, dma_addr_t *addrs, int max_entries) -- 2.17.1 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/nouveau/mem: guard against NULL pointer access in mem_del" has been added to the 4.19-stable tree
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d10285a25e29f13353bbf7760be8980048c1ef2f Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Wed, 7 Oct 2020 00:05:28 +0200
Subject: drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
Patches currently in stable-queue which might be from kher...@redhat.com are
queue-4.19/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/nouveau/mem: guard against NULL pointer access in mem_del" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/nouveau/mem: guard against NULL pointer access in mem_del
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From d10285a25e29f13353bbf7760be8980048c1ef2f Mon Sep 17 00:00:00 2001
From: Karol Herbst
Date: Wed, 7 Oct 2020 00:05:28 +0200
Subject: drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
Patches currently in stable-queue which might be from kher...@redhat.com are
queue-5.4/drm-nouveau-mem-guard-against-null-pointer-access-in-mem_del.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:
On 10/9/20 12:44 PM, Thomas Zimmermann wrote: > Hi > > Am 09.10.20 um 08:47 schrieb Thomas Zimmermann: >> NACK for the entire lack of any form of commit description. > > Please see the documentation at [1] on how to describe the changes and > getting your patches merged. Yes, I tried to use git send-email to send patches this time, and it resulted in this disaster. I'll stick to sending them through Thunderbird. > > Best regards > Thomas > > [1] ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: introduce vma_set_file function v2
On Fri, Oct 09, 2020 at 09:16:49AM +0200, Christian König wrote:
> Am 08.10.20 um 16:12 schrieb Daniel Vetter:
> > On Thu, Oct 08, 2020 at 01:23:39PM +0200, Christian König wrote:
> > > Add the new vma_set_file() function to allow changing
> > > vma->vm_file with the necessary refcount dance.
> > >
> > > v2: add more users of this.
> > >
> > > Signed-off-by: Christian König
> > > ---
> > > drivers/dma-buf/dma-buf.c | 16 +---
> > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
> > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
> > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4 ++--
> > > drivers/gpu/drm/msm/msm_gem.c | 4 +---
> > > drivers/gpu/drm/omapdrm/omap_gem.c | 3 +--
> > > drivers/gpu/drm/vgem/vgem_drv.c| 3 +--
> > > drivers/staging/android/ashmem.c | 5 ++---
> > > include/linux/mm.h | 2 ++
> > > mm/mmap.c | 16
> > > 10 files changed, 32 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index a6ba4d598f0e..e4316aa7e0f4 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -1163,20 +1163,14 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
> > > vm_area_struct *vma,
> > > return -EINVAL;
> > > /* readjust the vma */
> > > - get_file(dmabuf->file);
> > > - oldfile = vma->vm_file;
> > > - vma->vm_file = dmabuf->file;
> > > + oldfile = vma_set_file(vma, dmabuf->file);
> > > vma->vm_pgoff = pgoff;
> > > ret = dmabuf->ops->mmap(dmabuf, vma);
> > > - if (ret) {
> > > - /* restore old parameters on failure */
> > > - vma->vm_file = oldfile;
> > > - fput(dmabuf->file);
> > > - } else {
> > > - if (oldfile)
> > > - fput(oldfile);
> > > - }
> > > + /* restore old parameters on failure */
> > > + if (ret)
> > > + vma_set_file(vma, oldfile);
> > I think these two lines here are cargo-cult: If this fails, the mmap fails
> > and therefore the vma structure is kfreed. No point at all in restoring
> > anything.
>
> This was explicitly added with this patch to fix a problem:
>
> commit 495c10cc1c0c359871d5bef32dd173252fc17995
> Author: John Sheu
> Date: Mon Feb 11 17:50:24 2013 -0800
>
> CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
>
> Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
> themselves on failure. Not restoring the struct's data on failure
> causes a double-decrement of the vm_file's refcount.
>
> > With that: Reviewed-by: Daniel Vetter
>
> Can I keep that even with the error handling working? :)
Hm good find, I should have looked at git history myself.
I just noticed this here in the patch because everyone else does not do
this. But looking at the mmap_region() code in mmap.c we seem to indeed
have this problem for the error path:
unmap_and_free_vma:
vma->vm_file = NULL;
fput(file);
Note that the success path does things correctly (a bit above):
file = vma->vm_file;
out:
So it indeed looks like dma-buf is the only one that does this fully
correctly. So maybe we should do a follow-up patch to change the
mmap_region exit code to pick up whatever vma->vm_file was set instead,
and fput that?
Anyway I correct, r-b: as-is.
Cheers, Daniel
>
> Christian.
>
> >
> > > +
> > > return ret;
> > > }
> > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > index 312e9d58d5a7..10ce267c0947 100644
> > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > @@ -145,10 +145,8 @@ static int etnaviv_gem_mmap_obj(struct
> > > etnaviv_gem_object *etnaviv_obj,
> > >* address_space (so unmap_mapping_range does what we
> > > want,
> > >* in particular in the case of mmap'd dmabufs)
> > >*/
> > > - fput(vma->vm_file);
> > > - get_file(etnaviv_obj->base.filp);
> > > vma->vm_pgoff = 0;
> > > - vma->vm_file = etnaviv_obj->base.filp;
> > > + vma_set_file(vma, etnaviv_obj->base.filp);
> > > vma->vm_page_prot = vm_page_prot;
> > > }
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > index fec0e1e3dc3e..8ce4c9e28b87 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > > @@ -119,8 +119,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf
> > > *dma_buf, struct vm_area_struct *
> > > if (ret)
> > > return ret;
> > > - fput(vma->vm_file);
> > > - vma->vm_file = get_file(obj->base.filp);
> > > + vma_set_file(vma, obj->base.filp);
> > >
Re: [PATCH 2/4] drm/prime: document that use the page array is deprecated
On Fri, Oct 09, 2020 at 09:36:41AM +0200, Christian König wrote: > Am 08.10.20 um 16:14 schrieb Daniel Vetter: > > On Thu, Oct 08, 2020 at 04:09:14PM +0200, Daniel Vetter wrote: > > > On Thu, Oct 08, 2020 at 01:23:40PM +0200, Christian König wrote: > > > > We have reoccurring requests on this so better document that > > > > this approach doesn't work and dma_buf_mmap() needs to be used instead. > > > > > > > > Signed-off-by: Christian König > > > > --- > > > > drivers/gpu/drm/drm_prime.c | 7 ++- > > > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > > > > index 4910c446db83..16fa2bfc271e 100644 > > > > --- a/drivers/gpu/drm/drm_prime.c > > > > +++ b/drivers/gpu/drm/drm_prime.c > > > > @@ -956,7 +956,7 @@ EXPORT_SYMBOL(drm_gem_prime_import); > > > > /** > > > >* drm_prime_sg_to_page_addr_arrays - convert an sg table into a page > > > > array > > > >* @sgt: scatter-gather table to convert > > > > - * @pages: optional array of page pointers to store the page array in > > > > + * @pages: deprecated array of page pointers to store the page array in > > > >* @addrs: optional array to store the dma bus address of each page > > > >* @max_entries: size of both the passed-in arrays > > > >* > > > > @@ -965,6 +965,11 @@ EXPORT_SYMBOL(drm_gem_prime_import); > > > >* > > > >* Drivers can use this in their &drm_driver.gem_prime_import_sg_table > > > >* implementation. > > > > + * > > > > + * Specifying the pages array is deprecated and strongly discouraged > > > > for new > > > > + * drivers. The pages array is only useful for page faults and those > > > > can > > > > + * corrupt fields in the struct page if they are not handled by the > > > > exporting > > > > + * driver. > > > >*/ > > > I'd make this a _lot_ stronger: Aside from amdgpu and radeon all drivers > > > using this only need it for the pages array. Imo just open-code the sg > > > table walking loop in amdgpu/radeon (it's really not much code), and then > > > drop the dma_addr_t parameter from this function here (it's set to NULL by > > > everyone else). > > > > > > And then deprecate this entire function here with a big warning that a) > > > dma_buf_map_attachment is allowed to leave the struct page pointers NULL > > > and b) this breaks mmap, users must call dma_buf_mmap instead. > > > > > > Also maybe make it an uppercase DEPRECATED or something like that :-) > > OK I just realized I missed nouveau. That would be 3 places where we need > > to stuff the dma_addr_t list into something ttm can take. Still feels > > better than this half-deprecated function kludge ... > > Mhm, I don't see a reason why nouveau would need the struct page either. > > How about we split that up into two function? > > One for converting the sg_table into a linear dma_addr array. > > And one for converting the sg_table into a linear struct page array with a > __deprecated attribute on it? Yeah makes sense, since converting ttm to just use sgt iterations directly everywhere is probably a bit too much. Maybe keep that converter in ttm code, since outside of ttm the rough consensus is to converge on sgt for handling buffers. Well, for those drivers not stuck on struct page arrays :-) -Daniel > > Christian. > > > -Daniel > > > > > -Daniel > > > > > > > int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct > > > > page **pages, > > > > dma_addr_t *addrs, int max_entries) > > > > -- > > > > 2.17.1 > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/radeon: Add new callback that exposes vddc
This patch adds a callback for reporting vddc, to the dpm field of the
radeon_asic structure.
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cc4f58d16589..85a1cafdf303 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1992,6 +1992,7 @@ struct radeon_asic {
int (*get_fan_speed_percent)(struct radeon_device *rdev, u32
*speed);
u32 (*get_current_sclk)(struct radeon_device *rdev);
u32 (*get_current_mclk)(struct radeon_device *rdev);
+ u16 (*get_current_vddc)(struct radeon_device *rdev);
} dpm;
/* pageflipping */
struct {
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/radeon: Add implementation of get_current_vddc for Sumo
Add implementation of get_current_vddc() callback for Sumo.
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 1 +
drivers/gpu/drm/radeon/sumo_dpm.c| 20
3 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 495700d16fc9..8becbe09af2f 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1513,6 +1513,7 @@ static struct radeon_asic sumo_asic = {
.force_performance_level = &sumo_dpm_force_performance_level,
.get_current_sclk = &sumo_dpm_get_current_sclk,
.get_current_mclk = &sumo_dpm_get_current_mclk,
+ .get_current_vddc = &sumo_dpm_get_current_vddc,
},
.pflip = {
.page_flip = &evergreen_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index a74fa18cd27b..24644daead53 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -596,6 +596,7 @@ int sumo_dpm_force_performance_level(struct radeon_device
*rdev,
enum radeon_dpm_forced_level level);
u32 sumo_dpm_get_current_sclk(struct radeon_device *rdev);
u32 sumo_dpm_get_current_mclk(struct radeon_device *rdev);
+u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev);
/*
* cayman
diff --git a/drivers/gpu/drm/radeon/sumo_dpm.c
b/drivers/gpu/drm/radeon/sumo_dpm.c
index b95d5d390caf..f74f381af05f 100644
--- a/drivers/gpu/drm/radeon/sumo_dpm.c
+++ b/drivers/gpu/drm/radeon/sumo_dpm.c
@@ -1865,6 +1865,26 @@ u32 sumo_dpm_get_current_mclk(struct radeon_device *rdev)
return pi->sys_info.bootup_uma_clk;
}
+u16 sumo_dpm_get_current_vddc(struct radeon_device *rdev)
+{
+ struct sumo_power_info *pi = sumo_get_pi(rdev);
+ struct radeon_ps *rps = &pi->current_rps;
+ struct sumo_ps *ps = sumo_get_ps(rps);
+ struct sumo_pl *pl;
+ u32 current_index =
+ (RREG32(TARGET_AND_CURRENT_PROFILE_INDEX) & CURR_INDEX_MASK) >>
+ CURR_INDEX_SHIFT;
+
+ if (current_index == BOOST_DPM_LEVEL) {
+ pl = &pi->boost_pl;
+ } else if (current_index >= ps->num_levels) {
+ return 0;
+ } else {
+ pl = &ps->levels[current_index];
+ }
+ return sumo_convert_voltage_index_to_value(rdev, pl->vddc_index);
+}
+
void sumo_dpm_fini(struct radeon_device *rdev)
{
int i;
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: aspeed: Fix GENMASK misuse
On Mon, 24 Feb 2020 at 00:06, Andrew Jeffery wrote: > > > > On Sun, 23 Feb 2020, at 10:21, Ondrej Jirman wrote: > > Arguments to GENMASK should be msb >= lsb. > > > > Signed-off-by: Ondrej Jirman > > --- > > I just grepped the whole kernel tree for GENMASK argument order issues, > > and this is one of the three that popped up. No testing was done. > > I think someone's sent a patch previously, and last time it turned into a > discussion about how the macros aren't actually used and could be > removed. > > Regardless: > > Reviewed-by: Andrew Jeffery Thanks, I've applied this to drm-misc-next. Apologies for the delay. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/radeon: Expose vddc through hwmon
Create hwmon attribute for vddc, that uses previously declared
get_current_vddc() callback if there's an implementation available.
Also hides vddc, if there is no implementation for the current chipset (as per
Alexander Deucher's suggestion).
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_pm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 05c4196a8212..65d172b13e06 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -737,6 +737,26 @@ static ssize_t radeon_hwmon_show_sclk(struct device *dev,
static SENSOR_DEVICE_ATTR(freq1_input, S_IRUGO, radeon_hwmon_show_sclk, NULL,
0);
+static ssize_t radeon_hwmon_show_vddc(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct radeon_device *rdev = dev_get_drvdata(dev);
+ struct drm_device *ddev = rdev->ddev;
+ u16 vddc = 0;
+
+ /* Can't get vddc when the card is off */
+ if ((rdev->flags & RADEON_IS_PX) &&
+ (ddev->switch_power_state != DRM_SWITCH_POWER_ON))
+ return -EINVAL;
+
+ if (rdev->asic->dpm.get_current_vddc)
+ vddc = rdev->asic->dpm.get_current_vddc(rdev);
+
+ return snprintf(buf, PAGE_SIZE, "%u\n", vddc);
+}
+
+static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, radeon_hwmon_show_vddc, NULL,
+ 0);
static struct attribute *hwmon_attributes[] = {
&sensor_dev_attr_temp1_input.dev_attr.attr,
@@ -747,6 +767,7 @@ static struct attribute *hwmon_attributes[] = {
&sensor_dev_attr_pwm1_min.dev_attr.attr,
&sensor_dev_attr_pwm1_max.dev_attr.attr,
&sensor_dev_attr_freq1_input.dev_attr.attr,
+ &sensor_dev_attr_in0_input.dev_attr.attr,
NULL
};
@@ -765,7 +786,13 @@ static umode_t hwmon_attributes_visible(struct kobject
*kobj,
attr == &sensor_dev_attr_pwm1_enable.dev_attr.attr ||
attr == &sensor_dev_attr_pwm1_max.dev_attr.attr ||
attr == &sensor_dev_attr_pwm1_min.dev_attr.attr ||
-attr == &sensor_dev_attr_freq1_input.dev_attr.attr))
+attr == &sensor_dev_attr_freq1_input.dev_attr.attr ||
+attr == &sensor_dev_attr_in0_input.dev_attr.attr))
+ return 0;
+
+ /* Skip vddc attribute if get_current_vddc is not implemented */
+ if(attr == &sensor_dev_attr_in0_input.dev_attr.attr &&
+ !rdev->asic->dpm.get_current_vddc)
return 0;
/* Skip fan attributes if fan is not present */
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:
Hi Am 09.10.20 um 09:38 schrieb Sandeep Raghuraman: > > > On 10/9/20 12:44 PM, Thomas Zimmermann wrote: >> Hi >> >> Am 09.10.20 um 08:47 schrieb Thomas Zimmermann: >>> NACK for the entire lack of any form of commit description. >> >> Please see the documentation at [1] on how to describe the changes and >> getting your patches merged. > > Yes, I tried to use git send-email to send patches this time, and it resulted > in this disaster. I'll stick to sending them through Thunderbird. What's the problem with send-email? A typical call for your patchset would look like git send-mail ...HEAD --cover-letter --annotate --to=... --cc=... That allows you to write the cover letter and have it sent out. IIRC you need ot set $EDITOR to your favorite text editor; and configure the SMTP server in ~/.gitconfig, under [sendemail]. Best regards Thomas > >> >> Best regards >> Thomas >> >> [1] > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer 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 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
>
> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
> to their defaults. No functional changes are made.
>
> Signed-off-by: Thomas Zimmermann
I just found this in my inbox. I assume it has not been applied as you
were after a review.
Reviewed-by: Joel Stanley
I will apply it to drm-misc-next.
Cheers,
Joel
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 6b27242b9ee3c..1167ff78e24a3 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
>
> static struct drm_driver aspeed_gfx_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> - .gem_create_object = drm_cma_gem_create_object_default_funcs,
> - .dumb_create= drm_gem_cma_dumb_create,
> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> - .gem_prime_mmap = drm_gem_prime_mmap,
> + DRM_GEM_CMA_DRIVER_OPS,
> .fops = &fops,
> .name = "aspeed-gfx-drm",
> .desc = "ASPEED GFX DRM",
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/17] misc/habana: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
--
v2: Use unpin_user_pages_dirty_lock (John)
---
drivers/misc/habanalabs/Kconfig | 1 -
drivers/misc/habanalabs/common/habanalabs.h | 3 +-
drivers/misc/habanalabs/common/memory.c | 49 -
3 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/drivers/misc/habanalabs/Kconfig b/drivers/misc/habanalabs/Kconfig
index 8eb5d38c618e..2f04187f7167 100644
--- a/drivers/misc/habanalabs/Kconfig
+++ b/drivers/misc/habanalabs/Kconfig
@@ -6,7 +6,6 @@
config HABANA_AI
tristate "HabanaAI accelerators (habanalabs)"
depends on PCI && HAS_IOMEM
- select FRAME_VECTOR
select DMA_SHARED_BUFFER
select GENERIC_ALLOCATOR
select HWMON
diff --git a/drivers/misc/habanalabs/common/habanalabs.h
b/drivers/misc/habanalabs/common/habanalabs.h
index edbd627b29d2..c1b3ad613b15 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -881,7 +881,8 @@ struct hl_ctx_mgr {
struct hl_userptr {
enum vm_type_t vm_type; /* must be first */
struct list_headjob_node;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
enum dma_data_direction dir;
struct list_headdebugfs_list;
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 5ff4688683fd..327b64479f97 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1281,45 +1281,41 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
return -EFAULT;
}
- userptr->vec = frame_vector_create(npages);
- if (!userptr->vec) {
+ userptr->pages = kvmalloc_array(npages, sizeof(*userptr->pages),
+ GFP_KERNEL);
+ if (!userptr->pages) {
dev_err(hdev->dev, "Failed to create frame vector\n");
return -ENOMEM;
}
- rc = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- userptr->vec);
+ rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+userptr->pages);
if (rc != npages) {
dev_err(hdev->dev,
"Failed to map host memory, user ptr probably wrong\n");
if (rc < 0)
- goto destroy_framevec;
+ goto destroy_pages;
+ npages = rc;
rc = -EFAULT;
- goto put_framevec;
- }
-
- if (frame_vector_to_pages(userptr->vec) < 0) {
- dev_err(hdev->dev,
- "Failed to translate frame vector to pages\n");
- rc = -EFAULT;
- goto put_framevec;
+ goto put_pages;
}
+ userptr->npages = npages;
rc = sg_alloc_table_from_pages(userptr->sgt,
- frame_vector_pages(userptr->vec),
- npages, offset, size, GFP_ATOMIC);
+ userptr->pages,
+ npages, offset, size, GFP_ATOMIC);
if (rc < 0) {
dev_err(hdev->dev, "failed to create SG table from pages\n");
- goto put_framevec;
+ goto put_pages;
}
return 0;
-put_framevec:
- put_vaddr_frames(userptr->vec);
-destroy_framevec:
- frame_vector_destroy(userptr->vec);
+put_pages:
+ unpin_user_pages(userptr->pages, npages);
+destroy_pages:
+ kvfree(userptr->pages);
return rc;
}
@@ -1405,8 +1401,6 @@ int hl_pin_host_memory(struct hl_device *hdev, u64 addr,
u64 size,
*/
void hl_unpin_host_memory(struct hl_device *hdev, struct hl_userptr *userptr)
{
- struct page **pages;
-
hl_debugfs_remove_userptr(hdev, userptr);
if (userptr->dma_mapped)
@@ -1414,15 +1408,8 @@ void hl_unpin_host_memory(struct hl_device *hdev, struct
hl_userptr *userptr)
userptr->sgt->nents,
userptr->dir);
- pages = frame_vector_pages(userptr->vec);
- if (!IS_ERR(pages)) {
- int i;
[PATCH v2 00/17] follow_pfn and other iomap races
Hi all,
Round two of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:
v1:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
And the discussion that sparked this journey:
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
Changes in v2:
- tons of small polish&fixes all over, thanks to all the reviewers who
spotted issues
- I managed to test at least the generic_access_phys and pci mmap revoke
stuff with a few gdb sessions using our i915 debug tools (hence now also
the drm/i915 patch to properly request all the pci bar regions)
- reworked approach for the pci mmap revoke: Infrastructure moved into
kernel/resource.c, address_space mapping is now set up at open time for
everyone (which required some sysfs changes). Does indeed look a lot
cleaner and a lot less invasive than I feared at first.
The big thing I can't test are all the frame_vector changes in habanalbas,
exynos and media. Gerald has given the s390 patch a spin already.
Review, testing, feedback all very much welcome.
Cheers, Daniel
Daniel Vetter (17):
drm/exynos: Stop using frame_vector helpers
drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
misc/habana: Stop using frame_vector helpers
misc/habana: Use FOLL_LONGTERM for userptr
mm/frame-vector: Use FOLL_LONGTERM
media: videobuf2: Move frame_vector into media subsystem
mm: Close race in generic_access_phys
s390/pci: Remove races against pte updates
mm: Add unsafe_follow_pfn
media/videbuf1|2: Mark follow_pfn usage as unsafe
vfio/type1: Mark follow_pfn as unsafe
PCI: Obey iomem restrictions for procfs mmap
/dev/mem: Only set filp->f_mapping
resource: Move devmem revoke code to resource framework
sysfs: Support zapping of binary attr mmaps
PCI: Revoke mappings like devmem
drm/i915: Properly request PCI BARs
arch/s390/pci/pci_mmio.c | 98 +++
drivers/char/mem.c| 86 +---
drivers/gpu/drm/exynos/Kconfig| 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 -
drivers/gpu/drm/i915/intel_uncore.c | 25 -
drivers/media/common/videobuf2/Kconfig| 1 -
drivers/media/common/videobuf2/Makefile | 1 +
.../media/common/videobuf2}/frame_vector.c| 54 --
drivers/media/platform/omap/Kconfig | 1 -
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
drivers/misc/habanalabs/Kconfig | 1 -
drivers/misc/habanalabs/common/habanalabs.h | 3 +-
drivers/misc/habanalabs/common/memory.c | 50 --
drivers/pci/pci-sysfs.c | 4 +
drivers/pci/proc.c| 6 ++
drivers/vfio/vfio_iommu_type1.c | 4 +-
fs/sysfs/file.c | 11 +++
include/linux/ioport.h| 6 +-
include/linux/mm.h| 47 +
include/linux/sysfs.h | 2 +
include/media/videobuf2-core.h| 42
kernel/resource.c | 95 +-
mm/Kconfig| 3 -
mm/Makefile | 1 -
mm/memory.c | 76 +-
mm/nommu.c| 17
security/Kconfig | 13 +++
27 files changed, 412 insertions(+), 286 deletions(-)
rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/17] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ecede41af9b9..1e0c5a7f206e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -475,7 +475,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data
*g2d,
goto err_free;
}
- ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ ret = pin_user_pages_fast(start, npages,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/17] mm/frame-vector: Use FOLL_LONGTERM
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.
Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical section as suggested by Jason.
By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
--
v2: Streamline the code and further simplify the loop checks (Jason)
---
mm/frame_vector.c | 50 ++-
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 10f82d5643b6..d44779e56313 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -38,7 +38,6 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
struct vm_area_struct *vma;
int ret = 0;
int err;
- int locked;
if (nr_frames == 0)
return 0;
@@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
start = untagged_addr(start);
- mmap_read_lock(mm);
- locked = 1;
- vma = find_vma_intersection(mm, start, start + 1);
- if (!vma) {
- ret = -EFAULT;
- goto out;
- }
-
- /*
-* While get_vaddr_frames() could be used for transient (kernel
-* controlled lifetime) pinning of memory pages all current
-* users establish long term (userspace controlled lifetime)
-* page pinning. Treat get_vaddr_frames() like
-* get_user_pages_longterm() and disallow it for filesystem-dax
-* mappings.
-*/
- if (vma_is_fsdax(vma)) {
- ret = -EOPNOTSUPP;
- goto out;
- }
-
- if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
+ ret = pin_user_pages_fast(start, nr_frames,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
+ (struct page **)(vec->ptrs));
+ if (ret > 0) {
vec->got_ref = true;
vec->is_pfns = false;
- ret = pin_user_pages_locked(start, nr_frames,
- gup_flags, (struct page **)(vec->ptrs), &locked);
- goto out;
+ goto out_unlocked;
}
+ mmap_read_lock(mm);
vec->got_ref = false;
vec->is_pfns = true;
do {
unsigned long *nums = frame_vector_pfns(vec);
+ vma = find_vma_intersection(mm, start, start + 1);
+ if (!vma)
+ break;
+
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
err = follow_pfn(vma, start, &nums[ret]);
if (err) {
@@ -92,17 +76,13 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
start += PAGE_SIZE;
ret++;
}
- /*
-* We stop if we have enough pages or if VMA doesn't completely
-* cover the tail page.
-*/
- if (ret >= nr_frames || start < vma->vm_end)
+ /* Bail out if VMA doesn't completely cover the tail page. */
+ if (start < vma->vm_end)
break;
- vma = find_vma_intersection(mm, start, start + 1);
- } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
+ } while (ret < nr_frames);
out:
- if (locked)
- mmap_read_unlock(mm);
+ mmap_read_unlock(mm);
+out_unlocked:
if (!ret)
ret = -EFAULT;
if (ret > 0)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/17] misc/habana: Use FOLL_LONGTERM for userptr
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay
Cc: Omer Shpigelman
Cc: Ofir Bitton
Cc: Tomer Tayar
Cc: Moti Haimovski
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Pawel Piskorski
---
drivers/misc/habanalabs/common/memory.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/habanalabs/common/memory.c
b/drivers/misc/habanalabs/common/memory.c
index 327b64479f97..767d3644c033 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1288,7 +1288,8 @@ static int get_user_memory(struct hl_device *hdev, u64
addr, u64 size,
return -ENOMEM;
}
- rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ rc = pin_user_pages_fast(start, npages,
+FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
userptr->pages);
if (rc != npages) {
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/17] drm/exynos: Stop using frame_vector helpers
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
--
v2: Use unpin_user_pages_dirty_lock (John)
---
drivers/gpu/drm/exynos/Kconfig | 1 -
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 47 +++--
2 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6417f374b923..43257ef3c09d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -88,7 +88,6 @@ comment "Sub-drivers"
config DRM_EXYNOS_G2D
bool "G2D"
depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST
- select FRAME_VECTOR
help
Choose this option if you want to use Exynos G2D for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 967a5cdc120e..ecede41af9b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -205,7 +205,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t dma_addr;
unsigned long userptr;
unsigned long size;
- struct frame_vector *vec;
+ struct page **pages;
+ unsigned intnpages;
struct sg_table *sgt;
atomic_trefcount;
boolin_pool;
@@ -378,7 +379,6 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
bool force)
{
struct g2d_cmdlist_userptr *g2d_userptr = obj;
- struct page **pages;
if (!obj)
return;
@@ -398,15 +398,9 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
DMA_BIDIRECTIONAL, 0);
- pages = frame_vector_pages(g2d_userptr->vec);
- if (!IS_ERR(pages)) {
- int i;
-
- for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
- set_page_dirty_lock(pages[i]);
- }
- put_vaddr_frames(g2d_userptr->vec);
- frame_vector_destroy(g2d_userptr->vec);
+ unpin_user_pages_dirty_lock(g2d_userptr->pages, g2d_userptr->npages,
+ true);
+ kvfree(g2d_userptr->pages);
if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);
@@ -474,35 +468,34 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
g2d_data *g2d,
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
- g2d_userptr->vec = frame_vector_create(npages);
- if (!g2d_userptr->vec) {
+ g2d_userptr->pages = kvmalloc_array(npages, sizeof(*g2d_userptr->pages),
+ GFP_KERNEL);
+ if (!g2d_userptr->pages) {
ret = -ENOMEM;
goto err_free;
}
- ret = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
- g2d_userptr->vec);
+ ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
"failed to get user pages from userptr.\n");
if (ret < 0)
- goto err_destroy_framevec;
- ret = -EFAULT;
- goto err_put_framevec;
- }
- if (frame_vector_to_pages(g2d_userptr->vec) < 0) {
+ goto err_destroy_pages;
+ npages = ret;
ret = -EFAULT;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
+ g2d_userptr->npages = npages;
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
ret = -ENOMEM;
- goto err_put_framevec;
+ goto err_unpin_pages;
}
ret = sg_alloc_table_from_pages(sgt,
- frame_vector_pages(g2d_userptr->vec),
+ g2d_userptr->pages,
npages, offset, size, GFP_KERNEL);
if (ret < 0) {
DRM_DEV_ERROR(g2d->dev, "failed to get sgt from pages.\n");
@@ -538,11 +531,11 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct
g2d_data *g2d,
err_free_sgt:
kfree(sgt);
-err_put_framevec:
- put_vaddr_frames(g2d_userptr->v
[PATCH v2 08/17] s390/pci: Remove races against pte updates
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.
Since zpci_memcpy_from|toio seems to not do anything nefarious with
locks we just need to open code get_pfn and follow_pfn and make sure
we drop the locks only after we've done. The write function also needs
the copy_from_user move, since we can't take userspace faults while
holding the mmap sem.
Reviewed-by: Gerald Schaefer
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Niklas Schnelle
Cc: Gerald Schaefer
Cc: linux-s...@vger.kernel.org
--
v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
like before (Gerard)
---
arch/s390/pci/pci_mmio.c | 98 +++-
1 file changed, 57 insertions(+), 41 deletions(-)
diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
index 401cf670a243..1a6adbc68ee8 100644
--- a/arch/s390/pci/pci_mmio.c
+++ b/arch/s390/pci/pci_mmio.c
@@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem *dst,
return rc;
}
-static long get_pfn(unsigned long user_addr, unsigned long access,
- unsigned long *pfn)
-{
- struct vm_area_struct *vma;
- long ret;
-
- mmap_read_lock(current->mm);
- ret = -EINVAL;
- vma = find_vma(current->mm, user_addr);
- if (!vma)
- goto out;
- ret = -EACCES;
- if (!(vma->vm_flags & access))
- goto out;
- ret = follow_pfn(vma, user_addr, pfn);
-out:
- mmap_read_unlock(current->mm);
- return ret;
-}
-
SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
const void __user *, user_buffer, size_t, length)
{
u8 local_buf[64];
void __iomem *io_addr;
void *buf;
- unsigned long pfn;
+ struct vm_area_struct *vma;
+ pte_t *ptep;
+ spinlock_t *ptl;
long ret;
if (!zpci_is_enabled())
@@ -158,7 +140,7 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
mmio_addr,
* We only support write access to MIO capable devices if we are on
* a MIO enabled system. Otherwise we would have to check for every
* address if it is a special ZPCI_ADDR and would have to do
-* a get_pfn() which we don't need for MIO capable devices. Currently
+* a pfn lookup which we don't need for MIO capable devices. Currently
* ISM devices are the only devices without MIO support and there is no
* known need for accessing these from userspace.
*/
@@ -176,21 +158,37 @@ SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long,
mmio_addr,
} else
buf = local_buf;
- ret = get_pfn(mmio_addr, VM_WRITE, &pfn);
+ ret = -EFAULT;
+ if (copy_from_user(buf, user_buffer, length))
+ goto out_free;
+
+ mmap_read_lock(current->mm);
+ ret = -EINVAL;
+ vma = find_vma(current->mm, mmio_addr);
+ if (!vma)
+ goto out_unlock_mmap;
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ goto out_unlock_mmap;
+ ret = -EACCES;
+ if (!(vma->vm_flags & VM_WRITE))
+ goto out_unlock_mmap;
+
+ ret = follow_pte_pmd(vma->vm_mm, mmio_addr, NULL, &ptep, NULL, &ptl);
if (ret)
- goto out;
- io_addr = (void __iomem *)((pfn << PAGE_SHIFT) |
+ goto out_unlock_mmap;
+
+ io_addr = (void __iomem *)((pte_pfn(*ptep) << PAGE_SHIFT) |
(mmio_addr & ~PAGE_MASK));
- ret = -EFAULT;
if ((unsigned long) io_addr < ZPCI_IOMAP_ADDR_BASE)
- goto out;
-
- if (copy_from_user(buf, user_buffer, length))
- goto out;
+ goto out_unlock_pt;
ret = zpci_memcpy_toio(io_addr, buf, length);
-out:
+out_unlock_pt:
+ pte_unmap_unlock(ptep, ptl);
+out_unlock_mmap:
+ mmap_read_unlock(current->mm);
+out_free:
if (buf != local_buf)
kfree(buf);
return ret;
@@ -274,7 +272,9 @@ SYSCALL_DEFINE3(s390
[PATCH v2 06/17] media: videobuf2: Move frame_vector into media subsystem
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).
Reviewed-by: John Hubbard
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Daniel Vetter
---
drivers/media/common/videobuf2/Kconfig| 1 -
drivers/media/common/videobuf2/Makefile | 1 +
.../media/common/videobuf2}/frame_vector.c| 2 +
drivers/media/platform/omap/Kconfig | 1 -
include/linux/mm.h| 42 ---
include/media/videobuf2-core.h| 42 +++
mm/Kconfig| 3 --
mm/Makefile | 1 -
8 files changed, 45 insertions(+), 48 deletions(-)
rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
diff --git a/drivers/media/common/videobuf2/Kconfig
b/drivers/media/common/videobuf2/Kconfig
index edbc99ebba87..d2223a12c95f 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
config VIDEOBUF2_MEMOPS
tristate
- select FRAME_VECTOR
config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/drivers/media/common/videobuf2/Makefile
b/drivers/media/common/videobuf2/Makefile
index 77bebe8b202f..54306f8d096c 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
videobuf2-common-objs := videobuf2-core.o
+videobuf2-common-objs += frame_vector.o
ifeq ($(CONFIG_TRACEPOINTS),y)
videobuf2-common-objs += vb2-trace.o
diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
similarity index 99%
rename from mm/frame_vector.c
rename to drivers/media/common/videobuf2/frame_vector.c
index d44779e56313..2b0b97761d15 100644
--- a/mm/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -8,6 +8,8 @@
#include
#include
+#include
+
/**
* get_vaddr_frames() - map virtual addresses to pfns
* @start: starting user address
diff --git a/drivers/media/platform/omap/Kconfig
b/drivers/media/platform/omap/Kconfig
index f73b5893220d..de16de46c0f4 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
depends on VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
- select FRAME_VECTOR
help
V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 16b799a0522c..acd60fbf1a5a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1743,48 +1743,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned
long pages, bool inc);
int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
struct task_struct *task, bool bypass_rlim);
-/* Container for pinned pfns / pages */
-struct frame_vector {
- unsigned int nr_allocated; /* Number of frames we have space for */
- unsigned int nr_frames; /* Number of frames stored in ptrs array */
- bool got_ref; /* Did we pin pages by getting page ref? */
- bool is_pfns; /* Does array contain pages or pfns? */
- void *ptrs[]; /* Array of pinned pfns / pages. Use
-* pfns_vector_pages() or pfns_vector_pfns()
-* for access */
-};
-
-struct frame_vector *frame_vector_create(unsigned int nr_frames);
-void frame_vector_destroy(struct frame_vector *vec);
-int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
-unsigned int gup_flags, struct frame_vector *vec);
-void put_vaddr_frames(struct frame_vector *vec);
-int frame_vector_to_pages(struct frame_vector *vec);
-void frame_vector_to_pfns(struct frame_vector *vec);
-
-static inline unsigned int frame_vector_count(struct frame_vector *vec)
-{
- return vec->nr_frames;
-}
-
-static inline struct page **frame_vector_pages(struct frame_vector *vec)
-{
- if (vec->is_pfns) {
- int err = frame_vector_to_pages(vec);
-
- if (err)
- return ERR_PTR(err);
- }
- return (struct page **)(vec->ptrs);
-}
-
-static inline unsigned long *frame_vector_pfns(struct frame_vector *vec)
-{
- if (!vec->is_pfns)
- frame_vector_to_pfns(vec);
- return (unsigned long *)(vec->ptrs);
-}
-
struct kvec;
int get_kernel_pages(const struct
[PATCH v2 09/17] mm: Add unsafe_follow_pfn
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.
Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.
This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
---
include/linux/mm.h | 2 ++
mm/memory.c| 32 +++-
mm/nommu.c | 17 +
security/Kconfig | 13 +
4 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2a16631c1fda..ec8c90928fc9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1653,6 +1653,8 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
address,
pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index f7cbc4dde0ef..7c7b234ffb24 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4821,7 +4821,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
* @address: user virtual address
* @pfn: location to store found PFN
*
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a &mmu_notifier to follow
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
*
* Return: zero and the pfn at @pfn on success, -ve otherwise.
*/
@@ -4844,6 +4849,31 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
}
EXPORT_SYMBOL(follow_pfn);
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+#ifdef CONFIG_STRICT_FOLLOW_PFN
+ pr_info("unsafe follow_pfn usage rejected, see
CONFIG_STRICT_FOLLOW_PFN\n");
+ return -EINVAL;
+#else
+ WARN_ONCE(1, "unsafe follow_pfn usage\n");
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+ return follow_pfn(vma, address, pfn);
+#endif
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
#ifdef CONFIG_HAVE_IOREMAP_PROT
int follow_phys(struct vm_area_struct *vma,
unsigned long address, unsigned int flags,
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af1..3db2910f0d64 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -132,6 +132,23 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long
address,
}
EXPORT_SYMBOL(follow_pfn);
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn)
+{
+ return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
LIST_HEAD(vmap_area_list);
void vfree(const void *addr)
diff --git a/security/Kconfig b/security/Kconfig
inde
[PATCH v2 07/17] mm: Close race in generic_access_phys
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:
- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved
- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")
Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.
Since ioremap might need to manipulate pagetables too we need to drop
the pt lock and have a retry loop if we raced.
While at it, also add kerneldoc and improve the comment for the
vma_ops->access function. It's for accessing, not for moving the
memory from iomem to system memory, as the old comment seemed to
suggest.
References: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
Cc: Jason Gunthorpe
Cc: Dan Williams
Cc: Kees Cook
Cc: Rik van Riel
Cc: Benjamin Herrensmidt
Cc: Dave Airlie
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter
--
v2: Fix inversion in the retry check (John).
---
include/linux/mm.h | 3 ++-
mm/memory.c| 44 ++--
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index acd60fbf1a5a..2a16631c1fda 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -566,7 +566,8 @@ struct vm_operations_struct {
vm_fault_t (*pfn_mkwrite)(struct vm_fault *vmf);
/* called by access_process_vm when get_user_pages() fails, typically
-* for use by special VMAs that can switch between memory and hardware
+* for use by special VMAs. See also generic_access_phys() for a generic
+* implementation useful for any iomem mapping.
*/
int (*access)(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write);
diff --git a/mm/memory.c b/mm/memory.c
index fcfc4ca36eba..f7cbc4dde0ef 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4873,28 +4873,68 @@ int follow_phys(struct vm_area_struct *vma,
return ret;
}
+/**
+ * generic_access_phys - generic implementation for iomem mmap access
+ * @vma: the vma to access
+ * @addr: userspace addres, not relative offset within @vma
+ * @buf: buffer to read/write
+ * @len: length of transfer
+ * @write: set to FOLL_WRITE when writing, otherwise reading
+ *
+ * This is a generic implementation for &vm_operations_struct.access for an
+ * iomem mapping. This callback is used by access_process_vm() when the @vma is
+ * not page based.
+ */
int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
{
resource_size_t phys_addr;
unsigned long prot = 0;
void __iomem *maddr;
+ pte_t *ptep, pte;
+ spinlock_t *ptl;
int offset = addr & (PAGE_SIZE-1);
+ int ret = -EINVAL;
+
+ if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+ return -EINVAL;
+
+retry:
+ if (follow_pte(vma->vm_mm, addr, &ptep, &ptl))
+ return -EINVAL;
+ pte = *ptep;
+ pte_unmap_unlock(ptep, ptl);
- if (follow_phys(vma, addr, write, &prot, &phys_addr))
+ prot = pgprot_val(pte_pgprot(pte));
+ phys_addr = (resource_size_t)pte_pfn(pte) << PAGE_SHIFT;
+
+ if ((write & FOLL_WRITE) && !pte_write(pte))
return -EINVAL;
maddr = ioremap_prot(phys_addr, PAGE_ALIGN(len + offset), prot);
if (!maddr)
return -ENOMEM;
+ if (follow_pte(vma->vm_mm, addr, &ptep, &ptl))
+ goto out_unmap;
+
+ if (!pte_same(pte, *ptep)) {
+ pte_unmap_unlock(ptep, ptl);
+ iounmap(maddr);
+
+ goto retry;
+ }
+
if (write)
memcpy_toio(maddr + offset, buf, len);
else
memcpy_fromio(buf, maddr + offset, len);
+ ret = len;
+ pte_unmap_unlock(ptep, ptl);
+out_unmap:
iounmap(maddr);
- return len;
+ return ret;
}
EXPORT_SYMBOL_GPL(generic_access_phys);
#endif
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/17] vfio/type1: Mark follow_pfn as unsafe
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.
Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.
Real fix is to wire up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Alex Williamson
Cc: Cornelia Huck
Cc: k...@vger.kernel.org
---
drivers/vfio/vfio_iommu_type1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5fbf0c1f7433..a4d53f3d0a35 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -421,7 +421,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
{
int ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
if (ret) {
bool unlocked = false;
@@ -435,7 +435,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma,
struct mm_struct *mm,
if (ret)
return ret;
- ret = follow_pfn(vma, vaddr, pfn);
+ ret = unsafe_follow_pfn(vma, vaddr, pfn);
}
return ret;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/17] PCI: Revoke mappings like devmem
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.
Except there's two more ways to access PCI BARs: sysfs and proc mmap
support. Let's plug that hole.
For revoke_devmem() to work we need to link our vma into the same
address_space, with consistent vma->vm_pgoff. ->pgoff is already
adjusted, because that's how (io_)remap_pfn_range works, but for the
mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
to adjust this at at ->open time:
- for sysfs this is easy, now that binary attributes support this. We
just set bin_attr->mapping when mmap is supported
- for procfs it's a bit more tricky, since procfs pci access has only
one file per device, and access to a specific resources first needs
to be set up with some ioctl calls. But mmap is only supported for
the same resources as sysfs exposes with mmap support, and otherwise
rejected, so we can set the mapping unconditionally at open time
without harm.
A special consideration is for arch_can_pci_mmap_io() - we need to
make sure that the ->f_mapping doesn't alias between ioport and iomem
space. There's only 2 ways in-tree to support mmap of ioports: generic
pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
architecture hand-rolling. Both approach support ioport mmap through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.
The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: Greg Kroah-Hartman
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
--
v2:
- Totally new approach: Adjust filp->f_mapping at open time. Note that
this now works on all architectures, not just those support
ARCH_GENERIC_PCI_MMAP_RESOURCE
---
drivers/pci/pci-sysfs.c | 4
drivers/pci/proc.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6d78df981d41..cee38fcb4a86 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -928,6 +928,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_io);
error = device_create_bin_file(&b->dev, b->legacy_io);
if (error)
@@ -940,6 +941,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = 0600;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
+ b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(&b->dev, b->legacy_mem);
if (error)
@@ -1155,6 +1157,8 @@ static int pci_create_attr(struct pci_dev *pdev, int num,
int write_combine)
res_attr->mmap = pci_mmap_resource_uc;
}
}
+ if (res_attr->mmap)
+ res_attr->mapping = iomem_get_mapping();
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = 0600;
res_attr->size = pci_resource_len(pdev, num);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 3a2f90beb4cb..9bab07302bbf 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct
file *file)
fpriv->write_combine = 0;
file->private_data = fpriv;
+ file->f_mapping = iomem_get_mapping();
return 0;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/17] resource: Move devmem revoke code to resource framework
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.
To prepare for this, move the code from the /dev/kmem driver to
kernel/resource.c.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: David Hildenbrand
Cc: "Rafael J. Wysocki"
---
drivers/char/mem.c | 85 +
include/linux/ioport.h | 6 +--
kernel/resource.c | 95 +-
3 files changed, 96 insertions(+), 90 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5502f56f3655..53338aad8d28 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -31,9 +31,6 @@
#include
#include
#include
-#include
-#include
-#include
#ifdef CONFIG_IA64
# include
@@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t
offset, int orig)
return ret;
}
-static struct inode *devmem_inode;
-
-#ifdef CONFIG_IO_STRICT_DEVMEM
-void revoke_devmem(struct resource *res)
-{
- /* pairs with smp_store_release() in devmem_init_inode() */
- struct inode *inode = smp_load_acquire(&devmem_inode);
-
- /*
-* Check that the initialization has completed. Losing the race
-* is ok because it means drivers are claiming resources before
-* the fs_initcall level of init and prevent /dev/mem from
-* establishing mappings.
-*/
- if (!inode)
- return;
-
- /*
-* The expectation is that the driver has successfully marked
-* the resource busy by this point, so devmem_is_allowed()
-* should start returning false, however for performance this
-* does not iterate the entire resource range.
-*/
- if (devmem_is_allowed(PHYS_PFN(res->start)) &&
- devmem_is_allowed(PHYS_PFN(res->end))) {
- /*
-* *cringe* iomem=relaxed says "go ahead, what's the
-* worst that can happen?"
-*/
- return;
- }
-
- unmap_mapping_range(inode->i_mapping, res->start, resource_size(res),
1);
-}
-#endif
-
static int open_port(struct inode *inode, struct file *filp)
{
int rc;
@@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file *filp)
* revocations when drivers want to take over a /dev/mem mapped
* range.
*/
- filp->f_mapping = inode->i_mapping;
+ filp->f_mapping = iomem_get_mapping();
return 0;
}
@@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t *mode)
static struct class *mem_class;
-static int devmem_fs_init_fs_context(struct fs_context *fc)
-{
- return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type devmem_fs_type = {
- .name = "devmem",
- .owner = THIS_MODULE,
- .init_fs_context = devmem_fs_init_fs_context,
- .kill_sb= kill_anon_super,
-};
-
-static int devmem_init_inode(void)
-{
- static struct vfsmount *devmem_vfs_mount;
- static int devmem_fs_cnt;
- struct inode *inode;
- int rc;
-
- rc = simple_pin_fs(&devmem_fs_type, &devmem_vfs_mount, &devmem_fs_cnt);
- if (rc < 0) {
- pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
- return rc;
- }
-
- inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
- if (IS_ERR(inode)) {
- rc = PTR_ERR(inode);
- pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
- simple_release_fs(&devmem_vfs_mount, &devmem_fs_cnt);
- return rc;
- }
-
- /*
-* Publish /dev/mem initialized.
-* Pairs with smp_load_acquire() in revoke_devmem().
-*/
- smp_store_release(&devmem_inode, inode);
-
- return 0;
-}
-
static int __init chr_dev_init(void)
{
int minor;
@@ -1058,8 +977,6 @@ static int __init chr_dev_init(void)
*/
if ((minor == DEVPORT_MINOR) && !arch_has_dev_port())
continue;
- if ((minor == DEVMEM_MINOR) && devmem_init_inode() != 0)
- continue;
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
NULL, devlist[minor].name);
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 6c2b06fe8beb..8ffb61b36606 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -302,11 +302,7 @@ struct resource
[PATCH v2 12/17] PCI: Obey iomem restrictions for procfs mmap
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is loaded and using it.
Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().
References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
--
v2: Improve commit message (Bjorn)
---
drivers/pci/proc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index d35186b01d98..3a2f90beb4cb 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -274,6 +274,11 @@ static int proc_bus_pci_mmap(struct file *file, struct
vm_area_struct *vma)
else
return -EINVAL;
}
+
+ if (dev->resource[i].flags & IORESOURCE_MEM &&
+ iomem_is_exclusive(dev->resource[i].start))
+ return -EINVAL;
+
ret = pci_mmap_page_range(dev, i, vma,
fpriv->mmap_state, write_combine);
if (ret < 0)
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/17] /dev/mem: Only set filp->f_mapping
When we care about pagecache maintenance, we need to make sure that both f_mapping and i_mapping point at the right mapping. But for iomem mappings we only care about the virtual/pte side of things, so f_mapping is enough. Also setting inode->i_mapping was confusing me as a driver maintainer, since in e.g. drivers/gpu we don't do that. Per Dan this seems to be copypasta from places which do care about pagecache consistency, but not needed. Hence remove it for slightly less confusion. Signed-off-by: Daniel Vetter Cc: Jason Gunthorpe Cc: Kees Cook Cc: Dan Williams Cc: Andrew Morton Cc: John Hubbard Cc: Jérôme Glisse Cc: Jan Kara Cc: Dan Williams Cc: linux...@kvack.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org Cc: linux-me...@vger.kernel.org --- drivers/char/mem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index abd4ffdc8cde..5502f56f3655 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -864,7 +864,6 @@ static int open_port(struct inode *inode, struct file *filp) * revocations when drivers want to take over a /dev/mem mapped * range. */ - inode->i_mapping = devmem_inode->i_mapping; filp->f_mapping = inode->i_mapping; return 0; -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/17] media/videbuf1|2: Mark follow_pfn usage as unsafe
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.
This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.
userptr for normal memory will keep working as-is.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Laurent Dufour
Cc: Vlastimil Babka
Cc: Daniel Jordan
Cc: Michel Lespinasse
---
drivers/media/common/videobuf2/frame_vector.c | 2 +-
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/common/videobuf2/frame_vector.c
b/drivers/media/common/videobuf2/frame_vector.c
index 2b0b97761d15..a1b85fe9e7c1 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int
nr_frames,
break;
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
- err = follow_pfn(vma, start, &nums[ret]);
+ err = unsafe_follow_pfn(vma, start, &nums[ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
while (pages_done < (mem->size >> PAGE_SHIFT)) {
- ret = follow_pfn(vma, user_address, &this_pfn);
+ ret = unsafe_follow_pfn(vma, user_address, &this_pfn);
if (ret)
break;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 17/17] drm/i915: Properly request PCI BARs
When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
do nothing for i915. Because i915 doesn't request any regions, like
pretty much all drm pci drivers. I guess this is some very old
remnants from the userspace modesetting days, when we wanted to
co-exist with the fbdev driver. Which usually requested these
resources.
But makes me wonder why the pci subsystem doesn't just request
resource automatically when we map a bar and a pci driver is bound?
Knowledge about which pci bars we need kludged together from
intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
fake agp driver.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_uncore.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 54e201fdeba4..ce39049d8919 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore
*uncore)
struct pci_dev *pdev = i915->drm.pdev;
int mmio_bar;
int mmio_size;
+ int bar_selection;
+ int ret;
mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
+ bar_selection = BIT (2) | BIT(mmio_bar);
/*
-* Before gen4, the registers and the GTT are behind different BARs.
+* On gen3 the registers and the GTT are behind different BARs.
* However, from gen4 onwards, the registers and the GTT are shared
* in the same BAR, so we want to restrict this ioremap from
* clobbering the GTT which we want ioremap_wc instead. Fortunately,
@@ -1703,6 +1706,8 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
* generations up to Ironlake.
* For dgfx chips register range is expanded to 4MB.
*/
+ if (INTEL_GEN(i915) == 3)
+ bar_selection |= BIT(3);
if (INTEL_GEN(i915) < 5)
mmio_size = 512 * 1024;
else if (IS_DGFX(i915))
@@ -1710,8 +1715,15 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
else
mmio_size = 2 * 1024 * 1024;
+ ret = pci_request_selected_regions(pdev, bar_selection, "i915");
+ if (ret < 0) {
+ drm_err(&i915->drm, "failed to request pci bars\n");
+ return ret;
+ }
+
uncore->regs = pci_iomap(pdev, mmio_bar, mmio_size);
if (uncore->regs == NULL) {
+ pci_release_selected_regions(pdev, bar_selection);
drm_err(&i915->drm, "failed to map registers\n");
return -EIO;
}
@@ -1721,9 +1733,18 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
static void uncore_mmio_cleanup(struct intel_uncore *uncore)
{
- struct pci_dev *pdev = uncore->i915->drm.pdev;
+ struct drm_i915_private *i915 = uncore->i915;
+ struct pci_dev *pdev = i915->drm.pdev;
+ int mmio_bar;
+ int bar_selection;
+
+ mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
+ bar_selection = BIT (2) | BIT(mmio_bar);
+ if (INTEL_GEN(i915) == 3)
+ bar_selection |= BIT(3);
pci_iounmap(pdev, uncore->regs);
+ pci_release_selected_regions(pdev, bar_selection);
}
void intel_uncore_init_early(struct intel_uncore *uncore,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/17] sysfs: Support zapping of binary attr mmaps
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").
The simplest way to achieve this is by having the same filp->f_mapping
for all mappings, so that unmap_mapping_range can find them all, no
matter through which file they've been created. Since this must be set
at open time we need sysfs support for this.
Add an optional mapping parameter bin_attr, which is only consulted
when there's also an mmap callback, since without mmap support
allowing to adjust the ->f_mapping makes no sense.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Christian Brauner
Cc: "David S. Miller"
Cc: Michael Ellerman
Cc: Sourabh Jain
Cc: Daniel Vetter
Cc: Mauro Carvalho Chehab
Cc: Nayna Jain
---
fs/sysfs/file.c | 11 +++
include/linux/sysfs.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..9d8ccdb000e3 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -169,6 +169,16 @@ static int sysfs_kf_bin_mmap(struct kernfs_open_file *of,
return battr->mmap(of->file, kobj, battr, vma);
}
+static int sysfs_kf_bin_open(struct kernfs_open_file *of)
+{
+ struct bin_attribute *battr = of->kn->priv;
+
+ if (battr->mapping)
+ of->file->f_mapping = battr->mapping;
+
+ return 0;
+}
+
void sysfs_notify(struct kobject *kobj, const char *dir, const char *attr)
{
struct kernfs_node *kn = kobj->sd, *tmp;
@@ -240,6 +250,7 @@ static const struct kernfs_ops sysfs_bin_kfops_mmap = {
.read = sysfs_kf_bin_read,
.write = sysfs_kf_bin_write,
.mmap = sysfs_kf_bin_mmap,
+ .open = sysfs_kf_bin_open,
};
int sysfs_add_file_mode_ns(struct kernfs_node *parent,
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..a17a474d1601 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -164,11 +164,13 @@ __ATTRIBUTE_GROUPS(_name)
struct file;
struct vm_area_struct;
+struct address_space;
struct bin_attribute {
struct attributeattr;
size_t size;
void*private;
+ struct address_space*mapping;
ssize_t (*read)(struct file *, struct kobject *, struct bin_attribute *,
char *, loff_t, size_t);
ssize_t (*write)(struct file *, struct kobject *, struct bin_attribute
*,
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
Hi
Am 09.10.20 um 09:54 schrieb Joel Stanley:
> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
>>
>> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
>> to their defaults. No functional changes are made.
>>
>> Signed-off-by: Thomas Zimmermann
>
> I just found this in my inbox. I assume it has not been applied as you
> were after a review.
The patchset as a whole got an A-b and was merged a while ago.
>
> Reviewed-by: Joel Stanley
Nevertheless thanks for taking a look at the patch.
Best regards
Thomas
>
> I will apply it to drm-misc-next.
>
> Cheers,
>
> Joel
>
>> ---
>> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
>> 1 file changed, 1 insertion(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>> index 6b27242b9ee3c..1167ff78e24a3 100644
>> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>> @@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
>>
>> static struct drm_driver aspeed_gfx_driver = {
>> .driver_features= DRIVER_GEM | DRIVER_MODESET |
>> DRIVER_ATOMIC,
>> - .gem_create_object = drm_cma_gem_create_object_default_funcs,
>> - .dumb_create= drm_gem_cma_dumb_create,
>> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
>> - .gem_prime_mmap = drm_gem_prime_mmap,
>> + DRM_GEM_CMA_DRIVER_OPS,
>> .fops = &fops,
>> .name = "aspeed-gfx-drm",
>> .desc = "ASPEED GFX DRM",
>> --
>> 2.26.2
>>
--
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 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote:
>
> Hi
>
> Am 09.10.20 um 09:54 schrieb Joel Stanley:
> > On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
> >>
> >> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
> >> to their defaults. No functional changes are made.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >
> > I just found this in my inbox. I assume it has not been applied as you
> > were after a review.
>
> The patchset as a whole got an A-b and was merged a while ago.
I'm a bit confused, I couldn't see it in any tree. The aspeed one
seemed to have been skipped when applying the series.
I looked at today's linux-next and drm-misc-next.
> >
> > Reviewed-by: Joel Stanley
>
> Nevertheless thanks for taking a look at the patch.
>
> Best regards
> Thomas
>
> >
> > I will apply it to drm-misc-next.
> >
> > Cheers,
> >
> > Joel
> >
> >> ---
> >> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
> >> 1 file changed, 1 insertion(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> >> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> >> index 6b27242b9ee3c..1167ff78e24a3 100644
> >> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> >> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> >> @@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
> >>
> >> static struct drm_driver aspeed_gfx_driver = {
> >> .driver_features= DRIVER_GEM | DRIVER_MODESET |
> >> DRIVER_ATOMIC,
> >> - .gem_create_object = drm_cma_gem_create_object_default_funcs,
> >> - .dumb_create= drm_gem_cma_dumb_create,
> >> - .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> >> - .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> >> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> >> - .gem_prime_mmap = drm_gem_prime_mmap,
> >> + DRM_GEM_CMA_DRIVER_OPS,
> >> .fops = &fops,
> >> .name = "aspeed-gfx-drm",
> >> .desc = "ASPEED GFX DRM",
> >> --
> >> 2.26.2
> >>
>
> --
> 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
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
Hi
Am 09.10.20 um 10:06 schrieb Joel Stanley:
> On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 09.10.20 um 09:54 schrieb Joel Stanley:
>>> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann wrote:
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
to their defaults. No functional changes are made.
Signed-off-by: Thomas Zimmermann
>>>
>>> I just found this in my inbox. I assume it has not been applied as you
>>> were after a review.
>>
>> The patchset as a whole got an A-b and was merged a while ago.
>
> I'm a bit confused, I couldn't see it in any tree. The aspeed one
> seemed to have been skipped when applying the series.
>
> I looked at today's linux-next and drm-misc-next.
Indeed. The other patches are in drm-misc-next, but not this one. I must
have lost it during the merge process.
>
>>>
>>> Reviewed-by: Joel Stanley
>>
>> Nevertheless thanks for taking a look at the patch.
>>
>> Best regards
>> Thomas
>>
>>>
>>> I will apply it to drm-misc-next.
So please ahead and apply it. There's also an ack by Emil, which you may
want to add as well.
Acked-by: Emil Velikov
Sorry about missing the patch and thanks for taking care.
Best regards
Thomas
>>>
>>> Cheers,
>>>
>>> Joel
>>>
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 6b27242b9ee3c..1167ff78e24a3 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -188,12 +188,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
static struct drm_driver aspeed_gfx_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET |
DRIVER_ATOMIC,
- .gem_create_object = drm_cma_gem_create_object_default_funcs,
- .dumb_create= drm_gem_cma_dumb_create,
- .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
- .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
- .gem_prime_mmap = drm_gem_prime_mmap,
+ DRM_GEM_CMA_DRIVER_OPS,
.fops = &fops,
.name = "aspeed-gfx-drm",
.desc = "ASPEED GFX DRM",
--
2.26.2
>>
>> --
>> 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
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
Hi Rodrigo, How do we get W/A and rc6 changes in, do you have any details? Thanks, Srinivas -Original Message- From: Souza, Jose Sent: 06 October 2020 23:33 To: Vivi, Rodrigo ; ch...@chris-wilson.co.uk Cc: Ausmus, James ; Nikula, Jani ; Pandey, Hariom ; Roper, Matthew D ; intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; K, SrinivasX ; Surendrakumar Upadhyay, TejaskumarX Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote: > > > On Oct 6, 2020, at 10:48 AM, Chris Wilson wrote: > > > > Quoting Souza, Jose (2020-10-06 18:46:45) > > > +Rodrigo and Jani > > > > > > On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote: > > > > Removing force probe protection from EHL platform. Did not > > > > observe warnings, errors, flickering or any visual defects while > > > > doing ordinary tasks like browsing and editing documents in a > > > > two monitor setup. > > > > > > One of the requirements was also to have CI BAT all green and > > > shards as green is possible but EHL don't show up in CI results, we > > > actually have one single EHL machine in CI but I guess it is not able to > > > run all tests that shards do: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html > > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html > > we are really close to that point. We just need to fix some w/a and > rc6 issues before applying this change. > > > -Chris > Huum okay we have drm-tip results for EHL but if someone sends a patch that breaks EHL it will not be caught in pre-merge testing. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
Hi,
On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> This patch adds bindings for Intel KeemBay Display
>
> v2: review changes from Rob Herring
>
> Signed-off-by: Anitha Chrisanthus
> ---
> .../bindings/display/intel,keembay-display.yaml| 99
> ++
> 1 file changed, 99 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> new file mode 100644
> index 000..a38493d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> @@ -0,0 +1,99 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Devicetree bindings for Intel Keem Bay display controller
> +
> +maintainers:
> + - Anitha Chrisanthus
> + - Edmond J Dea
> +
> +properties:
> + compatible:
> +const: intel,kmb_display
> +
> + reg:
> +items:
> + - description: Lcd registers range
> + - description: Mipi registers range
Looking at the registers, the MIPI transceiver seems to be a separate IP,
same for D-PHY which should have a proper PHY driver instead of beeing handled
here.
> + - description: Msscam registers range
MSScam here seems to be a clock and reset controller for the LCD and MIPI IPs,
thus should be handler out of DRM.
> +
> + reg-names:
> +items:
> + - const: lcd
> + - const: mipi
> + - const: msscam
> +
> + clocks:
> +items:
> + - description: LCD controller clock
> + - description: Mipi DSI clock
> + - description: Mipi DSI econfig clock
> + - description: Mipi DSI config clock
> + - description: System clock or pll0 clock
> +
> + clock-names:
> +items:
> + - const: clk_lcd
> + - const: clk_mipi
> + - const: clk_mipi_ecfg
> + - const: clk_mipi_cfg
> + - const: clk_pll0
> +
> + interrupts:
> +maxItems: 1
> +
> + encoder-slave:
> +description: bridge node entry for mipi to hdmi converter
> +
> + port:
> +type: object
> +description: >
> + Port node with one endpoint connected to mipi to hdmi converter
> node.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - encoder-slave
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#define MOVISOC_KMB_MSS_AUX_LCD
> +#define MOVISOC_KMB_MSS_AUX_MIPI_TX0
> +#define MOVISOC_KMB_MSS_AUX_MIPI_ECFG
> +#define MOVISOC_KMB_MSS_AUX_MIPI_CFG
> +#define MOVISOC_KMB_A53_PLL_0_OUT_0
> +display@2090 {
> + compatible = "intel,keembay-display";
> + reg = <0x2093 0x3000>,
> +<0x2090 0x4000>,
> +<0x2091 0x30>;
> + reg-names = "lcd", "mipi", "msscam";
> + interrupts = ;
> + clocks = <&scmi_clk MOVISOC_KMB_MSS_AUX_LCD>,
> + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_TX0>,
> + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_ECFG>,
> + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_CFG>,
> + <&scmi_clk MOVISOC_KMB_A53_PLL_0_OUT_0>;
> + clock-names = "clk_lcd", "clk_mipi", "clk_mipi_ecfg",
> +"clk_mipi_cfg", "clk_pll0";
> +
> + encoder-slave = <&adv7535>;
> +
> + port {
> +dsi_output: endpoint {
> +remote-endpoint = <&adv7535_input>;
> +};
> + };
> +};
>
Anitha, Daniel, this keembay driver should be architectured like other ARM-like
display
controllers, with separate drivers for MIPI DSI bridge and msscam clock & reset
controller.
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: document that user-space should avoid parsing EDIDs
User-space should avoid parsing EDIDs for metadata already exposed via
other KMS interfaces and properties. For instance, user-space should not
try to extract a list of modes from the EDID: the kernel might mutate
the mode list (because of link capabilities or quirks for instance).
Other metadata not exposed by KMS can be parsed by user-space. This
includes for instance monitor identification (make/model/serial) and
supported color-spaces.
Signed-off-by: Simon Ser
Suggested-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 717c4e7271b0..00e58fd2d292 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
* drm_connector_update_edid_property(), usually after having parsed
* the EDID using drm_add_edid_modes(). Userspace cannot change this
* property.
+ *
+ * User-space should not parse the EDID to obtain information exposed via
+ * other KMS properties. For instance, user-space should not try to parse
+ * mode lists from the EDID.
* DPMS:
* Legacy property for setting the power state of the connector. For atomic
* drivers this is only provided for backwards compatibility with existing
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, Oct 9, 2020 at 11:24 AM Simon Ser wrote:
>
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_connector.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties. For instance, user-space should not try to parse
> + * mode lists from the EDID.
> * DPMS:
> * Legacy property for setting the power state of the connector. For
> atomic
> * drivers this is only provided for backwards compatibility with
> existing
> --
> 2.28.0
>
>
> ___
> 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 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> do nothing for i915. Because i915 doesn't request any regions, like
> pretty much all drm pci drivers. I guess this is some very old
> remnants from the userspace modesetting days, when we wanted to
> co-exist with the fbdev driver. Which usually requested these
> resources.
>
> But makes me wonder why the pci subsystem doesn't just request
> resource automatically when we map a bar and a pci driver is bound?
>
> Knowledge about which pci bars we need kludged together from
> intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> fake agp driver.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 54e201fdeba4..ce39049d8919 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
> struct pci_dev *pdev = i915->drm.pdev;
> int mmio_bar;
> int mmio_size;
> + int bar_selection;
Signed bitmasks always make me uneasy. But looks like
that's what it is in the pci api. So meh.
> + int ret;
>
> mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> + bar_selection = BIT (2) | BIT(mmio_bar);
^
spurious space
That's also not correct for gen2 I think.
gen2:
0 = GMADR
1 = MMADR
2 = IOBAR
gen3:
0 = MMADR
1 = IOBAR
2 = GMADR
3 = GTTADR
gen4+:
0+1 = GTTMMADR
2+3 = GMADR
4 = IOBAR
Maybe we should just have an explicit list of bars like that in a
comment?
I'd also suggest sucking this bitmask calculation into a small helper
so you can reuse it for the release.
> /*
> - * Before gen4, the registers and the GTT are behind different BARs.
> + * On gen3 the registers and the GTT are behind different BARs.
>* However, from gen4 onwards, the registers and the GTT are shared
>* in the same BAR, so we want to restrict this ioremap from
>* clobbering the GTT which we want ioremap_wc instead. Fortunately,
> @@ -1703,6 +1706,8 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
>* generations up to Ironlake.
>* For dgfx chips register range is expanded to 4MB.
>*/
> + if (INTEL_GEN(i915) == 3)
> + bar_selection |= BIT(3);
> if (INTEL_GEN(i915) < 5)
> mmio_size = 512 * 1024;
> else if (IS_DGFX(i915))
> @@ -1710,8 +1715,15 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
> else
> mmio_size = 2 * 1024 * 1024;
>
> + ret = pci_request_selected_regions(pdev, bar_selection, "i915");
> + if (ret < 0) {
> + drm_err(&i915->drm, "failed to request pci bars\n");
> + return ret;
> + }
> +
> uncore->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> if (uncore->regs == NULL) {
> + pci_release_selected_regions(pdev, bar_selection);
> drm_err(&i915->drm, "failed to map registers\n");
> return -EIO;
> }
> @@ -1721,9 +1733,18 @@ static int uncore_mmio_setup(struct intel_uncore
> *uncore)
>
> static void uncore_mmio_cleanup(struct intel_uncore *uncore)
> {
> - struct pci_dev *pdev = uncore->i915->drm.pdev;
> + struct drm_i915_private *i915 = uncore->i915;
> + struct pci_dev *pdev = i915->drm.pdev;
> + int mmio_bar;
> + int bar_selection;
> +
> + mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> + bar_selection = BIT (2) | BIT(mmio_bar);
> + if (INTEL_GEN(i915) == 3)
> + bar_selection |= BIT(3);
>
> pci_iounmap(pdev, uncore->regs);
> + pci_release_selected_regions(pdev, bar_selection);
> }
>
> void intel_uncore_init_early(struct intel_uncore *uncore,
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
Hi
Am 09.10.20 um 11:24 schrieb Simon Ser:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_connector.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties. For instance, user-space should not try to parse
> + * mode lists from the EDID.
Acked-by: Thomas Zimmermann
But this makes me wonder why the kernel exposes raw EDID in the first
place. Wouldn't it be better to expose meaningful fields (display model,
vendor, etc) instead?
Best regards
Thomas
> * DPMS:
> * Legacy property for setting the power state of the connector. For atomic
> * drivers this is only provided for backwards compatibility with existing
>
--
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] drm: document that user-space should avoid parsing EDIDs
Hi
Am 09.10.20 um 11:48 schrieb Thomas Zimmermann:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
>> User-space should avoid parsing EDIDs for metadata already exposed via
>> other KMS interfaces and properties. For instance, user-space should not
>> try to extract a list of modes from the EDID: the kernel might mutate
>> the mode list (because of link capabilities or quirks for instance).
>>
>> Other metadata not exposed by KMS can be parsed by user-space. This
>> includes for instance monitor identification (make/model/serial) and
>> supported color-spaces.
>>
>> Signed-off-by: Simon Ser
>> Suggested-by: Daniel Vetter
>> Cc: Daniel Vetter
>> Cc: Pekka Paalanen
>> Cc: Ville Syrjälä
>> ---
>> drivers/gpu/drm/drm_connector.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index 717c4e7271b0..00e58fd2d292 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[]
>> = {
>> * drm_connector_update_edid_property(), usually after having parsed
>> * the EDID using drm_add_edid_modes(). Userspace cannot change this
>> * property.
>> + *
>> + * User-space should not parse the EDID to obtain information exposed via
One nit: the rest of the file uses 'userspace' instead of 'user-space'.
>> + * other KMS properties. For instance, user-space should not try to parse
>> + * mode lists from the EDID.
>
> Acked-by: Thomas Zimmermann
>
> But this makes me wonder why the kernel exposes raw EDID in the first
> place. Wouldn't it be better to expose meaningful fields (display model,
> vendor, etc) instead?
>
> Best regards
> Thomas
>
>> * DPMS:
>> * Legacy property for setting the power state of the connector. For atomic
>> * drivers this is only provided for backwards compatibility with existing
>>
>
--
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 v2 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä
wrote:
>
> On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote:
> > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they
> > do nothing for i915. Because i915 doesn't request any regions, like
> > pretty much all drm pci drivers. I guess this is some very old
> > remnants from the userspace modesetting days, when we wanted to
> > co-exist with the fbdev driver. Which usually requested these
> > resources.
> >
> > But makes me wonder why the pci subsystem doesn't just request
> > resource automatically when we map a bar and a pci driver is bound?
> >
> > Knowledge about which pci bars we need kludged together from
> > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the
> > fake agp driver.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Kees Cook
> > Cc: Dan Williams
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Bjorn Helgaas
> > Cc: linux-...@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/intel_uncore.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index 54e201fdeba4..ce39049d8919 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore
> > *uncore)
> > struct pci_dev *pdev = i915->drm.pdev;
> > int mmio_bar;
> > int mmio_size;
> > + int bar_selection;
>
> Signed bitmasks always make me uneasy. But looks like
> that's what it is in the pci api. So meh.
Yeah it's surprising.
> > + int ret;
> >
> > mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> > + bar_selection = BIT (2) | BIT(mmio_bar);
>^
> spurious space
>
> That's also not correct for gen2 I think.
>
> gen2:
> 0 = GMADR
> 1 = MMADR
> 2 = IOBAR
>
> gen3:
> 0 = MMADR
> 1 = IOBAR
> 2 = GMADR
> 3 = GTTADR
>
> gen4+:
> 0+1 = GTTMMADR
> 2+3 = GMADR
> 4 = IOBAR
>
> Maybe we should just have an explicit list of bars like that in a
> comment?
>
> I'd also suggest sucking this bitmask calculation into a small helper
> so you can reuse it for the release.
tbh I just hacked this up for testing. Given how almost no other drm
driver does this, I'm wondering whether we should or not.
Also the only reason why I didn't just use the pci_request_regions
helper is to avoid the vga ioport range, since that's managed by
vgaarbiter.
So I think if we go for this for real we should:
- register the vga ioport range in the vgaarbiter
- have a pci_request_iomem_regions helper that grabs all mem bars
- roll that out to all drm pci drivers
Or something like that. The other complication is when we resize the
iobar. So not really sure what to do here.
-Daniel
>
> > /*
> > - * Before gen4, the registers and the GTT are behind different BARs.
> > + * On gen3 the registers and the GTT are behind different BARs.
> >* However, from gen4 onwards, the registers and the GTT are shared
> >* in the same BAR, so we want to restrict this ioremap from
> >* clobbering the GTT which we want ioremap_wc instead. Fortunately,
> > @@ -1703,6 +1706,8 @@ static int uncore_mmio_setup(struct intel_uncore
> > *uncore)
> >* generations up to Ironlake.
> >* For dgfx chips register range is expanded to 4MB.
> >*/
> > + if (INTEL_GEN(i915) == 3)
> > + bar_selection |= BIT(3);
> > if (INTEL_GEN(i915) < 5)
> > mmio_size = 512 * 1024;
> > else if (IS_DGFX(i915))
> > @@ -1710,8 +1715,15 @@ static int uncore_mmio_setup(struct intel_uncore
> > *uncore)
> > else
> > mmio_size = 2 * 1024 * 1024;
> >
> > + ret = pci_request_selected_regions(pdev, bar_selection, "i915");
> > + if (ret < 0) {
> > + drm_err(&i915->drm, "failed to request pci bars\n");
> > + return ret;
> > + }
> > +
> > uncore->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> > if (uncore->regs == NULL) {
> > + pci_release_selected_regions(pdev, bar_selection);
> > drm_err(&i915->drm, "failed to map registers\n");
> > return -EIO;
> > }
> > @@ -1721,9 +1733,18 @@ static int uncore_mmio_setup(struct intel_uncore
> > *uncore)
> >
> > static void uncore_mmio_cleanup(struct intel_uncore *uncore)
> > {
> > - struct pci_dev *pdev = uncore->i915->drm.pdev;
> > + struct drm_i915_private *i915 = uncore->i915;
> > + struct pci_dev *pdev = i915->drm.pdev;
> > + int mmio_bar;
> > + int bar_selection;
> > +
> > + mmio_bar = IS_GEN(i915, 2) ? 1 : 0;
> > + bar_selection =
Re: [PATCH v2 06/17] media: videobuf2: Move frame_vector into media subsystem
Em Fri, 9 Oct 2020 09:59:23 +0200
Daniel Vetter escreveu:
> It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
> symbol from all over the tree (well just one place, somehow omap media
> driver still had this in its Kconfig, despite not using it).
>
> Reviewed-by: John Hubbard
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: Mauro Carvalho Chehab
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Daniel Vetter
> ---
> drivers/media/common/videobuf2/Kconfig| 1 -
> drivers/media/common/videobuf2/Makefile | 1 +
> .../media/common/videobuf2}/frame_vector.c| 2 +
> drivers/media/platform/omap/Kconfig | 1 -
> include/linux/mm.h| 42 ---
> include/media/videobuf2-core.h| 42 +++
> mm/Kconfig| 3 --
> mm/Makefile | 1 -
> 8 files changed, 45 insertions(+), 48 deletions(-)
> rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
>
> diff --git a/drivers/media/common/videobuf2/Kconfig
> b/drivers/media/common/videobuf2/Kconfig
> index edbc99ebba87..d2223a12c95f 100644
> --- a/drivers/media/common/videobuf2/Kconfig
> +++ b/drivers/media/common/videobuf2/Kconfig
> @@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
>
> config VIDEOBUF2_MEMOPS
> tristate
> - select FRAME_VECTOR
>
> config VIDEOBUF2_DMA_CONTIG
> tristate
> diff --git a/drivers/media/common/videobuf2/Makefile
> b/drivers/media/common/videobuf2/Makefile
> index 77bebe8b202f..54306f8d096c 100644
> --- a/drivers/media/common/videobuf2/Makefile
> +++ b/drivers/media/common/videobuf2/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> videobuf2-common-objs := videobuf2-core.o
> +videobuf2-common-objs += frame_vector.o
>
> ifeq ($(CONFIG_TRACEPOINTS),y)
>videobuf2-common-objs += vb2-trace.o
> diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
> similarity index 99%
> rename from mm/frame_vector.c
> rename to drivers/media/common/videobuf2/frame_vector.c
> index d44779e56313..2b0b97761d15 100644
> --- a/mm/frame_vector.c
> +++ b/drivers/media/common/videobuf2/frame_vector.c
> @@ -8,6 +8,8 @@
> #include
> #include
>
> +#include
> +
See my comment below...
> /**
> * get_vaddr_frames() - map virtual addresses to pfns
> * @start: starting user address
> diff --git a/drivers/media/platform/omap/Kconfig
> b/drivers/media/platform/omap/Kconfig
> index f73b5893220d..de16de46c0f4 100644
> --- a/drivers/media/platform/omap/Kconfig
> +++ b/drivers/media/platform/omap/Kconfig
> @@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
> depends on VIDEO_V4L2
> select VIDEOBUF2_DMA_CONTIG
> select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
> - select FRAME_VECTOR
> help
> V4L2 Display driver support for OMAP2/3 based boards.
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 16b799a0522c..acd60fbf1a5a 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1743,48 +1743,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned
> long pages, bool inc);
> int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> struct task_struct *task, bool bypass_rlim);
>
> -/* Container for pinned pfns / pages */
> -struct frame_vector {
> - unsigned int nr_allocated; /* Number of frames we have space for */
> - unsigned int nr_frames; /* Number of frames stored in ptrs array */
> - bool got_ref; /* Did we pin pages by getting page ref? */
> - bool is_pfns; /* Does array contain pages or pfns? */
> - void *ptrs[]; /* Array of pinned pfns / pages. Use
> - * pfns_vector_pages() or pfns_vector_pfns()
> - * for access */
> -};
> -
> -struct frame_vector *frame_vector_create(unsigned int nr_frames);
> -void frame_vector_destroy(struct frame_vector *vec);
> -int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
> - unsigned int gup_flags, struct frame_vector *vec);
> -void put_vaddr_frames(struct frame_vector *vec);
> -int frame_vector_to_pages(struct frame_vector *vec);
> -void frame_vector_to_pfns(struct frame_vector *vec);
> -
> -static inline unsigned int frame_vector_count(struct frame_vector *vec)
> -{
> - return vec->nr_frames;
> -}
> -
> -static inline struct page **frame_vector_pages(struct frame_vector *vec)
> -{
> - if (vec->is_pfns) {
> - int err = frame_vector_to_pages(vec);
> -
> - if (err)
> - return ERR_PTR(err);
> - }
>
[PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
vgem is a minimalistic driver that provides shmemfs objects to
userspace that may then be used as an in-memory surface and transported
across dma-buf to other drivers. Since it's introduction,
drm_gem_shmem_helper now provides the same shmemfs facilities and so we
can trim vgem to wrap the helper.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 281 ++--
drivers/gpu/drm/vgem/vgem_drv.h | 11 --
3 files changed, 13 insertions(+), 280 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..db2ff76638cd 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -278,6 +278,7 @@ source "drivers/gpu/drm/i915/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index fa54a6d1403d..73cb17c4f7a8 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(&vgem_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(&obj->pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(&obj->pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int vgem_open(struct drm_device *dev, struct drm_file *file)
{
struct vgem_file *vfile;
@@ -159,41 +84,25 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+static struct drm_gem_shmem_object *__vgem_gem_create(struct drm_device *dev,
unsigned long size)
{
- struct drm_vgem_gem_object *obj;
- int ret;
-
- obj = kzalloc(sizeof(*obj), GFP_KERNEL);
- if (!obj)
- return ERR_PTR(-ENOMEM);
+ struct drm_gem_shmem_object *obj;
- obj->base.funcs = &vgem_gem_object_funcs;
-
- ret = drm_gem_object_init(dev, &obj->base, roundup(size, PAGE_SIZE));
- if (ret) {
- kfree(obj);
- return ERR_PTR(ret);
- }
-
- mutex_init(&obj->pages_lock);
+ obj = d
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, Oct 09, 2020 at 09:24:01AM +, Simon Ser wrote:
> User-space should avoid parsing EDIDs for metadata already exposed via
> other KMS interfaces and properties. For instance, user-space should not
> try to extract a list of modes from the EDID: the kernel might mutate
> the mode list (because of link capabilities or quirks for instance).
>
> Other metadata not exposed by KMS can be parsed by user-space. This
> includes for instance monitor identification (make/model/serial) and
> supported color-spaces.
>
> Signed-off-by: Simon Ser
> Suggested-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Ville Syrj�l�
> ---
> drivers/gpu/drm/drm_connector.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 717c4e7271b0..00e58fd2d292 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list dp_colorspaces[]
> = {
> * drm_connector_update_edid_property(), usually after having parsed
> * the EDID using drm_add_edid_modes(). Userspace cannot change this
> * property.
> + *
> + * User-space should not parse the EDID to obtain information exposed via
> + * other KMS properties. For instance, user-space should not try to parse
> + * mode lists from the EDID.
I assume that this is so that the kernel can apply quirks/limits in
cases where it knows it needs to? I think it would be nice to put at
least a few words indicating "why", otherwise this feels like an
arbitrary commandment with no justification.
Cheers,
-Brian
> * DPMS:
> * Legacy property for setting the power state of the connector. For atomic
> * drivers this is only provided for backwards compatibility with existing
> --
> 2.28.0
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, 9 Oct 2020 11:48:44 +0200
Thomas Zimmermann wrote:
> Hi
>
> Am 09.10.20 um 11:24 schrieb Simon Ser:
> > User-space should avoid parsing EDIDs for metadata already exposed via
> > other KMS interfaces and properties. For instance, user-space should not
> > try to extract a list of modes from the EDID: the kernel might mutate
> > the mode list (because of link capabilities or quirks for instance).
> >
> > Other metadata not exposed by KMS can be parsed by user-space. This
> > includes for instance monitor identification (make/model/serial) and
> > supported color-spaces.
> >
> > Signed-off-by: Simon Ser
> > Suggested-by: Daniel Vetter
> > Cc: Daniel Vetter
Reviewed-by: Pekka Paalanen
> > Cc: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_connector.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 717c4e7271b0..00e58fd2d292 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -960,6 +960,10 @@ static const struct drm_prop_enum_list
> > dp_colorspaces[] = {
> > * drm_connector_update_edid_property(), usually after having
> > parsed
> > * the EDID using drm_add_edid_modes(). Userspace cannot change
> > this
> > * property.
> > + *
> > + * User-space should not parse the EDID to obtain information
> > exposed via
> > + * other KMS properties. For instance, user-space should not try
> > to parse
> > + * mode lists from the EDID.
>
> Acked-by: Thomas Zimmermann
>
> But this makes me wonder why the kernel exposes raw EDID in the first
> place. Wouldn't it be better to expose meaningful fields (display model,
> vendor, etc) instead?
There are many EDID bits of information that the kernel has no use
for. EDID specifications and extensions also continually evolve.
If the kernel set out to expose all information EDID may encode, what
should the UAPI look like? How do you keep the UAPI maintainable and
extendable?
Why should the kernel parse information it has no use for itself at
all? For example: RGB and white-point chromaticities, or maximum HDR
luminance.
That seems quite a lot of continuous work for a benefit I'm not sure I
see when compared to just handing the EDID blob to userspace and let
userspace parse the things the kernel does not expose already.
What we do need is a userspace EDID parsing library. This was discussed
in #dri-devel IRC today as well.
Thanks,
pq
pgpT85gLa3AfY.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
Hi,
Em Fri, 9 Oct 2020 09:59:26 +0200
Daniel Vetter escreveu:
> Way back it was a reasonable assumptions that iomem mappings never
> change the pfn range they point at. But this has changed:
>
> - gpu drivers dynamically manage their memory nowadays, invalidating
> ptes with unmap_mapping_range when buffers get moved
>
> - contiguous dma allocations have moved from dedicated carvetouts to
> cma regions. This means if we miss the unmap the pfn might contain
> pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
>
> - even /dev/mem now invalidates mappings when the kernel requests that
> iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
> ("/dev/mem: Revoke mappings when a driver claims the region")
>
> Accessing pfns obtained from ptes without holding all the locks is
> therefore no longer a good idea.
>
> Unfortunately there's some users where this is not fixable (like v4l
> userptr of iomem mappings) or involves a pile of work (vfio type1
> iommu). For now annotate these as unsafe and splat appropriately.
>
> This patch adds an unsafe_follow_pfn, which later patches will then
> roll out to all appropriate places.
NACK, as this breaks an existing userspace API on media.
While I agree that using the userptr on media is something that
new drivers may not support, as DMABUF is a better way of
handling it, changing this for existing ones is a big no,
as it may break usersapace.
The right approach here would be to be able to fine-tune
support for it on a per-driver basis, e. g. disabling such
feature only for drivers that would use a movable page.
The media subsystem has already a way to disable USERPTR
support from VB2. the right approach would be to ensure
that newer drivers will only set this if they won't use
movable pages.
Regards,
Mauro
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: k...@vger.kernel.org
> ---
> include/linux/mm.h | 2 ++
> mm/memory.c| 32 +++-
> mm/nommu.c | 17 +
> security/Kconfig | 13 +
> 4 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 2a16631c1fda..ec8c90928fc9 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1653,6 +1653,8 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long
> address,
> pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
> int follow_pfn(struct vm_area_struct *vma, unsigned long address,
> unsigned long *pfn);
> +int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
> + unsigned long *pfn);
> int follow_phys(struct vm_area_struct *vma, unsigned long address,
> unsigned int flags, unsigned long *prot, resource_size_t *phys);
> int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index f7cbc4dde0ef..7c7b234ffb24 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4821,7 +4821,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
> * @address: user virtual address
> * @pfn: location to store found PFN
> *
> - * Only IO mappings and raw PFN mappings are allowed.
> + * Only IO mappings and raw PFN mappings are allowed. Note that callers must
> + * ensure coherency with pte updates by using a &mmu_notifier to follow
> updates.
> + * If this is not feasible, or the access to the @pfn is only very short
> term,
> + * use follow_pte_pmd() instead and hold the pagetable lock for the duration
> of
> + * the access instead. Any caller not following these requirements must use
> + * unsafe_follow_pfn() instead.
> *
> * Return: zero and the pfn at @pfn on success, -ve otherwise.
> */
> @@ -4844,6 +4849,31 @@ int follow_pfn(struct vm_area_struct *vma, unsigned
> long address,
> }
> EXPORT_SYMBOL(follow_pfn);
>
> +/**
> + * unsafe_follow_pfn - look up PFN at a user virtual address
> + * @vma: memory mapping
> + * @address: user virtual address
> + * @pfn: location to store found PFN
> + *
> + * Only IO mappings and raw PFN mappings are allowed.
> + *
> + * Returns zero and the pfn at @pfn on success, -ve otherwise.
> + */
> +int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
> + unsigned long *pfn)
> +{
> +#ifdef CONFIG_STRICT_FOLLOW_PFN
> + pr_info("unsafe follow_pfn usage rejected, see
> CONFIG_STRICT_FOLLOW_PFN\n");
> + return -EINVAL;
> +#else
> + WARN_ONCE(1, "unsafe follow_pfn usage\n");
> + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
> +
> + return follow_pfn(vma, address, pfn);
> +#endif
> +}
> +EXPORT_SYMBOL(unsafe_follow_pfn);
> +
> #ifdef CONFIG_HAVE_IOREMAP_PROT
> int follow_phys(str
Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote: > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä > wrote: > > > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote: > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they > > > do nothing for i915. Because i915 doesn't request any regions, like > > > pretty much all drm pci drivers. I guess this is some very old > > > remnants from the userspace modesetting days, when we wanted to > > > co-exist with the fbdev driver. Which usually requested these > > > resources. > > > > > > But makes me wonder why the pci subsystem doesn't just request > > > resource automatically when we map a bar and a pci driver is bound? > > > > > > Knowledge about which pci bars we need kludged together from > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the > > > fake agp driver. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Jason Gunthorpe > > > Cc: Kees Cook > > > Cc: Dan Williams > > > Cc: Andrew Morton > > > Cc: John Hubbard > > > Cc: Jérôme Glisse > > > Cc: Jan Kara > > > Cc: Dan Williams > > > Cc: linux...@kvack.org > > > Cc: linux-arm-ker...@lists.infradead.org > > > Cc: linux-samsung-...@vger.kernel.org > > > Cc: linux-me...@vger.kernel.org > > > Cc: Bjorn Helgaas > > > Cc: linux-...@vger.kernel.org > > > --- > > > drivers/gpu/drm/i915/intel_uncore.c | 25 +++-- > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > > b/drivers/gpu/drm/i915/intel_uncore.c > > > index 54e201fdeba4..ce39049d8919 100644 > > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct intel_uncore > > > *uncore) > > > struct pci_dev *pdev = i915->drm.pdev; > > > int mmio_bar; > > > int mmio_size; > > > + int bar_selection; > > > > Signed bitmasks always make me uneasy. But looks like > > that's what it is in the pci api. So meh. > > Yeah it's surprising. > > > > + int ret; > > > > > > mmio_bar = IS_GEN(i915, 2) ? 1 : 0; > > > + bar_selection = BIT (2) | BIT(mmio_bar); > >^ > > spurious space > > > > That's also not correct for gen2 I think. > > > > gen2: > > 0 = GMADR > > 1 = MMADR > > 2 = IOBAR > > > > gen3: > > 0 = MMADR > > 1 = IOBAR > > 2 = GMADR > > 3 = GTTADR > > > > gen4+: > > 0+1 = GTTMMADR > > 2+3 = GMADR > > 4 = IOBAR > > > > Maybe we should just have an explicit list of bars like that in a > > comment? > > > > I'd also suggest sucking this bitmask calculation into a small helper > > so you can reuse it for the release. > > tbh I just hacked this up for testing. Given how almost no other drm > driver does this, I'm wondering whether we should or not. > > Also the only reason why I didn't just use the pci_request_regions > helper is to avoid the vga ioport range, since that's managed by > vgaarbiter. VGA io range isn't part of any bar. Or do you mean just the io decode enable bit in the pci command register? That should be just a matter or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing to do with which bars we've requested IIRC. > > So I think if we go for this for real we should: > - register the vga ioport range in the vgaarbiter > - have a pci_request_iomem_regions helper that grabs all mem bars > - roll that out to all drm pci drivers > > Or something like that. The other complication is when we resize the > iobar. So not really sure what to do here. We resize it? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/21] drm/aspeed: Set driver CMA functions with DRM_GEM_CMA_DRIVER_OPS
On Fri, 9 Oct 2020 at 08:26, Thomas Zimmermann wrote: > > Hi > > Am 09.10.20 um 10:06 schrieb Joel Stanley: > > On Fri, 9 Oct 2020 at 08:01, Thomas Zimmermann wrote: > >> > >> Hi > >> > >> Am 09.10.20 um 09:54 schrieb Joel Stanley: > >>> On Fri, 22 May 2020 at 13:52, Thomas Zimmermann > >>> wrote: > > DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver > to their defaults. No functional changes are made. > > Signed-off-by: Thomas Zimmermann > >>> > >>> I just found this in my inbox. I assume it has not been applied as you > >>> were after a review. > >> > >> The patchset as a whole got an A-b and was merged a while ago. > > > > I'm a bit confused, I couldn't see it in any tree. The aspeed one > > seemed to have been skipped when applying the series. > > > > I looked at today's linux-next and drm-misc-next. > > Indeed. The other patches are in drm-misc-next, but not this one. I must > have lost it during the merge process. > > > > >>> > >>> Reviewed-by: Joel Stanley > >> > >> Nevertheless thanks for taking a look at the patch. > >> > >> Best regards > >> Thomas > >> > >>> > >>> I will apply it to drm-misc-next. > > So please ahead and apply it. There's also an ack by Emil, which you may > want to add as well. > > Acked-by: Emil Velikov > > Sorry about missing the patch and thanks for taking care. No problem. Thanks for the cleanup. Cheers, Joel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/17] sysfs: Support zapping of binary attr mmaps
On Fri, Oct 09, 2020 at 09:59:32AM +0200, Daniel Vetter wrote:
> We want to be able to revoke pci mmaps so that the same access rules
> applies as for /dev/kmem. Revoke support for devmem was added in
> 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
> region").
>
> The simplest way to achieve this is by having the same filp->f_mapping
> for all mappings, so that unmap_mapping_range can find them all, no
> matter through which file they've been created. Since this must be set
> at open time we need sysfs support for this.
>
> Add an optional mapping parameter bin_attr, which is only consulted
> when there's also an mmap callback, since without mmap support
> allowing to adjust the ->f_mapping makes no sense.
>
> Signed-off-by: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Kees Cook
> Cc: Dan Williams
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: Dan Williams
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Cc: Christian Brauner
> Cc: "David S. Miller"
> Cc: Michael Ellerman
> Cc: Sourabh Jain
> Cc: Daniel Vetter
> Cc: Mauro Carvalho Chehab
> Cc: Nayna Jain
> ---
> fs/sysfs/file.c | 11 +++
> include/linux/sysfs.h | 2 ++
> 2 files changed, 13 insertions(+)
Reviewed-by: Greg Kroah-Hartman
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework
On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote: > We want all iomem mmaps to consistently revoke ptes when the kernel > takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the > pci bar mmaps available through procfs and sysfs, which currently do > not revoke mappings. > > To prepare for this, move the code from the /dev/kmem driver to > kernel/resource.c. > > Signed-off-by: Daniel Vetter > Cc: Jason Gunthorpe > Cc: Kees Cook > Cc: Dan Williams > Cc: Andrew Morton > Cc: John Hubbard > Cc: Jérôme Glisse > Cc: Jan Kara > Cc: Dan Williams > Cc: linux...@kvack.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: Daniel Vetter > Cc: David Hildenbrand > Cc: "Rafael J. Wysocki" Reviewed-by: Greg Kroah-Hartman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
Hi, On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > User-space should avoid parsing EDIDs for metadata already exposed via > other KMS interfaces and properties. For instance, user-space should not > try to extract a list of modes from the EDID: the kernel might mutate > the mode list (because of link capabilities or quirks for instance). > > Other metadata not exposed by KMS can be parsed by user-space. This > includes for instance monitor identification (make/model/serial) and > supported color-spaces. So I take it the only way to get modes is through the connector's list of modes. That sounds reasonable enough to me, but I think to properly handle colour (e.g. CEA modes have different behaviour for limited/full range depending on which VIC they correspond to IIRC) we'd need to take more bits out of drm_mode_modeinfo::flags, which is unfortunate since there aren't that many of them left and it's not an extensible structure. Maybe proper mode handling is going to require an expanded mode structure, but today is not that day, so: Acked-by: Daniel Stone Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] mm: introduce vma_set_file function v2
Am 09.10.20 um 14:12 schrieb Jason Gunthorpe: On Fri, Oct 09, 2020 at 09:39:00AM +0200, Daniel Vetter wrote: I just noticed this here in the patch because everyone else does not do this. But looking at the mmap_region() code in mmap.c we seem to indeed have this problem for the error path: unmap_and_free_vma: vma->vm_file = NULL; fput(file); Note that the success path does things correctly (a bit above): file = vma->vm_file; out: So it indeed looks like dma-buf is the only one that does this fully correctly. So maybe we should do a follow-up patch to change the mmap_region exit code to pick up whatever vma->vm_file was set instead, and fput that? Given that this new vma_set_file() should be the only way to manipulate vm_file from the mmap op, I think this reflects a bug in mm/mmap.c.. Should be: unmap_and_free_vma: fput(vma->vm_file); vma->vm_file = NULL; Then everything works the way you'd expect without tricky error handling That's what Daniel suggested as well, yes. Going to craft a separate patch for this. Thanks, Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
Em Fri, 9 Oct 2020 09:21:11 -0300
Jason Gunthorpe escreveu:
> On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > Hi,
> >
> > Em Fri, 9 Oct 2020 09:59:26 +0200
> > Daniel Vetter escreveu:
> >
> > > Way back it was a reasonable assumptions that iomem mappings never
> > > change the pfn range they point at. But this has changed:
> > >
> > > - gpu drivers dynamically manage their memory nowadays, invalidating
> > > ptes with unmap_mapping_range when buffers get moved
> > >
> > > - contiguous dma allocations have moved from dedicated carvetouts to
> > > cma regions. This means if we miss the unmap the pfn might contain
> > > pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
> > >
> > > - even /dev/mem now invalidates mappings when the kernel requests that
> > > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
> > > ("/dev/mem: Revoke mappings when a driver claims the region")
> > >
> > > Accessing pfns obtained from ptes without holding all the locks is
> > > therefore no longer a good idea.
> > >
> > > Unfortunately there's some users where this is not fixable (like v4l
> > > userptr of iomem mappings) or involves a pile of work (vfio type1
> > > iommu). For now annotate these as unsafe and splat appropriately.
> > >
> > > This patch adds an unsafe_follow_pfn, which later patches will then
> > > roll out to all appropriate places.
> >
> > NACK, as this breaks an existing userspace API on media.
>
> It doesn't break it. You get a big warning the thing is broken and it
> keeps working.
>
> We can't leave such a huge security hole open - it impacts other
> subsystems, distros need to be able to run in a secure mode.
Well, if distros disable it, then apps will break.
> > While I agree that using the userptr on media is something that
> > new drivers may not support, as DMABUF is a better way of
> > handling it, changing this for existing ones is a big no,
> > as it may break usersapace.
>
> media community needs to work to fix this, not pretend it is OK to
> keep going as-is.
> Dealing with security issues is the one case where an uABI break might
> be acceptable.
>
> If you want to NAK it then you need to come up with the work to do
> something here correctly that will support the old drivers without the
> kernel taint.
>
> Unfortunately making things uncomfortable for the subsystem is the big
> hammer the core kernel needs to use to actually get this security work
> done by those responsible.
I'm not pretending that this is ok. Just pointing that the approach
taken is NOT OK.
I'm not a mm/ expert, but, from what I understood from Daniel's patch
description is that this is unsafe *only if* __GFP_MOVABLE is used.
Well, no drivers inside the media subsystem uses such flag, although
they may rely on some infrastructure that could be using it behind
the bars.
If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
flag that it would be denying the core mm code to set __GFP_MOVABLE.
Please let address the issue on this way, instead of broken an
userspace API that it is there since 1991.
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
Em Fri, 9 Oct 2020 14:37:23 +0200
Mauro Carvalho Chehab escreveu:
> Em Fri, 9 Oct 2020 09:21:11 -0300
> Jason Gunthorpe escreveu:
>
> > On Fri, Oct 09, 2020 at 12:34:21PM +0200, Mauro Carvalho Chehab wrote:
> > > Hi,
> > >
> > > Em Fri, 9 Oct 2020 09:59:26 +0200
> > > Daniel Vetter escreveu:
> > >
> > > > Way back it was a reasonable assumptions that iomem mappings never
> > > > change the pfn range they point at. But this has changed:
> > > >
> > > > - gpu drivers dynamically manage their memory nowadays, invalidating
> > > > ptes with unmap_mapping_range when buffers get moved
> > > >
> > > > - contiguous dma allocations have moved from dedicated carvetouts to
> > > > cma regions. This means if we miss the unmap the pfn might contain
> > > > pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
> > > >
> > > > - even /dev/mem now invalidates mappings when the kernel requests that
> > > > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
> > > > ("/dev/mem: Revoke mappings when a driver claims the region")
> > > >
> > > > Accessing pfns obtained from ptes without holding all the locks is
> > > > therefore no longer a good idea.
> > > >
> > > > Unfortunately there's some users where this is not fixable (like v4l
> > > > userptr of iomem mappings) or involves a pile of work (vfio type1
> > > > iommu). For now annotate these as unsafe and splat appropriately.
> > > >
> > > > This patch adds an unsafe_follow_pfn, which later patches will then
> > > > roll out to all appropriate places.
> > >
> > > NACK, as this breaks an existing userspace API on media.
> >
> > It doesn't break it. You get a big warning the thing is broken and it
> > keeps working.
> >
> > We can't leave such a huge security hole open - it impacts other
> > subsystems, distros need to be able to run in a secure mode.
>
> Well, if distros disable it, then apps will break.
>
> > > While I agree that using the userptr on media is something that
> > > new drivers may not support, as DMABUF is a better way of
> > > handling it, changing this for existing ones is a big no,
> > > as it may break usersapace.
> >
> > media community needs to work to fix this, not pretend it is OK to
> > keep going as-is.
>
> > Dealing with security issues is the one case where an uABI break might
> > be acceptable.
> >
> > If you want to NAK it then you need to come up with the work to do
> > something here correctly that will support the old drivers without the
> > kernel taint.
> >
> > Unfortunately making things uncomfortable for the subsystem is the big
> > hammer the core kernel needs to use to actually get this security work
> > done by those responsible.
>
>
> I'm not pretending that this is ok. Just pointing that the approach
> taken is NOT OK.
>
> I'm not a mm/ expert, but, from what I understood from Daniel's patch
> description is that this is unsafe *only if* __GFP_MOVABLE is used.
>
> Well, no drivers inside the media subsystem uses such flag, although
> they may rely on some infrastructure that could be using it behind
> the bars.
>
> If this is the case, the proper fix seems to have a GFP_NOT_MOVABLE
> flag that it would be denying the core mm code to set __GFP_MOVABLE.
>
> Please let address the issue on this way, instead of broken an
> userspace API that it is there since 1991.
In time: I meant to say 1998.
Thanks,
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos/hdmi: add support for 1920x1200@60Hz mode
Add clock configuration for 154MHz pixelclock to Exynos542x HDMIPHY,
which is required for 1920x1200@60Hz mode. The PLL configuration data
has been taken from the vendor's kernel tree for the Odroid XU4 board.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index dc01c188c0e0..39fa5d3b01ef 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -522,6 +522,15 @@ static const struct hdmiphy_config hdmiphy_5420_configs[]
= {
0x54, 0x4B, 0x25, 0x03, 0x00, 0x80, 0x01, 0x80,
},
},
+ {
+ .pixel_clock = 15400,
+ .conf = {
+ 0x01, 0xD1, 0x20, 0x01, 0x40, 0x30, 0x08, 0xCC,
+ 0x8C, 0xE8, 0xC1, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x86,
+ 0x54, 0x3F, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
};
static const struct hdmiphy_config hdmiphy_5433_configs[] = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > Hi, > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > User-space should avoid parsing EDIDs for metadata already exposed via > > other KMS interfaces and properties. For instance, user-space should not > > try to extract a list of modes from the EDID: the kernel might mutate > > the mode list (because of link capabilities or quirks for instance). > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > includes for instance monitor identification (make/model/serial) and > > supported color-spaces. > > So I take it the only way to get modes is through the connector's list > of modes. That sounds reasonable enough to me, but I think to properly > handle colour (e.g. CEA modes have different behaviour for > limited/full range depending on which VIC they correspond to IIRC) If the mode has a VIC and that VIC is not 1, then it's limited range, otherwise full range. There are fortunately no cases where you would have the same exact timings corresponding to different quantization range depending on the VIC. And the only reason the same timings could correspond to multiple VICs is aspect ratio. Which is already exposed via the mode flags, assuming the appropriate client cap is enabled. So I think the only reason to expose the VIC would be if userspace is non-lazy and wants to manage its colors presicely, but is otherwise lazy and doesn't want to figure out what the VIC of the mode is on its own. I guess one related thing we might want to expose is the "is quantization range selectable?" bits from the EDID (assuming we really want the "don't parse the EDID in userspace" policy [1]). That would be needed for userspace to be able to figure out if it can override the VIC based quantization range in the display. Although with a bunch of crappy displays you will want to override it anyway because they just didn't bother with implementing the spec correctly and instead always expect full range data. [1] which probably would mean a huge boatload if properties or some structure inside a blob (which is pretty much just the EDID with a different layout then). > we'd need to take more bits out of drm_mode_modeinfo::flags, which is > unfortunate since there aren't that many of them left and it's not an > extensible structure. Maybe proper mode handling is going to require > an expanded mode structure, but today is not that day, so: > Acked-by: Daniel Stone > > Cheers, > Daniel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add AXBXGXRX106106106106 format
Hi Matteo, +Joe to Cc
On Thu, Oct 08, 2020 at 03:33:50PM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 722c7ebe4e88..03262472059c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -202,6 +202,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
I'm OK with it formatted like this tbh. The YUV formats at the bottom
already mess up the formatting of the table as a whole.
If Joe feels strongly about having it split, I don't think that should
hurt grep-ability much for the common cases (grep for format name, or
grep for format parameters). So either way you can add:
Reviewed-by: Brian Starkey
Thanks!
-Brian
> { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f327801267..9374d9558493 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -155,6 +155,12 @@ extern "C" {
> #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
>
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
> + * of unused padding per component:
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /*
> [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
> On Oct 9, 2020, at 1:31 AM, K, SrinivasX wrote: > > Hi Rodrigo, > > How do we get W/A and rc6 changes in, do you have any details? I told based on what I was seeing on https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html? focusing on the issues that are exclusively for ehl and not happening on other platforms. It looks like workarounds are fine there now. so I'm not sure if it was sporadic thing that day. for the rc6 there are a few testcases failing around it: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-fence.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_pm_rc6_reside...@rc6-idle.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_675/fi-ehl-1/igt@i915_selftest@live@gt_pm.html#dmesg-warnings415 > > Thanks, > Srinivas > > -Original Message- > From: Souza, Jose > Sent: 06 October 2020 23:33 > To: Vivi, Rodrigo ; ch...@chris-wilson.co.uk > Cc: Ausmus, James ; Nikula, Jani > ; Pandey, Hariom ; Roper, > Matthew D ; intel-...@lists.freedesktop.org; > dri-devel@lists.freedesktop.org; K, SrinivasX ; > Surendrakumar Upadhyay, TejaskumarX > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe > protection > > On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote: >> >>> On Oct 6, 2020, at 10:48 AM, Chris Wilson wrote: >>> >>> Quoting Souza, Jose (2020-10-06 18:46:45) +Rodrigo and Jani On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote: > Removing force probe protection from EHL platform. Did not > observe warnings, errors, flickering or any visual defects while > doing ordinary tasks like browsing and editing documents in a > two monitor setup. One of the requirements was also to have CI BAT all green and shards as green is possible but EHL don't show up in CI results, we actually have one single EHL machine in CI but I guess it is not able to run all tests that shards do: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9097/filelist.html >>> >>> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip-alt.html >> >> we are really close to that point. We just need to fix some w/a and >> rc6 issues before applying this change. >> >>> -Chris >> > > Huum okay we have drm-tip results for EHL but if someone sends a patch that > breaks EHL it will not be caught in pre-merge testing. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] amd/amdgpu_ctx: Use struct_size() helper and kmalloc()
On Fri, Oct 09, 2020 at 09:08:51AM +0200, Christian König wrote: > Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva: > > Make use of the new struct_size() helper instead of the offsetof() idiom. > > Also, use kmalloc() instead of kcalloc(). > > > > Signed-off-by: Gustavo A. R. Silva > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c > > index c80d8339f58c..5be125f3b92a 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c > > @@ -100,7 +100,7 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx > > *ctx, u32 hw_ip, > > enum drm_sched_priority priority; > > int r; > > - entity = kcalloc(1, offsetof(typeof(*entity), > > fences[amdgpu_sched_jobs]), > > + entity = kmalloc(struct_size(entity, fences, amdgpu_sched_jobs), > > NAK. You could use kzalloc() here, but kmalloc won't zero initialize the > memory which could result in unforeseen consequences. Oh I see.. I certainly didn't take that into account. I'll fix that up and respin. Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, 9 Oct 2020 16:10:25 +0300 Ville Syrjälä wrote: > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > > Hi, > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > > User-space should avoid parsing EDIDs for metadata already exposed via > > > other KMS interfaces and properties. For instance, user-space should not > > > try to extract a list of modes from the EDID: the kernel might mutate > > > the mode list (because of link capabilities or quirks for instance). > > > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > > includes for instance monitor identification (make/model/serial) and > > > supported color-spaces. > > > > So I take it the only way to get modes is through the connector's list > > of modes. That sounds reasonable enough to me, but I think to properly > > handle colour (e.g. CEA modes have different behaviour for > > limited/full range depending on which VIC they correspond to IIRC) > > If the mode has a VIC and that VIC is not 1, then it's limited range, > otherwise full range. There are fortunately no cases where you would > have the same exact timings corresponding to different quantization > range depending on the VIC. > > And the only reason the same timings could correspond to multiple VICs > is aspect ratio. Which is already exposed via the mode flags, assuming > the appropriate client cap is enabled. > > So I think the only reason to expose the VIC would be if userspace is > non-lazy and wants to manage its colors presicely, but is otherwise lazy > and doesn't want to figure out what the VIC of the mode is on its own. What would "figure out what the VIC of the mode is" require in userspace? A database of all VIC modes and then compare if the detailed timings match? Is that also how the kernel recognises that userspace wants to set a certain VIC mode instead of some arbitrary mode? Can CVT or GVT produce those exact timings? Can that accidentally result in limited range? Sounds like the hypothetical libedid needs a libvic as a friend... and libpixel-format while at it. :-) Thanks, pq pgp4G1NiXGpEw.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] dt-bindings: panel: add documentation for oneplus6 panel
On Wed, 07 Oct 2020 17:49:14 +, Caleb Connolly wrote: > Document the OnePlus 6/T common panel driver, example from > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi > > Signed-off-by: Caleb Connolly > --- > .../display/panel/panel-oneplus6.yaml | 73 +++ > 1 file changed, 73 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-oneplus6.yaml > My bot found errors running 'make dt_binding_check' on your patch: Error: Documentation/devicetree/bindings/display/panel/panel-oneplus6.example.dts:19.9-14 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [scripts/Makefile.lib:342: Documentation/devicetree/bindings/display/panel/panel-oneplus6.example.dt.yaml] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1366: dt_binding_check] Error 2 See https://patchwork.ozlabs.org/patch/1378187 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] dt-bindings: panel: add documentation for oneplus6 panel
On Wed, Oct 07, 2020 at 05:49:14PM +, Caleb Connolly wrote: > Document the OnePlus 6/T common panel driver, example from > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi > > Signed-off-by: Caleb Connolly > --- > .../display/panel/panel-oneplus6.yaml | 73 +++ > 1 file changed, 73 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/panel-oneplus6.yaml > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-oneplus6.yaml > b/Documentation/devicetree/bindings/display/panel/panel-oneplus6.yaml > new file mode 100644 > index ..23ba369cc2f5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/panel-oneplus6.yaml > @@ -0,0 +1,73 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/panel/panel-oneplus6.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: OnePlus 6/T panel driver > + > +description: | > + The OnePlus 6 panel driver encompasses the display panels found in the > + OnePlus 6 and 6T devices, the panels have almost identical behaviour and > + are not used by any other devices. > + > +maintainers: > + - Caleb Connolly > + > +allOf: > + - $ref: panel-common.yaml# > + > +properties: > + compatible: > +enum: > + - samsung,sofef00 > + - samsung,s6e3fc2x01 > + > + reg: true > + reset-gpios: true > + port: true > + > + vddio-supply: > +description: VDDIO regulator A panel with a single supply can use panel-simple-dsi.yaml. 'reset-gpios' was missing, but has been added recently. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 17/17] drm/i915: Properly request PCI BARs
On Fri, Oct 9, 2020 at 12:42 PM Ville Syrjälä wrote: > > On Fri, Oct 09, 2020 at 12:01:39PM +0200, Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 11:47 AM Ville Syrjälä > > wrote: > > > > > > On Fri, Oct 09, 2020 at 09:59:34AM +0200, Daniel Vetter wrote: > > > > When trying to test my CONFIG_IO_STRICT_DEVMEM changes I realized they > > > > do nothing for i915. Because i915 doesn't request any regions, like > > > > pretty much all drm pci drivers. I guess this is some very old > > > > remnants from the userspace modesetting days, when we wanted to > > > > co-exist with the fbdev driver. Which usually requested these > > > > resources. > > > > > > > > But makes me wonder why the pci subsystem doesn't just request > > > > resource automatically when we map a bar and a pci driver is bound? > > > > > > > > Knowledge about which pci bars we need kludged together from > > > > intel_uncore.c and intel_gtt.c from i915 and intel-gtt.c over in the > > > > fake agp driver. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: Jason Gunthorpe > > > > Cc: Kees Cook > > > > Cc: Dan Williams > > > > Cc: Andrew Morton > > > > Cc: John Hubbard > > > > Cc: Jérôme Glisse > > > > Cc: Jan Kara > > > > Cc: Dan Williams > > > > Cc: linux...@kvack.org > > > > Cc: linux-arm-ker...@lists.infradead.org > > > > Cc: linux-samsung-...@vger.kernel.org > > > > Cc: linux-me...@vger.kernel.org > > > > Cc: Bjorn Helgaas > > > > Cc: linux-...@vger.kernel.org > > > > --- > > > > drivers/gpu/drm/i915/intel_uncore.c | 25 +++-- > > > > 1 file changed, 23 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > > > > b/drivers/gpu/drm/i915/intel_uncore.c > > > > index 54e201fdeba4..ce39049d8919 100644 > > > > --- a/drivers/gpu/drm/i915/intel_uncore.c > > > > +++ b/drivers/gpu/drm/i915/intel_uncore.c > > > > @@ -1692,10 +1692,13 @@ static int uncore_mmio_setup(struct > > > > intel_uncore *uncore) > > > > struct pci_dev *pdev = i915->drm.pdev; > > > > int mmio_bar; > > > > int mmio_size; > > > > + int bar_selection; > > > > > > Signed bitmasks always make me uneasy. But looks like > > > that's what it is in the pci api. So meh. > > > > Yeah it's surprising. > > > > > > + int ret; > > > > > > > > mmio_bar = IS_GEN(i915, 2) ? 1 : 0; > > > > + bar_selection = BIT (2) | BIT(mmio_bar); > > >^ > > > spurious space > > > > > > That's also not correct for gen2 I think. > > > > > > gen2: > > > 0 = GMADR > > > 1 = MMADR > > > 2 = IOBAR > > > > > > gen3: > > > 0 = MMADR > > > 1 = IOBAR > > > 2 = GMADR > > > 3 = GTTADR > > > > > > gen4+: > > > 0+1 = GTTMMADR > > > 2+3 = GMADR > > > 4 = IOBAR > > > > > > Maybe we should just have an explicit list of bars like that in a > > > comment? > > > > > > I'd also suggest sucking this bitmask calculation into a small helper > > > so you can reuse it for the release. > > > > tbh I just hacked this up for testing. Given how almost no other drm > > driver does this, I'm wondering whether we should or not. > > > > Also the only reason why I didn't just use the pci_request_regions > > helper is to avoid the vga ioport range, since that's managed by > > vgaarbiter. > > VGA io range isn't part of any bar. Or do you mean just the io decode > enable bit in the pci command register? That should be just a matter > or pci_enable_device() vs. pci_enable_device_mem() I think. So nothing > to do with which bars we've requested IIRC. > > > > > So I think if we go for this for real we should: > > - register the vga ioport range in the vgaarbiter > > - have a pci_request_iomem_regions helper that grabs all mem bars > > - roll that out to all drm pci drivers > > > > Or something like that. The other complication is when we resize the > > iobar. So not really sure what to do here. > > We resize it? By default I thought firmware puts everything (well, squeezes) into the lower 32bit. Maybe they stopped doing that. So when we want the full bar (for discrete at least) we need to resize it and put it somewhere in the 64bit range above end of system memory. So I guess correct phrasing is "we will resize it" :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote: > On Fri, 9 Oct 2020 16:10:25 +0300 > Ville Syrjälä wrote: > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > > > Hi, > > > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > > > User-space should avoid parsing EDIDs for metadata already exposed via > > > > other KMS interfaces and properties. For instance, user-space should not > > > > try to extract a list of modes from the EDID: the kernel might mutate > > > > the mode list (because of link capabilities or quirks for instance). > > > > > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > > > includes for instance monitor identification (make/model/serial) and > > > > supported color-spaces. > > > > > > So I take it the only way to get modes is through the connector's list > > > of modes. That sounds reasonable enough to me, but I think to properly > > > handle colour (e.g. CEA modes have different behaviour for > > > limited/full range depending on which VIC they correspond to IIRC) > > > > If the mode has a VIC and that VIC is not 1, then it's limited range, > > otherwise full range. There are fortunately no cases where you would > > have the same exact timings corresponding to different quantization > > range depending on the VIC. > > > > And the only reason the same timings could correspond to multiple VICs > > is aspect ratio. Which is already exposed via the mode flags, assuming > > the appropriate client cap is enabled. > > > > So I think the only reason to expose the VIC would be if userspace is > > non-lazy and wants to manage its colors presicely, but is otherwise lazy > > and doesn't want to figure out what the VIC of the mode is on its own. > > What would "figure out what the VIC of the mode is" require in userspace? > > A database of all VIC modes and then compare if the detailed timings match? > > Is that also how the kernel recognises that userspace wants to set a > certain VIC mode instead of some arbitrary mode? Yes and yes. Note that atm we also don't have a way for userspace to say that it wants to signal limited range to the sink but wants the kernel to not do the full->limited range conversion. Ie. no way for userspace to pass in pixels that are already in limited range. There was a patch for that posted quite long ago, but it didn't go in. > > Can CVT or GVT produce those exact timings? Can that accidentally > result in limited range? Not sure. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework
On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote:
>
> On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote:
>
> > +struct address_space *iomem_get_mapping(void)
> > +{
> > + return iomem_inode->i_mapping;
>
> This should pair an acquire with the release below
>
> > + /*
> > + * Publish /dev/mem initialized.
> > + * Pairs with smp_load_acquire() in revoke_iomem().
> > + */
> > + smp_store_release(&iomem_inode, inode);
>
> However, this seems abnormal, initcalls rarely do this kind of stuff
> with global data..
>
> The kernel crashes if this fs_initcall is raced with
> iomem_get_mapping() due to the unconditional dereference, so I think
> it can be safely switched to a simple assignment.
Ah yes I checked this all, but forgot to correctly annotate the
iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem:
Add missing memory barriers for devmem_inode").
The reasons for the annotations is that iomem requests can happen
fairly early, way before fs_initcalls happen. That means revoke_iomem
needs to check for that and bail out if we race - nothing bad can
happen since userspace isn't running at this point anyway. And
apparently it needs to be a full acquire fence since we don't just
write a value, but need a barrier for the struct stuff.
Now iomem_get_mapping otoh can only be called after userspace is up &
running, so way after all the fs_initcalls are guaranteed to have
fininshed. Hence we don't really need anything there. But I expect the
kernel race checker thing to complain, plus that then gives me a good
spot to explain why we can't race and don't have to check for a NULL
iomem_inode.
I'll add that in v3.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] amd/amdgpu_ctx: Use struct_size() helper and kmalloc()
Am 09.10.20 um 15:54 schrieb Gustavo A. R. Silva: On Fri, Oct 09, 2020 at 09:08:51AM +0200, Christian König wrote: Am 08.10.20 um 16:34 schrieb Gustavo A. R. Silva: Make use of the new struct_size() helper instead of the offsetof() idiom. Also, use kmalloc() instead of kcalloc(). Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c index c80d8339f58c..5be125f3b92a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c @@ -100,7 +100,7 @@ static int amdgpu_ctx_init_entity(struct amdgpu_ctx *ctx, u32 hw_ip, enum drm_sched_priority priority; int r; - entity = kcalloc(1, offsetof(typeof(*entity), fences[amdgpu_sched_jobs]), + entity = kmalloc(struct_size(entity, fences, amdgpu_sched_jobs), NAK. You could use kzalloc() here, but kmalloc won't zero initialize the memory which could result in unforeseen consequences. Oh I see.. I certainly didn't take that into account. I'll fix that up and respin. Shit happens, we already have a fix for this. Alex merged it and it immediately broke our testing systems. So one of our engineers came up with a fix which should already have been applied. Christian. Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] amd/amdgpu_ctx: Use struct_size() helper and kmalloc()
On Fri, Oct 09, 2020 at 04:29:55PM +0200, Christian König wrote: > > > > - entity = kcalloc(1, offsetof(typeof(*entity), > > > > fences[amdgpu_sched_jobs]), > > > > + entity = kmalloc(struct_size(entity, fences, amdgpu_sched_jobs), > > > NAK. You could use kzalloc() here, but kmalloc won't zero initialize the > > > memory which could result in unforeseen consequences. > > Oh I see.. I certainly didn't take that into account. > > > > I'll fix that up and respin. > > Shit happens, we already have a fix for this. Alex merged it and it > immediately broke our testing systems. :/ > So one of our engineers came up with a fix which should already have been > applied. Great. Good to know it's already fixed! :) Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
> -Original Message-
> From: Neil Armstrong
> Sent: Friday, October 9, 2020 2:10 AM
> To: Chrisanthus, Anitha ; dri-
> de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel
>
> Cc: Dea, Edmund J ; s...@ravnborg.org
> Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel
> KeemBay Display
>
> Hi,
>
> On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> >
> > Signed-off-by: Anitha Chrisanthus
> > ---
> > .../bindings/display/intel,keembay-display.yaml| 99
> ++
> > 1 file changed, 99 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml
> > new file mode 100644
> > index 000..a38493d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml
> > @@ -0,0 +1,99 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/intel,keembay-
> display.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Devicetree bindings for Intel Keem Bay display controller
> > +
> > +maintainers:
> > + - Anitha Chrisanthus
> > + - Edmond J Dea
> > +
> > +properties:
> > + compatible:
> > +const: intel,kmb_display
> > +
> > + reg:
> > +items:
> > + - description: Lcd registers range
> > + - description: Mipi registers range
>
> Looking at the registers, the MIPI transceiver seems to be a separate IP,
> same for D-PHY which should have a proper PHY driver instead of beeing
> handled
> here.
Mipi is not a separate IP, it is all part of one sub system in the Intel
Movidius Soc.
>
> > + - description: Msscam registers range
>
> MSScam here seems to be a clock and reset controller for the LCD and MIPI
> IPs,
> thus should be handler out of DRM.
>
> > +
> > + reg-names:
> > +items:
> > + - const: lcd
> > + - const: mipi
> > + - const: msscam
> > +
> > + clocks:
> > +items:
> > + - description: LCD controller clock
> > + - description: Mipi DSI clock
> > + - description: Mipi DSI econfig clock
> > + - description: Mipi DSI config clock
> > + - description: System clock or pll0 clock
> > +
> > + clock-names:
> > +items:
> > + - const: clk_lcd
> > + - const: clk_mipi
> > + - const: clk_mipi_ecfg
> > + - const: clk_mipi_cfg
> > + - const: clk_pll0
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + encoder-slave:
> > +description: bridge node entry for mipi to hdmi converter
> > +
> > + port:
> > +type: object
> > +description: >
> > + Port node with one endpoint connected to mipi to hdmi converter
> node.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - clock-names
> > + - interrupts
> > + - encoder-slave
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#define MOVISOC_KMB_MSS_AUX_LCD
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_TX0
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_ECFG
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_CFG
> > +#define MOVISOC_KMB_A53_PLL_0_OUT_0
> > +display@2090 {
> > + compatible = "intel,keembay-display";
> > + reg = <0x2093 0x3000>,
> > +<0x2090 0x4000>,
> > +<0x2091 0x30>;
> > + reg-names = "lcd", "mipi", "msscam";
> > + interrupts = ;
> > + clocks = <&scmi_clk MOVISOC_KMB_MSS_AUX_LCD>,
> > + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_TX0>,
> > + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_ECFG>,
> > + <&scmi_clk MOVISOC_KMB_MSS_AUX_MIPI_CFG>,
> > + <&scmi_clk MOVISOC_KMB_A53_PLL_0_OUT_0>;
> > + clock-names = "clk_lcd", "clk_mipi", "clk_mipi_ecfg",
> > +"clk_mipi_cfg", "clk_pll0";
> > +
> > + encoder-slave = <&adv7535>;
> > +
> > + port {
> > +dsi_output: endpoint {
> > +remote-endpoint = <&adv7535_input>;
> > +};
> > + };
> > +};
> >
>
> Anitha, Daniel, this keembay driver should be architectured like other ARM-
> like display
> controllers, with separate drivers for MIPI DSI bridge and msscam clock &
> reset controller.
> Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ALSA: hda/i915 - fix list corruption with concurrent probes
On Tue, 06 Oct 2020 18:17:22 +0200,
Kai Vehmanen wrote:
>
> From: Takashi Iwai
>
> Current hdac_i915 uses a static completion instance to wait
> for i915 driver to complete the component bind.
>
> This design is not safe if multiple HDA controllers are active and
> communicating with different i915 instances, and can lead to list
> corruption and failed audio driver probe.
>
> Fix the design by moving completion mechanism to common acomp
> code and remove the related code from hdac_i915.
>
> Co-developed-by: Kai Vehmanen
> Signed-off-by: Kai Vehmanen
> Signed-off-by: Takashi Iwai
Now I applied it with Fixes tag to 7b882fe3e3e8 ("ALSA: hda - handle
multiple i915 device instances").
thanks,
Takashi
> ---
> include/drm/drm_audio_component.h | 4
> sound/hda/hdac_component.c| 3 +++
> sound/hda/hdac_i915.c | 23 +++
> 3 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/include/drm/drm_audio_component.h
> b/include/drm/drm_audio_component.h
> index a45f93487039..0d36bfd1a4cd 100644
> --- a/include/drm/drm_audio_component.h
> +++ b/include/drm/drm_audio_component.h
> @@ -117,6 +117,10 @@ struct drm_audio_component {
>* @audio_ops: Ops implemented by hda driver, called by DRM driver
>*/
> const struct drm_audio_component_audio_ops *audio_ops;
> + /**
> + * @master_bind_complete: completion held during component master
> binding
> + */
> + struct completion master_bind_complete;
> };
>
> #endif /* _DRM_AUDIO_COMPONENT_H_ */
> diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c
> index 89126c6fd216..bb37e7e0bd79 100644
> --- a/sound/hda/hdac_component.c
> +++ b/sound/hda/hdac_component.c
> @@ -210,12 +210,14 @@ static int hdac_component_master_bind(struct device
> *dev)
> goto module_put;
> }
>
> + complete_all(&acomp->master_bind_complete);
> return 0;
>
> module_put:
> module_put(acomp->ops->owner);
> out_unbind:
> component_unbind_all(dev, acomp);
> + complete_all(&acomp->master_bind_complete);
>
> return ret;
> }
> @@ -296,6 +298,7 @@ int snd_hdac_acomp_init(struct hdac_bus *bus,
> if (!acomp)
> return -ENOMEM;
> acomp->audio_ops = aops;
> + init_completion(&acomp->master_bind_complete);
> bus->audio_component = acomp;
> devres_add(dev, acomp);
>
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index 5f0a1aa6ad84..454474ac5716 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -11,8 +11,6 @@
> #include
> #include
>
> -static struct completion bind_complete;
> -
> #define IS_HSW_CONTROLLER(pci) (((pci)->device == 0x0a0c) || \
> ((pci)->device == 0x0c0c) || \
> ((pci)->device == 0x0d0c) || \
> @@ -130,19 +128,6 @@ static bool i915_gfx_present(void)
> return pci_dev_present(ids);
> }
>
> -static int i915_master_bind(struct device *dev,
> - struct drm_audio_component *acomp)
> -{
> - complete_all(&bind_complete);
> - /* clear audio_ops here as it was needed only for completion call */
> - acomp->audio_ops = NULL;
> - return 0;
> -}
> -
> -static const struct drm_audio_component_audio_ops i915_init_ops = {
> - .master_bind = i915_master_bind
> -};
> -
> /**
> * snd_hdac_i915_init - Initialize i915 audio component
> * @bus: HDA core bus
> @@ -163,9 +148,7 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> if (!i915_gfx_present())
> return -ENODEV;
>
> - init_completion(&bind_complete);
> -
> - err = snd_hdac_acomp_init(bus, &i915_init_ops,
> + err = snd_hdac_acomp_init(bus, NULL,
> i915_component_master_match,
> sizeof(struct i915_audio_component) -
> sizeof(*acomp));
> if (err < 0)
> @@ -177,8 +160,8 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> if (!IS_ENABLED(CONFIG_MODULES) ||
> !request_module("i915")) {
> /* 60s timeout */
> - wait_for_completion_timeout(&bind_complete,
> -msecs_to_jiffies(60 * 1000));
> +
> wait_for_completion_timeout(&acomp->master_bind_complete,
> + msecs_to_jiffies(60 *
> 1000));
> }
> }
> if (!acomp->ops) {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/amdgpu: stop using pages with drm_prime_sg_to_page_addr_arrays
This is deprecated. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 399961035ae6..ac463e706b19 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -1011,8 +1011,8 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_bo_device *bdev, goto release_sg; /* convert SG to linear array of pages and dma addresses */ - drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, -gtt->ttm.dma_address, ttm->num_pages); + drm_prime_sg_to_page_addr_arrays(ttm->sg, NULL, gtt->ttm.dma_address, +ttm->num_pages); return 0; @@ -1345,7 +1345,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_bo_device *bdev, ttm->sg = sgt; } - drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, + drm_prime_sg_to_page_addr_arrays(ttm->sg, NULL, gtt->ttm.dma_address, ttm->num_pages); ttm_tt_set_populated(ttm); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
