Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
Hi Ingo,
On Wed, Mar 25, 2020 at 1:59 PM Ingo Molnar wrote:
>
>
> * Masahiro Yamada wrote:
>
> > This series of cleanups was prompted by Linus:
> > https://lkml.org/lkml/2020/3/12/726
> >
> > First, this series drop always-on CONFIG_AS_* options.
> > Some of those options were introduced in old days.
> > For example, the check for CONFIG_AS_CFI dates back to 2006.
> >
> > We raise the minimal tool versions from time to time.
> > Currently, we require binutils 2.21
> > (and we plan to bump it to 2.23 for v5.7-rc1).
> >
> > After cleaning away the old checks,
> > as-instr calls are moved to Kconfig from Makefiles.
> > (patch 11)
> >
> > This allows more Kconfig / Makefile cleanups.
> > Patch 12 is complex, but I double-checked it does the equivalent.
> >
> > Patch 14 bumps the binutils version to 2.23,
> > and patch 15 removes more CONFIG_AS_* options.
> >
> > I folded all relevanet patches into this series,
> > as suggested by Jason A. Donenfeld.
> >
> > If x86 maintainers take care of this series, that's good.
> >
> > If it is OK to queue this up to Kbuild tree,
> > I will send a pull request to Linus.
> >
> > Thank you.
>
> LGTM. I've got these four from Jason A. Donenfeld queued up in
> tip:WIP.x86/asm:
>
> bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on
> assembler")
> 829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
> 95ef9f80ed63: ("x86/build: Probe assembler from Kconfig instead of Kbuild")
> 1651e700664b: ("x86: Fix bitops.h warning with a moved cast")
>
> I suppose these might interact (maybe even conflict), and are topically
> related.
>
> Would you like to pull these into the kbuild tree? You can find them in:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/asm
>
> Thanks,
>
> Ingo
I did not know that these had already landed in tip tree.
They are immature version.
(In fact CONFIG_AS_CFI and AS_ADX are false-negative
if GCC that defaults to 32-bit is used.)
Can you simply discard the WIP.x86/asm branch,
and only reapply
1651e700664b: ("x86: Fix bitops.h warning with a moved cast")
?
--
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
* Masahiro Yamada wrote:
> This series of cleanups was prompted by Linus:
> https://lkml.org/lkml/2020/3/12/726
>
> First, this series drop always-on CONFIG_AS_* options.
> Some of those options were introduced in old days.
> For example, the check for CONFIG_AS_CFI dates back to 2006.
>
> We raise the minimal tool versions from time to time.
> Currently, we require binutils 2.21
> (and we plan to bump it to 2.23 for v5.7-rc1).
>
> After cleaning away the old checks,
> as-instr calls are moved to Kconfig from Makefiles.
> (patch 11)
>
> This allows more Kconfig / Makefile cleanups.
> Patch 12 is complex, but I double-checked it does the equivalent.
>
> Patch 14 bumps the binutils version to 2.23,
> and patch 15 removes more CONFIG_AS_* options.
>
> I folded all relevanet patches into this series,
> as suggested by Jason A. Donenfeld.
>
> If x86 maintainers take care of this series, that's good.
>
> If it is OK to queue this up to Kbuild tree,
> I will send a pull request to Linus.
>
> Thank you.
LGTM. I've got these four from Jason A. Donenfeld queued up in
tip:WIP.x86/asm:
bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on
assembler")
829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
95ef9f80ed63: ("x86/build: Probe assembler from Kconfig instead of Kbuild")
1651e700664b: ("x86: Fix bitops.h warning with a moved cast")
I suppose these might interact (maybe even conflict), and are topically
related.
Would you like to pull these into the kbuild tree? You can find them in:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/asm
Thanks,
Ingo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 27/89] clk: bcm: Add BCM2711 DVP driver
Quoting Maxime Ripard (2020-03-23 03:56:16) > Hi Stephen, > > On Thu, Mar 12, 2020 at 06:00:59PM -0700, Stephen Boyd wrote: > > > + dvp->clks[1] = clk_register_gate(>dev, "hdmi1-108MHz", > > > +parent, CLK_IS_CRITICAL, > > > +base + DVP_HT_RPI_MISC_CONFIG, 4, > > > +CLK_GATE_SET_TO_DISABLE, > > > >reset.lock); > > > > Can we use clk_hw APIs, document why CLK_IS_CRITICAL, and use something > > like clk_hw_register_gate_parent_data() so that we don't have to use > > of_clk_get_parent_name() above? > > That function is new to me, and I'm not sure how I'm supposed to use it? > > It looks like clk_hw_register_gate, clk_hw_register_gate_parent_hw and > clk_hw_register_gate_parent_data all call __clk_hw_register_gate with > the same arguments, each expecting the parent_name, so they look > equivalent? > > It looks like the original intent was to have the parent name, clk_hw > or clk_parent_data as argument, but the macro itself was copy pasted > without changing the arguments it's calling __clk_hw_register_gate > with? > Yeah! It looks like nobody has tried to use it yet so you've come across that problem where nobody reviews things and I just merge it anyway. I'll send a fix shortly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/i915/dp: Attach and set drm connector VRR property
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..95db4e783893 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5843,6 +5843,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+static bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = >display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -5853,6 +5870,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
int ret = intel_connector_update_modes(connector, edid);
if (ret)
return ret;
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
}
/* if eDP has no EDID, fall back to fixed mode */
@@ -6880,6 +6901,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing paramaters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Signed-off-by: Manasi Navare
Reviewed-by: Harry Wentland
---
include/drm/drm_dp_helper.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9d87cdf2740a..36655f3c83f8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1315,6 +1315,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
}
+/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
+static inline bool
+drm_dp_sink_can_do_video_without_timing_msa(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+ DP_MSA_TIMING_PAR_IGNORED;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/radeon: remove unneeded header include path
On Wed, Mar 25, 2020 at 4:42 AM Alex Deucher wrote: > > On Tue, Mar 24, 2020 at 12:48 PM Masahiro Yamada wrote: > > > > Hi, > > > > I think this series is a good clean-up. > > > > Could you take a look at this please? > > Can you resend? I don't seem to have gotten it. Must have ended up > getting flagged a spam or something. Can you take it from patchwork ? (4 patches) https://lore.kernel.org/patchwork/project/lkml/list/?series=429491 Thanks. > Alex > > > > > > > > > On Fri, Feb 14, 2020 at 12:40 AM Masahiro Yamada > > wrote: > > > > > > A header include path without $(srctree)/ is suspicious because it does > > > not work with O= builds. > > > > > > You can build drivers/gpu/drm/radeon/ without this include path. > > > > > > Signed-off-by: Masahiro Yamada > > > --- > > > > > > drivers/gpu/drm/radeon/Makefile | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/radeon/Makefile > > > b/drivers/gpu/drm/radeon/Makefile > > > index c693b2ca0329..9d5d3dc1011f 100644 > > > --- a/drivers/gpu/drm/radeon/Makefile > > > +++ b/drivers/gpu/drm/radeon/Makefile > > > @@ -3,8 +3,6 @@ > > > # Makefile for the drm device driver. This driver provides support for > > > the > > > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > > > > > -ccflags-y := -Idrivers/gpu/drm/amd/include > > > - > > > hostprogs := mkregtable > > > clean-files := rn50_reg_safe.h r100_reg_safe.h r200_reg_safe.h > > > rv515_reg_safe.h r300_reg_safe.h r420_reg_safe.h rs600_reg_safe.h > > > r600_reg_safe.h evergreen_reg_safe.h cayman_reg_safe.h > > > > > > -- > > > 2.17.1 > > > > > > > > > -- > > Best Regards > > Masahiro Yamada > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: delete notify in virtio_gpu_object_create
For 3D buffers, virtio_gpu_gem_object_open notifies.
We can have the same behavior for dumb buffer. We just
need to make sure the first open notifies the host for
dumb buffers.
v2: virtio_gpu_gem_object_open always notifies
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 1 +
drivers/gpu/drm/virtio/virtgpu_gem.c| 10 --
drivers/gpu/drm/virtio/virtgpu_object.c | 1 -
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 79ad176aca5a8..842200e01d785 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -71,6 +71,7 @@ struct virtio_gpu_object {
uint32_t hw_res_handle;
bool dumb;
bool created;
+ bool notified;
};
#define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, base.base)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 90c0a8ea1708c..597ddb7391fb9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -111,10 +111,13 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
{
struct virtio_gpu_device *vgdev = obj->dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
+ struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
struct virtio_gpu_object_array *objs;
- if (!vgdev->has_virgl_3d)
- return 0;
+ if (!vgdev->has_virgl_3d && !bo->notified)
+ goto out_notify;
+ else if (!vgdev->has_virgl_3d)
+ goto out;
objs = virtio_gpu_array_alloc(1);
if (!objs)
@@ -123,7 +126,10 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
virtio_gpu_cmd_context_attach_resource(vgdev, vfpriv->ctx_id,
objs);
+out_notify:
+ bo->notified = true;
virtio_gpu_notify(vgdev);
+out:
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d9039bb7c5e37..51a8da7d5ef3b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
return ret;
}
- virtio_gpu_notify(vgdev);
*bo_ptr = bo;
return 0;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/prime: use length macro when mapping sgl
As dma_map_sg can reorganize scatter-gather lists in a
way that can cause some later segments to be empty we should
always use the sg_dma_len macro to fetch the actual length.
This could now be 0 and not need to be mapped to a page or
address array
Signed-off-by: Shane Francis
---
drivers/gpu/drm/drm_prime.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..e4eff5b84597 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -965,12 +965,14 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table
*sgt, struct page **pages,
u32 len, index;
dma_addr_t addr;
+
index = 0;
for_each_sg(sgt->sgl, sg, sgt->nents, count) {
- len = sg->length;
+ len = sg_dma_len(sg);
page = sg_page(sg);
addr = sg_dma_address(sg);
+
while (len > 0) {
if (WARN_ON(index >= max_entries))
return -1;
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] AMDGPU / RADEON / DRM Fix mapping of user pages
This patch set is to fix a bug in amdgpu / radeon drm that results in a crash when dma_map_sg combines elemnets within a scatterlist table. There are 2 shortfalls in the current kernel. 1) AMDGPU / RADEON assumes that the requested and created scatterlist table lengths using from dma_map_sg are equal. This may not be the case using the newer dma-iommu implementation 2) drm_prime does not fetch the length of the scatterlist via the correct dma macro, this can use the incorrect length being used (>0) in places where dma_map_sg has updated the table elements. The sg_dma_len macro is representative of the length of the sg item after dma_map_sg Example Crash : > [drm:amdgpu_ttm_backend_bind [amdgpu]] *ERROR* failed to pin userptr This happens in OpenCL applications, causing them to crash or hang, on either amdgpu-pro or ROCm OpenCL implementations Shane Francis (3): drm/prime: use dma length macro when mapping sg to arrays drm/amdgpu: fix scatter-gather mapping with user pages drm/radeon: fix scatter-gather mapping with user pages drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/drm_prime.c | 4 +++- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/radeon: fix scatter-gather mapping with user pages
Calls to dma_map_sg may return segments / entries than requested if they fall on page bounderies. The old implementation did not support this use case. Signed-off-by: Shane Francis --- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 3b92311d30b9..b3380ffab4c2 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -528,7 +528,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) r = -ENOMEM; nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction); - if (nents != ttm->sg->nents) + if (nents == 0) goto release_sg; drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/amdgpu: fix scatter-gather mapping with user pages
Calls to dma_map_sg may return segments / entries than requested if they fall on page bounderies. The old implementation did not support this use case. Signed-off-by: Shane Francis --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index dee446278417..c6e9885c071f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -974,7 +974,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) /* Map SG to device */ r = -ENOMEM; nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction); - if (nents != ttm->sg->nents) + if (nents == 0) goto release_sg; /* convert SG to linear array of pages and dma addresses */ -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/virtio: delete notify in virtio_gpu_object_create
On Wed, Mar 25, 2020 at 12:44 AM Gurchetan Singh wrote: > > - For dumb buffers, virtio_gpu_gem_create can notify. > - For 3D buffers, virtio_gpu_gem_object_open can notify. Hmm, I feel this is a bit complex. virtio_gpu_gem_object_open may not notify, and the caller needs to know about it. Can we change it to virtio_gpu_object_create never notifies and virtio_gpu_gem_object_open always notifies? > > Signed-off-by: Gurchetan Singh > --- > drivers/gpu/drm/virtio/virtgpu_gem.c| 1 + > drivers/gpu/drm/virtio/virtgpu_object.c | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c > b/drivers/gpu/drm/virtio/virtgpu_gem.c > index 90c0a8ea1708..aa14dd12928e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_gem.c > +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c > @@ -49,6 +49,7 @@ static int virtio_gpu_gem_create(struct drm_file *file, > return ret; > } > > + virtio_gpu_notify(vgdev); > *obj_p = >base.base; > > /* drop reference from allocate - handle holds it now */ > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c > b/drivers/gpu/drm/virtio/virtgpu_object.c > index d9039bb7c5e3..51a8da7d5ef3 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_object.c > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c > @@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device > *vgdev, > return ret; > } > > - virtio_gpu_notify(vgdev); > *bo_ptr = bo; > return 0; > > -- > 2.25.1.696.g5e7596f4ac-goog > > ___ > 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 v3 0/7] drm/meson: add support for Amlogic Video FBC
Neil Armstrong writes: > Amlogic uses a proprietary lossless image compression protocol and format > for their hardware video codec accelerators, either video decoders or > video input encoders. > > It considerably reduces memory bandwidth while writing and reading > frames in memory. > > The underlying storage is considered to be 3 components, 8bit or 10-bit > per component, YCbCr 420, single plane : > - DRM_FORMAT_YUV420_8BIT > - DRM_FORMAT_YUV420_10BIT > > This modifier will be notably added to DMA-BUF frames imported from the V4L2 > Amlogic VDEC decoder. > > At least two layout are supported : > - Basic: composed of a body and a header > - Scatter: the buffer is filled with a IOMMU scatter table referring > to the encoder current memory layout. This mode if more efficient in terms > of memory allocation but frames are not dumpable and only valid during until > the buffer is freed and back in control of the encoder > > At least two options are supported : > - Memory saving: when the pixel bpp is 8b, the size of the superblock can > be reduced, thus saving memory. > > This serie adds the missing register, updated the FBC decoder registers > content to be committed by the crtc code. > > The Amlogic FBC has been tested with compressed content from the Amlogic > HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit > (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit > (Scatter on G12A/SM1, default on GXL). Tested on meson-sm1-sei610 (VP9 60fps content). Tested-by: Kevin Hilman Kevin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: manage drm_minor cleanup with drmm_
On Tue, Mar 24, 2020 at 09:39:36PM +0100, Daniel Vetter wrote:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
>
> The kdev for the minor already handles NULL, so no problem there.
>
> Hence add drmm_remove_action() to the drm_managed library.
>
> v2: Make pointer math around void ** consistent with what Laurent
> suggested.
>
> v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> because of some questions from Thomas. This also means we need to move
> the drmm_add_action_or_reset helper earlier in the series.
>
> v4: Uh ... fix slightly embarrassing bug CI spotted.
Looks like the one I spotted in my review.
Saw your mail only after posting.
One Q below.
>
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 69 ---
> drivers/gpu/drm/drm_managed.c | 14 +++
> include/drm/drm_managed.h | 9 -
> 3 files changed, 46 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a710c53d13a8..50c56ff24c71 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> }
> }
>
> +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> +{
> + struct drm_minor *minor = data;
> + unsigned long flags;
> +
> + put_device(minor->kdev);
> +
> + spin_lock_irqsave(_minor_lock, flags);
> + idr_remove(_minors_idr, minor->index);
> + spin_unlock_irqrestore(_minor_lock, flags);
> +}
> +
> static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> {
> struct drm_minor *minor;
> unsigned long flags;
> int r;
>
> - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> if (!minor)
> return -ENOMEM;
>
> @@ -117,46 +129,20 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> idr_preload_end();
>
> if (r < 0)
> - goto err_free;
> + return r;
>
> minor->index = r;
>
> + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> + if (r)
> + return r;
> +
> minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev)) {
> - r = PTR_ERR(minor->kdev);
> - goto err_index;
> - }
> + if (IS_ERR(minor->kdev))
> + return PTR_ERR(minor->kdev);
>
> *drm_minor_get_slot(dev, type) = minor;
> return 0;
> -
> -err_index:
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -err_free:
> - kfree(minor);
> - return r;
> -}
> -
> -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> -{
> - struct drm_minor **slot, *minor;
> - unsigned long flags;
> -
> - slot = drm_minor_get_slot(dev, type);
> - minor = *slot;
> - if (!minor)
> - return;
> -
> - put_device(minor->kdev);
> -
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -
> - kfree(minor);
> - *slot = NULL;
In drm_minor_alloc_release() there is no equivalent to this
NULL assignment.
Did you consider if there was any real reason for the NULL assignment?
Sam
> }
>
> static int drm_minor_register(struct drm_device *dev, unsigned int type)
> @@ -678,16 +664,16 @@ int drm_dev_init(struct drm_device *dev,
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> - goto err_minors;
> + goto err;
> }
>
> ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> if (ret)
> - goto err_minors;
> + goto err;
>
> ret = drm_legacy_create_map_hash(dev);
> if (ret)
> - goto err_minors;
> + goto err;
>
> drm_legacy_ctxbitmap_init(dev);
>
> @@ -695,7 +681,7 @@ int drm_dev_init(struct drm_device *dev,
> ret = drm_gem_init(dev);
> if (ret) {
> DRM_ERROR("Cannot initialize graphics execution manager
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
> }
> }
>
> @@ -708,10 +694,6 @@ int drm_dev_init(struct drm_device *dev,
> err_setunique:
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> -err_ctxbitmap:
> -err_minors:
> - drm_minor_free(dev,
Re: [PATCH 22/51] drm: manage drm_minor cleanup with drmm_
On Mon, Mar 23, 2020 at 03:49:21PM +0100, Daniel Vetter wrote:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
>
> The kdev for the minor already handles NULL, so no problem there.
>
> Hence add drmm_remove_action() to the drm_managed library.
>
> v2: Make pointer math around void ** consistent with what Laurent
> suggested.
>
> v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> because of some questions from Thomas. This also means we need to move
> the drmm_add_action_or_reset helper earlier in the series.
>
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 70 ---
> drivers/gpu/drm/drm_managed.c | 14 +++
> include/drm/drm_managed.h | 9 -
> 3 files changed, 46 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a710c53d13a8..25fc2107057c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> }
> }
>
> +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> +{
> + struct drm_minor *minor = data;
> + unsigned long flags;
> +
> + put_device(minor->kdev);
> +
> + spin_lock_irqsave(_minor_lock, flags);
> + idr_remove(_minors_idr, minor->index);
> + spin_unlock_irqrestore(_minor_lock, flags);
> +}
> +
> static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> {
> struct drm_minor *minor;
> unsigned long flags;
> int r;
>
> - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> if (!minor)
> return -ENOMEM;
>
> @@ -117,46 +129,19 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> idr_preload_end();
>
> if (r < 0)
> - goto err_free;
> + return r;
>
> - minor->index = r;
> + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> + if (r)
> + return r;
>
> + minor->index = r;
This looks wrong.
We do:
r = idr_alloc(_minors_idr,
And then we loose the value when we reuse r
in the call to drmm_add_action_or_reset().
So the index we assign is the return value of
drmm_add_action_or_reset() and not the ID returned
by idr_alloc()
With this fixed:
Reviewed-by: Sam Ravnborg
> minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev)) {
> - r = PTR_ERR(minor->kdev);
> - goto err_index;
> - }
> + if (IS_ERR(minor->kdev))
> + return PTR_ERR(minor->kdev);
>
> *drm_minor_get_slot(dev, type) = minor;
> return 0;
> -
> -err_index:
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -err_free:
> - kfree(minor);
> - return r;
> -}
> -
> -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> -{
> - struct drm_minor **slot, *minor;
> - unsigned long flags;
> -
> - slot = drm_minor_get_slot(dev, type);
> - minor = *slot;
> - if (!minor)
> - return;
> -
> - put_device(minor->kdev);
> -
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -
> - kfree(minor);
> - *slot = NULL;
> }
>
> static int drm_minor_register(struct drm_device *dev, unsigned int type)
> @@ -678,16 +663,16 @@ int drm_dev_init(struct drm_device *dev,
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> - goto err_minors;
> + goto err;
> }
>
> ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> if (ret)
> - goto err_minors;
> + goto err;
>
> ret = drm_legacy_create_map_hash(dev);
> if (ret)
> - goto err_minors;
> + goto err;
>
> drm_legacy_ctxbitmap_init(dev);
>
> @@ -695,7 +680,7 @@ int drm_dev_init(struct drm_device *dev,
> ret = drm_gem_init(dev);
> if (ret) {
> DRM_ERROR("Cannot initialize graphics execution manager
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
> }
> }
>
> @@ -708,10 +693,6 @@ int drm_dev_init(struct drm_device *dev,
> err_setunique:
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> -err_ctxbitmap:
Re: [PATCH 21/51] drm: Use drmm_ for drm_dev_init cleanup
Hi Daniel.
On Mon, Mar 23, 2020 at 03:49:20PM +0100, Daniel Vetter wrote:
> Well for the simple stuff at least, vblank, gem and minor cleanup I
> want to further split up as a demonstration.
>
> v2: We need to clear drm_device->dev otherwise the debug drm printing
> after our cleanup hook (e.g. in drm_manged_release) will chase
> released memory and result in a use-after-free. Not really pretty, but
> oh well.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 48 ---
> 1 file changed, 25 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index c80ebc6811b1..a710c53d13a8 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -580,6 +580,23 @@ static void drm_fs_inode_free(struct inode *inode)
> *used.
> */
>
> +static void drm_dev_init_release(struct drm_device *dev, void *res)
> +{
> + drm_legacy_ctxbitmap_cleanup(dev);
> + drm_legacy_remove_map_hash(dev);
> + drm_fs_inode_free(dev->anon_inode);
> +
> + put_device(dev->dev);
> + /* Prevent use-after-free in drm_managed_release when debugging is
> + * enabled. Slightly awkward, but can't really be helped. */
> + dev->dev = NULL;
> + mutex_destroy(>master_mutex);
> + mutex_destroy(>clientlist_mutex);
> + mutex_destroy(>filelist_mutex);
> + mutex_destroy(>struct_mutex);
> + drm_legacy_destroy_members(dev);
> +}
> +
> /**
> * drm_dev_init - Initialise new DRM device
> * @dev: DRM device
> @@ -647,11 +664,15 @@ int drm_dev_init(struct drm_device *dev,
> mutex_init(>clientlist_mutex);
> mutex_init(>master_mutex);
>
> + ret = drmm_add_action(dev, drm_dev_init_release, NULL);
> + if (ret)
> + return ret;
> +
> dev->anon_inode = drm_fs_inode_new();
> if (IS_ERR(dev->anon_inode)) {
> ret = PTR_ERR(dev->anon_inode);
> DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
> - goto err_free;
> + goto err;
> }
>
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> @@ -688,19 +709,12 @@ int drm_dev_init(struct drm_device *dev,
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> err_ctxbitmap:
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> err_minors:
> drm_minor_free(dev, DRM_MINOR_PRIMARY);
> drm_minor_free(dev, DRM_MINOR_RENDER);
> - drm_fs_inode_free(dev->anon_inode);
> -err_free:
> - put_device(dev->dev);
> - mutex_destroy(>master_mutex);
> - mutex_destroy(>clientlist_mutex);
> - mutex_destroy(>filelist_mutex);
> - mutex_destroy(>struct_mutex);
> - drm_legacy_destroy_members(dev);
> +err:
> + drm_managed_release(dev);
If for example drmm_add_action() fails this will call the following
functions without their init parts called:
drm_legacy_ctxbitmap_cleanup(dev);
This function do:
mutex_lock(>struct_mutex);
idr_destroy(>ctx_idr);
mutex_unlock(>struct_mutex);
Use of struct_mutex - OK
Call to idr_destroy() - I could not convince myself this was OK.
But I did not look too deep into idr_destroy() - thsi is unknown
land for me.
drm_legacy_remove_map_hash(dev);
This function do:
drm_ht_remove(>map_hash); =>
if ((>map_hash)->table) {
->table is NULL is init fucntion is not called - OK
drm_fs_inode_free(dev->anon_inode);
NOP if anon_inode is NULL - OK
So if idr_destroy() call is OK then error handling looks OK
and the patch is:
Reviewed-by: Sam Ravnborg
The error handling is even nicer later in this series.
But I looked only at this patch for now.
Sam
> +
> return ret;
> }
> EXPORT_SYMBOL(drm_dev_init);
> @@ -763,20 +777,8 @@ void drm_dev_fini(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
>
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_legacy_remove_map_hash(dev);
> - drm_fs_inode_free(dev->anon_inode);
> -
> drm_minor_free(dev, DRM_MINOR_PRIMARY);
> drm_minor_free(dev, DRM_MINOR_RENDER);
> -
> - put_device(dev->dev);
> -
> - mutex_destroy(>master_mutex);
> - mutex_destroy(>clientlist_mutex);
> - mutex_destroy(>filelist_mutex);
> - mutex_destroy(>struct_mutex);
> - drm_legacy_destroy_members(dev);
> }
> EXPORT_SYMBOL(drm_dev_fini);
>
> --
> 2.25.1
>
> ___
> 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 v2 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
On Tue, Mar 24, 2020 at 02:45:03PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use in_le32() instead of le32_to_cpup() to fix sparse warning about
> improper type of the argument.
>
> Also add missing inline keyword to control_par_to_var() definition
> (to match function prototype).
>
> Acked-by: Sam Ravnborg
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/video/fbdev/controlfb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
> index 38b61cdb5ca4..9625792f4413 100644
> --- a/drivers/video/fbdev/controlfb.c
> +++ b/drivers/video/fbdev/controlfb.c
> @@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct fb_info
> *info)
> container_of(info, struct fb_info_control, info);
> unsigned ctrl;
>
> - ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
> + ctrl = in_le32(CNTRL_REG(p, ctrl));
> if (blank_mode > 0)
> switch (blank_mode) {
> case FB_BLANK_VSYNC_SUSPEND:
> @@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo
> *var,
> * Convert hardware data in par to an fb_var_screeninfo
> */
>
> -static void control_par_to_var(struct fb_par_control *par, struct
> fb_var_screeninfo *var)
> +static inline void control_par_to_var(struct fb_par_control *par,
Just quick drive-by bikeshed, feel free to ignore: static inline within a
.c file imo doesn't make sense anymore, compilers are smart enough
nowadays. I'd just drop this.
-Daniel
> + struct fb_var_screeninfo *var)
> {
> struct control_regints *rv;
>
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: manage drm_minor cleanup with drmm_
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.
The kdev for the minor already handles NULL, so no problem there.
Hence add drmm_remove_action() to the drm_managed library.
v2: Make pointer math around void ** consistent with what Laurent
suggested.
v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
because of some questions from Thomas. This also means we need to move
the drmm_add_action_or_reset helper earlier in the series.
v4: Uh ... fix slightly embarrassing bug CI spotted.
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 69 ---
drivers/gpu/drm/drm_managed.c | 14 +++
include/drm/drm_managed.h | 9 -
3 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a710c53d13a8..50c56ff24c71 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
drm_device *dev,
}
}
+static void drm_minor_alloc_release(struct drm_device *dev, void *data)
+{
+ struct drm_minor *minor = data;
+ unsigned long flags;
+
+ put_device(minor->kdev);
+
+ spin_lock_irqsave(_minor_lock, flags);
+ idr_remove(_minors_idr, minor->index);
+ spin_unlock_irqrestore(_minor_lock, flags);
+}
+
static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
unsigned long flags;
int r;
- minor = kzalloc(sizeof(*minor), GFP_KERNEL);
+ minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
if (!minor)
return -ENOMEM;
@@ -117,46 +129,20 @@ static int drm_minor_alloc(struct drm_device *dev,
unsigned int type)
idr_preload_end();
if (r < 0)
- goto err_free;
+ return r;
minor->index = r;
+ r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
+ if (r)
+ return r;
+
minor->kdev = drm_sysfs_minor_alloc(minor);
- if (IS_ERR(minor->kdev)) {
- r = PTR_ERR(minor->kdev);
- goto err_index;
- }
+ if (IS_ERR(minor->kdev))
+ return PTR_ERR(minor->kdev);
*drm_minor_get_slot(dev, type) = minor;
return 0;
-
-err_index:
- spin_lock_irqsave(_minor_lock, flags);
- idr_remove(_minors_idr, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
-err_free:
- kfree(minor);
- return r;
-}
-
-static void drm_minor_free(struct drm_device *dev, unsigned int type)
-{
- struct drm_minor **slot, *minor;
- unsigned long flags;
-
- slot = drm_minor_get_slot(dev, type);
- minor = *slot;
- if (!minor)
- return;
-
- put_device(minor->kdev);
-
- spin_lock_irqsave(_minor_lock, flags);
- idr_remove(_minors_idr, minor->index);
- spin_unlock_irqrestore(_minor_lock, flags);
-
- kfree(minor);
- *slot = NULL;
}
static int drm_minor_register(struct drm_device *dev, unsigned int type)
@@ -678,16 +664,16 @@ int drm_dev_init(struct drm_device *dev,
if (drm_core_check_feature(dev, DRIVER_RENDER)) {
ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
if (ret)
- goto err_minors;
+ goto err;
}
ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
if (ret)
- goto err_minors;
+ goto err;
ret = drm_legacy_create_map_hash(dev);
if (ret)
- goto err_minors;
+ goto err;
drm_legacy_ctxbitmap_init(dev);
@@ -695,7 +681,7 @@ int drm_dev_init(struct drm_device *dev,
ret = drm_gem_init(dev);
if (ret) {
DRM_ERROR("Cannot initialize graphics execution manager
(GEM)\n");
- goto err_ctxbitmap;
+ goto err;
}
}
@@ -708,10 +694,6 @@ int drm_dev_init(struct drm_device *dev,
err_setunique:
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_destroy(dev);
-err_ctxbitmap:
-err_minors:
- drm_minor_free(dev, DRM_MINOR_PRIMARY);
- drm_minor_free(dev, DRM_MINOR_RENDER);
err:
drm_managed_release(dev);
@@ -776,9 +758,6 @@ void drm_dev_fini(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_destroy(dev);
-
- drm_minor_free(dev, DRM_MINOR_PRIMARY);
- drm_minor_free(dev, DRM_MINOR_RENDER);
}
EXPORT_SYMBOL(drm_dev_fini);
diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index
Re: [PATCH v8] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
just noticed that the patch title should be changed..
drm/nouveau: prevent putting nvidia GPUs into lower device states on
certain intel bridges
or
drm/nouveau: workaround runpm fail by disabling PCI power management
on certain intel bridges
On Tue, Mar 24, 2020 at 9:29 PM Karol Herbst wrote:
>
> Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
>
> Depending on the used kernel there might be messages like those in demsg:
>
> "nouveau :01:00.0: Refused to change power state, currently in D3"
> "nouveau :01:00.0: can't change power state from D3cold to D0 (config
> space inaccessible)"
> followed by backtraces of kernel crashes or timeouts within nouveau.
>
> It's still unkown why this issue exists, but this is a reliable workaround
> and solves a very annoying issue for user having to choose between a
> crashing kernel or higher power consumption of their Laptops.
>
> Signed-off-by: Karol Herbst
> Cc: Bjorn Helgaas
> Cc: Lyude Paul
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
> ---
> v2: convert to pci_dev quirk
> put a proper technical explanation of the issue as a in-code comment
> v3: disable it only for certain combinations of intel and nvidia hardware
> v4: simplify quirk by setting flag on the GPU itself
> v5: restructure quirk to make it easier to add new IDs
> fix whitespace issues
> fix potential NULL pointer access
> update the quirk documentation
> v6: move quirk into nouveau
> v7: fix typos and commit message
> v8: reset the pm_cap field to get rid of changes in pci core (thanks to
> Bjorn for this idea)
>
> drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
> drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 2cd83849600f..b1beed40e746 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
> kfree(drm);
> }
>
> +/*
> + * On some Intel PCIe bridge controllers doing a
> + * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
> + * Skipping the intermediate D3hot step seems to make it work again. This is
> + * probably caused by not meeting the expectation the involved AML code has
> + * when the GPU is put into D3hot state before invoking it.
> + *
> + * This leads to various manifestations of this issue:
> + * - AML code execution to power on the GPU hits an infinite loop (as the
> + *code waits on device memory to change).
> + * - kernel crashes, as all PCI reads return -1, which most code isn't able
> + *to handle well enough.
> + *
> + * In all cases dmesg will contain at least one line like this:
> + * 'nouveau :01:00.0: Refused to change power state, currently in D3'
> + * followed by a lot of nouveau timeouts.
> + *
> + * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the
> not
> + * documented PCI config space register 0x248 of the Intel PCIe bridge
> + * controller (0x1901) in order to change the state of the PCIe link between
> + * the PCIe port and the GPU. There are alternative code paths using other
> + * registers, which seem to work fine (executed pre Windows 8):
> + * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
> + * - 0xb0 bit 0x10 (link disable)
> + * Changing the conditions inside the firmware by poking into the relevant
> + * addresses does resolve the issue, but it seemed to be ACPI private memory
> + * and not any device accessible memory at all, so there is no portable way
> of
> + * changing the conditions.
> + * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
> + *
> + * The only systems where this behavior can be seen are hybrid graphics
> laptops
> + * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear
> whether
> + * this issue only occurs in combination with listed Intel PCIe bridge
> + * controllers and the mentioned GPUs or other devices as well.
> + *
> + * documentation on the PCIe bridge controller can be found in the
> + * "7th Generation Intel® Processor Families for H Platforms Datasheet
> Volume 2"
> + * Section "12 PCI Express* Controller (x16) Registers"
> + */
> +
> +static void quirk_broken_nv_runpm(struct pci_dev *pdev)
> +{
> + struct drm_device *dev = pci_get_drvdata(pdev);
> + struct nouveau_drm *drm = nouveau_drm(dev);
> + struct pci_dev *bridge = pci_upstream_bridge(pdev);
> +
> + if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
> + return;
> +
> + switch (bridge->device)
[PATCH v8] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
Depending on the used kernel there might be messages like those in demsg:
"nouveau :01:00.0: Refused to change power state, currently in D3"
"nouveau :01:00.0: can't change power state from D3cold to D0 (config
space inaccessible)"
followed by backtraces of kernel crashes or timeouts within nouveau.
It's still unkown why this issue exists, but this is a reliable workaround
and solves a very annoying issue for user having to choose between a
crashing kernel or higher power consumption of their Laptops.
Signed-off-by: Karol Herbst
Cc: Bjorn Helgaas
Cc: Lyude Paul
Cc: Rafael J. Wysocki
Cc: Mika Westerberg
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205623
---
v2: convert to pci_dev quirk
put a proper technical explanation of the issue as a in-code comment
v3: disable it only for certain combinations of intel and nvidia hardware
v4: simplify quirk by setting flag on the GPU itself
v5: restructure quirk to make it easier to add new IDs
fix whitespace issues
fix potential NULL pointer access
update the quirk documentation
v6: move quirk into nouveau
v7: fix typos and commit message
v8: reset the pm_cap field to get rid of changes in pci core (thanks to
Bjorn for this idea)
drivers/gpu/drm/nouveau/nouveau_drm.c | 63 +++
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f..b1beed40e746 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -618,6 +618,64 @@ nouveau_drm_device_fini(struct drm_device *dev)
kfree(drm);
}
+/*
+ * On some Intel PCIe bridge controllers doing a
+ * D0 -> D3hot -> D3cold -> D0 sequence causes Nvidia GPUs to not reappear.
+ * Skipping the intermediate D3hot step seems to make it work again. This is
+ * probably caused by not meeting the expectation the involved AML code has
+ * when the GPU is put into D3hot state before invoking it.
+ *
+ * This leads to various manifestations of this issue:
+ * - AML code execution to power on the GPU hits an infinite loop (as the
+ *code waits on device memory to change).
+ * - kernel crashes, as all PCI reads return -1, which most code isn't able
+ *to handle well enough.
+ *
+ * In all cases dmesg will contain at least one line like this:
+ * 'nouveau :01:00.0: Refused to change power state, currently in D3'
+ * followed by a lot of nouveau timeouts.
+ *
+ * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not
+ * documented PCI config space register 0x248 of the Intel PCIe bridge
+ * controller (0x1901) in order to change the state of the PCIe link between
+ * the PCIe port and the GPU. There are alternative code paths using other
+ * registers, which seem to work fine (executed pre Windows 8):
+ * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')
+ * - 0xb0 bit 0x10 (link disable)
+ * Changing the conditions inside the firmware by poking into the relevant
+ * addresses does resolve the issue, but it seemed to be ACPI private memory
+ * and not any device accessible memory at all, so there is no portable way of
+ * changing the conditions.
+ * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.
+ *
+ * The only systems where this behavior can be seen are hybrid graphics laptops
+ * with a secondary Nvidia Maxwell, Pascal or Turing GPU. It's unclear whether
+ * this issue only occurs in combination with listed Intel PCIe bridge
+ * controllers and the mentioned GPUs or other devices as well.
+ *
+ * documentation on the PCIe bridge controller can be found in the
+ * "7th Generation Intel® Processor Families for H Platforms Datasheet Volume
2"
+ * Section "12 PCI Express* Controller (x16) Registers"
+ */
+
+static void quirk_broken_nv_runpm(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(dev);
+ struct pci_dev *bridge = pci_upstream_bridge(pdev);
+
+ if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
+ return;
+
+ switch (bridge->device) {
+ case 0x1901:
+ drm->old_pm_cap = pdev->pm_cap;
+ pdev->pm_cap = 0;
+ NV_INFO(drm, "Disabling PCI power management to avoid bug\n");
+ break;
+ }
+}
+
static int nouveau_drm_probe(struct pci_dev *pdev,
const struct pci_device_id *pent)
{
@@ -699,6 +757,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (ret)
goto fail_drm_dev_init;
+ quirk_broken_nv_runpm(pdev);
[Bug 206575] [amdgpu] [drm] No video signal on resume from suspend, R9 380
https://bugzilla.kernel.org/show_bug.cgi?id=206575 --- Comment #18 from Joe Ramsey (kernel_bugzi...@joeramsey.com) --- (In reply to Alex Deucher from comment #17) > If you could verify that 5.6 works for you, you could bisect to see what > commit fixed it. OK, I'm about to reveal my ignorance. I just got a chance to compile 5.6-rc7 to confirm that resume from suspend worked (it did), but I have no idea how to bisect. Googled for it and it looks like I need to be using git, but I'm just downloading the tarball from kernel.org to compile my kernel. Is this even worth messing with given that it looks like we may have a stable 5.6 in the near future? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/9] Huge page-table entries for TTM
From: Thomas Hellstrom (VMware)
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables
huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries
on huge_fault fallbacks. Typically on COW or on buffer-objects that want
write-notify. COW and write-notification is always done on the lowest
page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate
the caching- and encryption flags of huge page-table entries without ugly
hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured
to support transhuge pages, either by default or using madvise().
However, they are unlikely to be inserted unless the kernel buffer object
pfns and user-space addresses align perfectly. There are various options
here, but since buffer objects that reside in system pages typically start
at huge page boundaries if they are backed by huge pages, we try to enforce
buffer object starting pfns and user-space addresses to be huge page-size
aligned if their size exceeds a huge page-size. If pud-size transhuge
("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx.
The vmwgfx driver may perform dirty-tracking and needs some special code
to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according
to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for
graphics IO memory. This may later be reused by other graphics drivers
if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
A similar change is needed for graphics drivers that want a reasonable
likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned,
its size will NOT be inflated by this patchset. This means that the buffer
object tail will use smaller size page-table entries and thus no memory
overhead occurs. Drivers that want to pay the memory overhead price need to
implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to
work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing
using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
memory resources.
This patch series is now about to become a pull request.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase
adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support
transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title.
Changes since v3:
* Added reviews and acks
* Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch
specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v5:
* Fix drm build error with !CONFIG_MMU
(Reported-by: kbuild test robot )
Changes since v6:
* drm_file.c new includes also conditioned on CONFIG_TRANSPARENT_HUGEPAGE
* checkpatch complained about formatting of a commit message - fixed.
* Updated Thomas' email address
* Added acks from Andrew Morton
[1]
The below test program generates the following gnu time output when run on a
vmwgfx-enabled kernel without the patch series:
4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k
0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k
0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal
graphics applications, but probably due to the aggressive buffer object
caching in vmwgfx user-space drivers the CPU time reduction is within
error limits.
#include
#include
#include
#include
static void checkerr(int ret, const char *name)
{
if (ret < 0) {
perror(name);
exit(-1);
}
}
int main(int agc, const char *argv[])
{
struct drm_mode_create_dumb c_arg = {0};
struct drm_mode_map_dumb m_arg =
[PATCH v7 5/9] drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
From: "Thomas Hellstrom (VMware)"
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be
compiled with trans-huge-pages always enabled, or the kernel needs to be
compiled with trans-huge-pages enabled using madvise, and the user-space
app needs to call madvise() to enable trans-huge pages on a per-mapping
basis.
Furthermore huge page-faults will not succeed unless buffer objects and
user-space addresses are aligned on huge page size boundaries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 161 -
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 3 +-
3 files changed, 161 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b8c4dd..0af14835504c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -156,6 +156,89 @@ vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/**
+ * ttm_bo_vm_insert_huge - Insert a pfn for PUD or PMD faults
+ * @vmf: Fault data
+ * @bo: The buffer object
+ * @page_offset: Page offset from bo start
+ * @fault_page_size: The size of the fault in pages.
+ * @pgprot: The page protections.
+ * Does additional checking whether it's possible to insert a PUD or PMD
+ * pfn and performs the insertion.
+ *
+ * Return: VM_FAULT_NOPAGE on successful insertion, VM_FAULT_FALLBACK if
+ * a huge fault was not possible, or on insertion error.
+ */
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ pgoff_t i;
+ vm_fault_t ret;
+ unsigned long pfn;
+ pfn_t pfnt;
+ struct ttm_tt *ttm = bo->ttm;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+
+ /* Fault should not cross bo boundary. */
+ page_offset &= ~(fault_page_size - 1);
+ if (page_offset + fault_page_size > bo->num_pages)
+ goto out_fallback;
+
+ if (bo->mem.bus.is_iomem)
+ pfn = ttm_bo_io_mem_pfn(bo, page_offset);
+ else
+ pfn = page_to_pfn(ttm->pages[page_offset]);
+
+ /* pfn must be fault_page_size aligned. */
+ if ((pfn & (fault_page_size - 1)) != 0)
+ goto out_fallback;
+
+ /* Check that memory is contiguous. */
+ if (!bo->mem.bus.is_iomem) {
+ for (i = 1; i < fault_page_size; ++i) {
+ if (page_to_pfn(ttm->pages[page_offset + i]) != pfn + i)
+ goto out_fallback;
+ }
+ } else if (bo->bdev->driver->io_mem_pfn) {
+ for (i = 1; i < fault_page_size; ++i) {
+ if (ttm_bo_io_mem_pfn(bo, page_offset + i) != pfn + i)
+ goto out_fallback;
+ }
+ }
+
+ pfnt = __pfn_to_pfn_t(pfn, PFN_DEV);
+ if (fault_page_size == (HPAGE_PMD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write);
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ else if (fault_page_size == (HPAGE_PUD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pud_prot(vmf, pfnt, pgprot, write);
+#endif
+ else
+ WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);
+
+ if (ret != VM_FAULT_NOPAGE)
+ goto out_fallback;
+
+ return VM_FAULT_NOPAGE;
+out_fallback:
+ count_vm_event(THP_FAULT_FALLBACK);
+ return VM_FAULT_FALLBACK;
+}
+#else
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ return VM_FAULT_FALLBACK;
+}
+#endif
+
/**
* ttm_bo_vm_fault_reserved - TTM fault helper
* @vmf: The struct vm_fault given as argument to the fault callback
@@ -163,6 +246,7 @@ EXPORT_SYMBOL(ttm_bo_vm_reserve);
* @num_prefault: Maximum number of prefault pages. The caller may want to
* specify this based on madvice settings and the size of the GPU object
* backed by the memory.
+ * @fault_page_size: The
[PATCH v7 2/9] mm: Introduce vma_is_special_huge
From: "Thomas Hellstrom (VMware)"
For VM_PFNMAP and VM_MIXEDMAP vmas that want to support transhuge pages
and -page table entries, introduce vma_is_special_huge() that takes the
same codepaths as vma_is_dax().
The use of "special" follows the definition in memory.c, vm_normal_page():
"Special" mappings do not wish to be associated with a "struct page"
(either it doesn't exist, or it exists but they don't want to touch it)
For PAGE_SIZE pages, "special" is determined per page table entry to be
able to deal with COW pages. But since we don't have huge COW pages,
we can classify a vma as either "special huge" or "normal huge".
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Acked-by: Christian König
Acked-by: Andrew Morton
---
include/linux/mm.h | 17 +
mm/huge_memory.c | 6 +++---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c54fb96cb1e6..bdd79a72bb42 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2867,6 +2867,23 @@ extern long copy_huge_page_from_user(struct page
*dst_page,
const void __user *usr_src,
unsigned int pages_per_huge_page,
bool allow_pagefault);
+
+/**
+ * vma_is_special_huge - Are transhuge page-table entries considered special?
+ * @vma: Pointer to the struct vm_area_struct to consider
+ *
+ * Whether transhuge page-table entries are considered "special" following
+ * the definition in vm_normal_page().
+ *
+ * Return: true if transhuge page-table entries should be considered special,
+ * false otherwise.
+ */
+static inline bool vma_is_special_huge(const struct vm_area_struct *vma)
+{
+ return vma_is_dax(vma) || (vma->vm_file &&
+ (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP)));
+}
+
#endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_HUGETLBFS */
#ifdef CONFIG_DEBUG_PAGEALLOC
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 24ad53b4dfc0..19c8d462ab08 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1802,7 +1802,7 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct
vm_area_struct *vma,
orig_pmd = pmdp_huge_get_and_clear_full(tlb->mm, addr, pmd,
tlb->fullmm);
tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
if (arch_needs_pgtable_deposit())
zap_deposited_table(tlb->mm, pmd);
spin_unlock(ptl);
@@ -2066,7 +2066,7 @@ int zap_huge_pud(struct mmu_gather *tlb, struct
vm_area_struct *vma,
*/
pudp_huge_get_and_clear_full(tlb->mm, addr, pud, tlb->fullmm);
tlb_remove_pud_tlb_entry(tlb, pud, addr);
- if (vma_is_dax(vma)) {
+ if (vma_is_special_huge(vma)) {
spin_unlock(ptl);
/* No zero page support yet */
} else {
@@ -2175,7 +2175,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct
*vma, pmd_t *pmd,
*/
if (arch_needs_pgtable_deposit())
zap_deposited_table(mm, pmd);
- if (vma_is_dax(vma))
+ if (vma_is_special_huge(vma))
return;
page = pmd_page(_pmd);
if (!PageDirty(page) && pmd_dirty(_pmd))
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 3/9] mm: Split huge pages on write-notify or COW
From: "Thomas Hellstrom (VMware)"
The functions wp_huge_pmd() and wp_huge_pud() currently relies on the
huge_fault() callback to split huge page table entries if needed.
However for module users that requires export of the split_huge_xxx()
functionality which may be undesired. Instead split pre-existing huge
page-table entries on VM_FAULT_FALLBACK return.
We currently only do COW and write-notify on the PTE level, so if the
huge_fault() handler returns VM_FAULT_FALLBACK on wp faults,
split the huge pages and page-table entries. Also do this for huge PUDs
if there is no huge_fault() handler and the vma is not anonymous, similar
to how it's done for PMDs.
Note that fs/dax.c still does the splitting in the huge_fault() handler,
but as huge_fault() A follow-up patch can remove the dax.c split_huge_pmd()
if needed.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Acked-by: Christian König
Acked-by: Andrew Morton
---
mm/memory.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e8bfdf0d9d1d..efa59b1b109c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3951,11 +3951,14 @@ static inline vm_fault_t wp_huge_pmd(struct vm_fault
*vmf, pmd_t orig_pmd)
{
if (vma_is_anonymous(vmf->vma))
return do_huge_pmd_wp_page(vmf, orig_pmd);
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PMD);
- /* COW handled on pte level: split pmd */
- VM_BUG_ON_VMA(vmf->vma->vm_flags & VM_SHARED, vmf->vma);
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+
+ /* COW or write-notify handled on pte level: split pmd. */
__split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
return VM_FAULT_FALLBACK;
@@ -3968,12 +3971,20 @@ static inline bool vma_is_accessible(struct
vm_area_struct *vma)
static vm_fault_t create_huge_pud(struct vm_fault *vmf)
{
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#if defined(CONFIG_TRANSPARENT_HUGEPAGE) &&\
+ defined(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)
/* No support for anonymous transparent PUD pages yet */
if (vma_is_anonymous(vmf->vma))
- return VM_FAULT_FALLBACK;
- if (vmf->vma->vm_ops->huge_fault)
- return vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+ goto split;
+ if (vmf->vma->vm_ops->huge_fault) {
+ vm_fault_t ret = vmf->vma->vm_ops->huge_fault(vmf, PE_SIZE_PUD);
+
+ if (!(ret & VM_FAULT_FALLBACK))
+ return ret;
+ }
+split:
+ /* COW or write-notify not handled on PUD level: split pud.*/
+ __split_huge_pud(vmf->vma, vmf->pud, vmf->address);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
return VM_FAULT_FALLBACK;
}
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 4/9] mm: Add vmf_insert_pfn_xxx_prot() for huge page-table entries
From: "Thomas Hellstrom (VMware)"
For graphics drivers needing to modify the page-protection, add
huge page-table entries counterparts to vmf_insert_pfn_prot().
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Acked-by: Christian König
Acked-by: Andrew Morton
---
include/linux/huge_mm.h | 41 +++--
mm/huge_memory.c| 38 --
2 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 5aca3d1bdb32..f63b0882c1b3 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -47,8 +47,45 @@ extern bool move_huge_pmd(struct vm_area_struct *vma,
unsigned long old_addr,
extern int change_huge_pmd(struct vm_area_struct *vma, pmd_t *pmd,
unsigned long addr, pgprot_t newprot,
int prot_numa);
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write);
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write);
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pmd - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pmd_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write);
+
+/**
+ * vmf_insert_pfn_pud - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info.
+ *
+ * Return: vm_fault_t value.
+ */
+static inline vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn,
+ bool write)
+{
+ return vmf_insert_pfn_pud_prot(vmf, pfn, vmf->vma->vm_page_prot, write);
+}
+
enum transparent_hugepage_flag {
TRANSPARENT_HUGEPAGE_FLAG,
TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 19c8d462ab08..4036d5e0a6f3 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -824,11 +824,24 @@ static void insert_pfn_pmd(struct vm_area_struct *vma,
unsigned long addr,
pte_free(mm, pgtable);
}
-vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pmd_prot - insert a pmd size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pmd size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pmd_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PMD_MASK;
struct vm_area_struct *vma = vmf->vma;
- pgprot_t pgprot = vma->vm_page_prot;
pgtable_t pgtable = NULL;
/*
@@ -856,7 +869,7 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, pfn_t
pfn, bool write)
insert_pfn_pmd(vma, addr, vmf->pmd, pfn, pgprot, write, pgtable);
return VM_FAULT_NOPAGE;
}
-EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd);
+EXPORT_SYMBOL_GPL(vmf_insert_pfn_pmd_prot);
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma)
@@ -902,11 +915,24 @@ static void insert_pfn_pud(struct vm_area_struct *vma,
unsigned long addr,
spin_unlock(ptl);
}
-vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write)
+/**
+ * vmf_insert_pfn_pud_prot - insert a pud size pfn
+ * @vmf: Structure describing the fault
+ * @pfn: pfn to insert
+ * @pgprot: page protection to use
+ * @write: whether it's a write fault
+ *
+ * Insert a pud size pfn. See vmf_insert_pfn() for additional info and
+ * also consult the vmf_insert_mixed_prot() documentation when
+ * @pgprot != @vmf->vma->vm_page_prot.
+ *
+ * Return: vm_fault_t value.
+ */
+vm_fault_t vmf_insert_pfn_pud_prot(struct vm_fault *vmf, pfn_t pfn,
+ pgprot_t pgprot, bool write)
{
unsigned long addr = vmf->address & PUD_MASK;
struct
[PATCH v7 8/9] drm/vmwgfx: Introduce a huge page aligning TTM range manager
From: "Thomas Hellstrom (VMware)"
Using huge page-table entries requires that the physical address of the
start of a buffer object is huge page size aligned.
Make a special version of the TTM range manager that accomplishes this,
but falls back to a smaller page size alignment (PUD->PMD, PMD->NORMAL)
to avoid eviction.
If other drivers want to use it in the future, it can be made a
TTM generic helper. Note that drivers can force eviction for a certain
alignment by assigning the TTM GPU alignment correspondingly.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/Makefile | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 7 ++
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 166
3 files changed, 174 insertions(+)
create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index c877a21a0739..421dd2a497a5 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -11,4 +11,5 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_validation.o vmwgfx_page_dirty.o \
ttm_object.o ttm_lock.o
+vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 6fc8d5c171c6..d19d28c13671 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1407,6 +1407,13 @@ vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
enum page_entry_size pe_size);
#endif
+/* Transparent hugepage support - vmwgfx_thp.c */
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+extern const struct ttm_mem_type_manager_func vmw_thp_func;
+#else
+#define vmw_thp_func ttm_bo_manager_func
+#endif
+
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
new file mode 100644
index ..b7c816ba7166
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_thp.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Huge page-table-entry support for IO memory.
+ *
+ * Copyright (C) 2007-2019 Vmware, Inc. All rights reservedd.
+ */
+#include "vmwgfx_drv.h"
+#include
+#include
+#include
+
+/**
+ * struct vmw_thp_manager - Range manager implementing huge page alignment
+ *
+ * @mm: The underlying range manager. Protected by @lock.
+ * @lock: Manager lock.
+ */
+struct vmw_thp_manager {
+ struct drm_mm mm;
+ spinlock_t lock;
+};
+
+static int vmw_thp_insert_aligned(struct drm_mm *mm, struct drm_mm_node *node,
+ unsigned long align_pages,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem,
+ unsigned long lpfn,
+ enum drm_mm_insert_mode mode)
+{
+ if (align_pages >= mem->page_alignment &&
+ (!mem->page_alignment || align_pages % mem->page_alignment == 0)) {
+ return drm_mm_insert_node_in_range(mm, node,
+ mem->num_pages,
+ align_pages, 0,
+ place->fpfn, lpfn, mode);
+ }
+
+ return -ENOSPC;
+}
+
+static int vmw_thp_get_node(struct ttm_mem_type_manager *man,
+ struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+ struct vmw_thp_manager *rman = (struct vmw_thp_manager *) man->priv;
+ struct drm_mm *mm = >mm;
+ struct drm_mm_node *node;
+ unsigned long align_pages;
+ unsigned long lpfn;
+ enum drm_mm_insert_mode mode = DRM_MM_INSERT_BEST;
+ int ret;
+
+ node = kzalloc(sizeof(*node), GFP_KERNEL);
+ if (!node)
+ return -ENOMEM;
+
+ lpfn = place->lpfn;
+ if (!lpfn)
+ lpfn = man->size;
+
+ mode = DRM_MM_INSERT_BEST;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
+
+ spin_lock(>lock);
+ if (IS_ENABLED(CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD)) {
+ align_pages = (HPAGE_PUD_SIZE >> PAGE_SHIFT);
+ if (mem->num_pages >= align_pages) {
+ ret = vmw_thp_insert_aligned(mm, node, align_pages,
+place, mem, lpfn, mode);
+ if (!ret)
+ goto found_unlock;
+ }
+
[PATCH v7 9/9] drm/vmwgfx: Hook up the helpers to align buffer objects
From: "Thomas Hellstrom (VMware)"
Start using the helpers that align buffer object user-space addresses and
buffer object vram addresses to huge page boundaries.
This is to improve the chances of allowing huge page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/drm_file.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 13 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d1fcb0c61622..eb009d3ab48f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -1011,4 +1011,5 @@ unsigned long drm_get_unmapped_area(struct file *file,
return current->mm->get_unmapped_area(file, uaddr, len, pgoff, flags);
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
+EXPORT_SYMBOL_GPL(drm_get_unmapped_area);
#endif /* CONFIG_MMU */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4f58364421ce..f0b7a891cbad 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1230,6 +1230,18 @@ static void vmw_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static unsigned long
+vmw_get_unmapped_area(struct file *file, unsigned long uaddr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ struct drm_file *file_priv = file->private_data;
+ struct vmw_private *dev_priv = vmw_priv(file_priv->minor->dev);
+
+ return drm_get_unmapped_area(file, uaddr, len, pgoff, flags,
+_priv->vma_manager);
+}
+
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
void *ptr)
{
@@ -1401,6 +1413,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.compat_ioctl = vmw_compat_ioctl,
#endif
.llseek = noop_llseek,
+ .get_unmapped_area = vmw_get_unmapped_area,
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index d19d28c13671..fc98622caf87 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -915,6 +915,7 @@ extern int vmw_mmap(struct file *filp, struct
vm_area_struct *vma);
extern void vmw_validation_mem_init_ttm(struct vmw_private *dev_priv,
size_t gran);
+
/**
* TTM buffer object driver - vmwgfx_ttm_buffer.c
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 3f3b2c7a208a..bf0bc4697959 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -749,7 +749,7 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
- man->func = _bo_manager_func;
+ man->func = _thp_func;
man->gpu_offset = 0;
man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_CACHED;
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 6/9] drm/vmwgfx: Support huge page faults
From: "Thomas Hellstrom (VMware)"
With vmwgfx dirty-tracking we need a specialized huge_fault
callback. Implement and hook it up.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 ++
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 74 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 5 +-
3 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index b70d73225707..6fc8d5c171c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1402,6 +1402,10 @@ void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo,
pgoff_t start, pgoff_t end);
vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf);
vm_fault_t vmw_bo_vm_mkwrite(struct vm_fault *vmf);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size);
+#endif
/**
* VMW_DEBUG_KMS - Debug output for kernel mode-setting
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
index 8cf7a77c9b2f..d4d66532f9c9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
@@ -473,7 +473,7 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
* a lot of unnecessary write faults.
*/
if (vbo->dirty && vbo->dirty->method == VMW_BO_DIRTY_MKWRITE)
- prot = vma->vm_page_prot;
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
else
prot = vm_get_page_prot(vma->vm_flags);
@@ -486,3 +486,75 @@ vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf)
return ret;
}
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+vm_fault_t vmw_bo_vm_huge_fault(struct vm_fault *vmf,
+ enum page_entry_size pe_size)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
+ vma->vm_private_data;
+ struct vmw_buffer_object *vbo =
+ container_of(bo, struct vmw_buffer_object, base);
+ pgprot_t prot;
+ vm_fault_t ret;
+ pgoff_t fault_page_size;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+ bool is_cow_mapping =
+ (vma->vm_flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
+
+ switch (pe_size) {
+ case PE_SIZE_PMD:
+ fault_page_size = HPAGE_PMD_SIZE >> PAGE_SHIFT;
+ break;
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ case PE_SIZE_PUD:
+ fault_page_size = HPAGE_PUD_SIZE >> PAGE_SHIFT;
+ break;
+#endif
+ default:
+ WARN_ON_ONCE(1);
+ return VM_FAULT_FALLBACK;
+ }
+
+ /* Always do write dirty-tracking and COW on PTE level. */
+ if (write && (READ_ONCE(vbo->dirty) || is_cow_mapping))
+ return VM_FAULT_FALLBACK;
+
+ ret = ttm_bo_vm_reserve(bo, vmf);
+ if (ret)
+ return ret;
+
+ if (vbo->dirty) {
+ pgoff_t allowed_prefault;
+ unsigned long page_offset;
+
+ page_offset = vmf->pgoff -
+ drm_vma_node_start(>base.vma_node);
+ if (page_offset >= bo->num_pages ||
+ vmw_resources_clean(vbo, page_offset,
+ page_offset + PAGE_SIZE,
+ _prefault)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_unlock;
+ }
+
+ /*
+* Write protect, so we get a new fault on write, and can
+* split.
+*/
+ prot = vm_get_page_prot(vma->vm_flags & ~VM_SHARED);
+ } else {
+ prot = vm_get_page_prot(vma->vm_flags);
+ }
+
+ ret = ttm_bo_vm_fault_reserved(vmf, prot, 1, fault_page_size);
+ if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
+ return ret;
+
+out_unlock:
+ dma_resv_unlock(bo->base.resv);
+
+ return ret;
+}
+#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
index aa7e50f63b94..3c03b1746661 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
@@ -34,7 +34,10 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma)
.page_mkwrite = vmw_bo_vm_mkwrite,
.fault = vmw_bo_vm_fault,
.open = ttm_bo_vm_open,
- .close = ttm_bo_vm_close
+ .close =
[PATCH v7 7/9] drm: Add a drm_get_unmapped_area() helper
From: "Thomas Hellstrom (VMware)"
Unaligned virtual addresses makes it unlikely that huge page-table entries
can be used.
So align virtual buffer object address huge page boundaries to the
underlying physical address huge page boundaries taking buffer object
sizes into account to determine when it might be possible to use huge
page-table entries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
drivers/gpu/drm/drm_file.c | 140 +
include/drm/drm_file.h | 9 +++
2 files changed, 149 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e01961..d1fcb0c61622 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -48,6 +48,11 @@
#include "drm_internal.h"
#include "drm_legacy.h"
+#if defined(CONFIG_MMU) && defined(CONFIG_TRANSPARENT_HUGEPAGE)
+#include
+#include
+#endif
+
/* from BKL pushdown */
DEFINE_MUTEX(drm_global_mutex);
@@ -872,3 +877,138 @@ struct file *mock_drm_getfile(struct drm_minor *minor,
unsigned int flags)
return file;
}
EXPORT_SYMBOL_FOR_TESTS_ONLY(mock_drm_getfile);
+
+#ifdef CONFIG_MMU
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * drm_addr_inflate() attempts to construct an aligned area by inflating
+ * the area size and skipping the unaligned start of the area.
+ * adapted from shmem_get_unmapped_area()
+ */
+static unsigned long drm_addr_inflate(unsigned long addr,
+ unsigned long len,
+ unsigned long pgoff,
+ unsigned long flags,
+ unsigned long huge_size)
+{
+ unsigned long offset, inflated_len;
+ unsigned long inflated_addr;
+ unsigned long inflated_offset;
+
+ offset = (pgoff << PAGE_SHIFT) & (huge_size - 1);
+ if (offset && offset + len < 2 * huge_size)
+ return addr;
+ if ((addr & (huge_size - 1)) == offset)
+ return addr;
+
+ inflated_len = len + huge_size - PAGE_SIZE;
+ if (inflated_len > TASK_SIZE)
+ return addr;
+ if (inflated_len < len)
+ return addr;
+
+ inflated_addr = current->mm->get_unmapped_area(NULL, 0, inflated_len,
+ 0, flags);
+ if (IS_ERR_VALUE(inflated_addr))
+ return addr;
+ if (inflated_addr & ~PAGE_MASK)
+ return addr;
+
+ inflated_offset = inflated_addr & (huge_size - 1);
+ inflated_addr += offset - inflated_offset;
+ if (inflated_offset > offset)
+ inflated_addr += huge_size;
+
+ if (inflated_addr > TASK_SIZE - len)
+ return addr;
+
+ return inflated_addr;
+}
+
+/**
+ * drm_get_unmapped_area() - Get an unused user-space virtual memory area
+ * suitable for huge page table entries.
+ * @file: The struct file representing the address space being mmap()'d.
+ * @uaddr: Start address suggested by user-space.
+ * @len: Length of the area.
+ * @pgoff: The page offset into the address space.
+ * @flags: mmap flags
+ * @mgr: The address space manager used by the drm driver. This argument can
+ * probably be removed at some point when all drivers use the same
+ * address space manager.
+ *
+ * This function attempts to find an unused user-space virtual memory area
+ * that can accommodate the size we want to map, and that is properly
+ * aligned to facilitate huge page table entries matching actual
+ * huge pages or huge page aligned memory in buffer objects. Buffer objects
+ * are assumed to start at huge page boundary pfns (io memory) or be
+ * populated by huge pages aligned to the start of the buffer object
+ * (system- or coherent memory). Adapted from shmem_get_unmapped_area.
+ *
+ * Return: aligned user-space address.
+ */
+unsigned long drm_get_unmapped_area(struct file *file,
+ unsigned long uaddr, unsigned long len,
+ unsigned long pgoff, unsigned long flags,
+ struct drm_vma_offset_manager *mgr)
+{
+ unsigned long addr;
+ unsigned long inflated_addr;
+ struct drm_vma_offset_node *node;
+
+ if (len > TASK_SIZE)
+ return -ENOMEM;
+
+ /*
+* @pgoff is the file page-offset the huge page boundaries of
+* which typically aligns to physical address huge page boundaries.
+* That's not true for DRM, however, where physical address huge
+* page boundaries instead are aligned with the offset from
+* buffer object start. So adjust @pgoff to be the offset from
+* buffer object start.
+*/
+
[PATCH v7 1/9] fs: Constify vma argument to vma_is_dax
From: "Thomas Hellstrom (VMware)"
The function is used by upcoming vma_is_special_huge() with which we want
to use a const vma argument. Since for vma_is_dax() the vma argument is
only dereferenced for reading, constify it.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom (VMware)
Reviewed-by: Roland Scheidegger
Acked-by: Christian König
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3cd4fe6b845e..2b38ce5b73ad 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3391,7 +3391,7 @@ static inline bool io_is_direct(struct file *filp)
return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
}
-static inline bool vma_is_dax(struct vm_area_struct *vma)
+static inline bool vma_is_dax(const struct vm_area_struct *vma)
{
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/radeon: remove unneeded header include path
On Tue, Mar 24, 2020 at 12:48 PM Masahiro Yamada wrote: > > Hi, > > I think this series is a good clean-up. > > Could you take a look at this please? Can you resend? I don't seem to have gotten it. Must have ended up getting flagged a spam or something. Alex > > > > On Fri, Feb 14, 2020 at 12:40 AM Masahiro Yamada wrote: > > > > A header include path without $(srctree)/ is suspicious because it does > > not work with O= builds. > > > > You can build drivers/gpu/drm/radeon/ without this include path. > > > > Signed-off-by: Masahiro Yamada > > --- > > > > drivers/gpu/drm/radeon/Makefile | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/radeon/Makefile > > b/drivers/gpu/drm/radeon/Makefile > > index c693b2ca0329..9d5d3dc1011f 100644 > > --- a/drivers/gpu/drm/radeon/Makefile > > +++ b/drivers/gpu/drm/radeon/Makefile > > @@ -3,8 +3,6 @@ > > # Makefile for the drm device driver. This driver provides support for the > > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > > > -ccflags-y := -Idrivers/gpu/drm/amd/include > > - > > hostprogs := mkregtable > > clean-files := rn50_reg_safe.h r100_reg_safe.h r200_reg_safe.h > > rv515_reg_safe.h r300_reg_safe.h r420_reg_safe.h rs600_reg_safe.h > > r600_reg_safe.h evergreen_reg_safe.h cayman_reg_safe.h > > > > -- > > 2.17.1 > > > > > -- > Best Regards > Masahiro Yamada > ___ > 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 v10 2/2] drm/bridge: Add NWL MIPI DSI host controller support
On Fri, Mar 20, 2020 at 3:49 PM Guido Günther wrote: > > This adds initial support for the NWL MIPI DSI Host controller found on > i.MX8 SoCs. > > It adds support for the i.MX8MQ but the same IP can be found on > e.g. the i.MX8QXP. > > It has been tested on the Librem 5 devkit using mxsfb. > > Signed-off-by: Guido Günther > Co-developed-by: Robert Chiras > Signed-off-by: Robert Chiras > Tested-by: Robert Chiras > Tested-by: Martin Kepplinger Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
On Fri, Mar 20, 2020 at 3:49 PM Guido Günther wrote: > > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. > > Signed-off-by: Guido Günther > Tested-by: Robert Chiras > Reviewed-by: Rob Herring > Acked-by: Sam Ravnborg Reviewed-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/dp_mst: Remove VCPI while disabling topology mgr"
Huh? There was an alternative fix for this pushed a while ago:
8732fe46b20c ("drm/dp_mst: Fix clearing payload state on topology disable")
But I'm not seeing it in master, although it is cc'd for stable :S
On Sun, 2020-03-22 at 16:42 +0100, Jiri Kosina wrote:
> On Fri, 17 Jan 2020, Lyude Paul wrote:
>
> > This reverts commit 64e62bdf04ab8529f45ed0a85122c703035dec3a.
> >
> > This commit ends up causing some lockdep splats due to trying to grab the
> > payload lock while holding the mgr's lock:
> >
> > [ 54.010099]
> > [ 54.011765] ==
> > [ 54.018670] WARNING: possible circular locking dependency detected
> > [ 54.025577] 5.5.0-rc6-02274-g77381c23ee63 #47 Not tainted
> > [ 54.031610] --
> > [ 54.038516] kworker/1:6/1040 is trying to acquire lock:
> > [ 54.044354] 888272af3228 (>payload_lock){+.+.}, at:
> > drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> > [ 54.054957]
> > [ 54.054957] but task is already holding lock:
> > [ 54.061473] 888272af3060 (>lock){+.+.}, at:
> > drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> > [ 54.071193]
> > [ 54.071193] which lock already depends on the new lock.
>
> So I just received this very lockdep splat on 5.6-rc3 (I know, it's not
> the latest and greatest, but I don't see anything related between 5.6-rc3
> and Linus' HEAD).
>
> Seems like this revert was never applied. Could this please be revisited?
> Or has some alternative fix been comitted between 5.6-rc3 and current?
>
> Thanks.
>
> > [ 54.071193]
> > [ 54.080334]
> > [ 54.080334] the existing dependency chain (in reverse order) is:
> > [ 54.088697]
> > [ 54.088697] -> #1 (>lock){+.+.}:
> > [ 54.094440]__mutex_lock+0xc3/0x498
> > [ 54.099015]drm_dp_mst_topology_get_port_validated+0x25/0x80
> > [ 54.106018]drm_dp_update_payload_part1+0xa2/0x2e2
> > [ 54.112051]intel_mst_pre_enable_dp+0x144/0x18f
> > [ 54.117791]intel_encoders_pre_enable+0x63/0x70
> > [ 54.123532]hsw_crtc_enable+0xa1/0x722
> > [ 54.128396]intel_update_crtc+0x50/0x194
> > [ 54.133455]skl_commit_modeset_enables+0x40c/0x540
> > [ 54.139485]intel_atomic_commit_tail+0x5f7/0x130d
> > [ 54.145418]intel_atomic_commit+0x2c8/0x2d8
> > [ 54.150770]drm_atomic_helper_set_config+0x5a/0x70
> > [ 54.156801]drm_mode_setcrtc+0x2ab/0x833
> > [ 54.161862]drm_ioctl+0x2e5/0x424
> > [ 54.166242]vfs_ioctl+0x21/0x2f
> > [ 54.170426]do_vfs_ioctl+0x5fb/0x61e
> > [ 54.175096]ksys_ioctl+0x55/0x75
> > [ 54.179377]__x64_sys_ioctl+0x1a/0x1e
> > [ 54.184146]do_syscall_64+0x5c/0x6d
> > [ 54.188721]entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > [ 54.194946]
> > [ 54.194946] -> #0 (>payload_lock){+.+.}:
> > [ 54.201463]
> > [ 54.201463] other info that might help us debug this:
> > [ 54.201463]
> > [ 54.210410] Possible unsafe locking scenario:
> > [ 54.210410]
> > [ 54.217025]CPU0CPU1
> > [ 54.222082]
> > [ 54.227138] lock(>lock);
> > [ 54.230643]lock(>payload_lock);
> > [ 54.237742]lock(>lock);
> > [ 54.244062] lock(>payload_lock);
> > [ 54.248346]
> > [ 54.248346] *** DEADLOCK ***
> > [ 54.248346]
> > [ 54.254959] 7 locks held by kworker/1:6/1040:
> > [ 54.259822] #0: 888275c4f528 ((wq_completion)events){+.+.},
> > at: worker_thread+0x455/0x6e2
> > [ 54.269451] #1: c9000119beb0
> > ((work_completion)(&(_priv->hotplug.hotplug_work)->work)){+.+.},
> > at: worker_thread+0x455/0x6e2
> > [ 54.282768] #2: 888272a403f0 (>mode_config.mutex){+.+.},
> > at: i915_hotplug_work_func+0x4b/0x2be
> > [ 54.293368] #3: 824fc6c0 (drm_connector_list_iter){.+.+},
> > at: i915_hotplug_work_func+0x17e/0x2be
> > [ 54.304061] #4: c9000119bc58 (crtc_ww_class_acquire){+.+.},
> > at: drm_helper_probe_detect_ctx+0x40/0xfd
> > [ 54.314855] #5: 888272a40470 (crtc_ww_class_mutex){+.+.}, at:
> > drm_modeset_lock+0x74/0xe2
> > [ 54.324385] #6: 888272af3060 (>lock){+.+.}, at:
> > drm_dp_mst_topology_mgr_set_mst+0x3c/0x2e4
> > [ 54.334597]
> > [ 54.334597] stack backtrace:
> > [ 54.339464] CPU: 1 PID: 1040 Comm: kworker/1:6 Not tainted
> > 5.5.0-rc6-02274-g77381c23ee63 #47
> > [ 54.348893] Hardware name: Google Fizz/Fizz, BIOS
> > Google_Fizz.10139.39.0 01/04/2018
> > [ 54.357451] Workqueue: events i915_hotplug_work_func
> > [ 54.362995] Call Trace:
> > [ 54.365724] dump_stack+0x71/0x9c
> > [ 54.369427] check_noncircular+0x91/0xbc
> > [ 54.373809] ? __lock_acquire+0xc9e/0xf66
> > [ 54.378286] ? __lock_acquire+0xc9e/0xf66
> > [ 54.382763] ? lock_acquire+0x175/0x1ac
> > [ 54.387048] ? drm_dp_mst_topology_mgr_set_mst+0x218/0x2e4
> > [
latencies and code inefficiencies in amdgpu display handling
Hi guys, recently I've been tracing some IRQ latencies in a system and the display handling in amdgpu doesn't really look that good. To be honest it also doesn't look too bad, but I still want to share my findings here. The trace below is from a single vblank IRQ with a pageflip. The most interesting points from my perspective: 1. While this is a single CRTC vblank IRQ, the handler calls amdgpu_get_vblank_counter_kms 10(!) times. This isn't really a cheap function as it also reads the current scanout position and thus makes multiple MMIO device reads. This seems like low-hanging fruit for optimiaztion, as querying the same thing this many times in a single IRQ invocation seems like total overkill. 2. In this particular trace one of the scanout position reads seems to block. The trace indicates that almost 300us are spent in this single device read. Is this a known issue? 3. There are quite a few spinlocks being locked with spin_lock_irqsave, while this handler code is never called from non-IRQ context, so all those calls could use the cheaper spin_lock. This is a micro optimization, but it caught my eye when looking over the trace/code. Regards, Lucas # tracer: irqsoff # # irqsoff latency trace v1.1.5 on 5.6.0-rc7+ # # latency: 417 us, #446/446, CPU#6 | (M:desktop VP:0, KP:0, SP:0 HP:0 #P:16) #- #| task: user-task-0 (uid:1000 nice:0 policy:0 rt_prio:0) #- # => started at: interrupt_entry # => ended at: swapgs_restore_regs_and_return_to_usermode # # # _--=> CPU# # / _-=> irqs-off #| / _=> need-resched #|| / _---=> hardirq/softirq #||| / _--=> preempt-depth # / delay # cmd pid | time | caller # \ / | \| / user-task-06d...0us : trace_hardirqs_off_thunk <-interrupt_entry user-task-06d...0us : do_IRQ <-ret_from_intr user-task-06d...0us : irq_enter <-do_IRQ user-task-06d...0us : rcu_irq_enter <-irq_enter user-task-06d...0us : irqtime_account_irq <-irq_enter user-task-06d.h.1us : handle_edge_irq <-do_IRQ user-task-06d.h.1us : _raw_spin_lock <-handle_edge_irq user-task-06d.h.1us : irq_may_run <-handle_edge_irq user-task-06d.h.1us : irq_chip_ack_parent <-handle_edge_irq user-task-06d.h.1us : apic_ack_irq <-handle_edge_irq user-task-06d.h.1us : handle_irq_event <-handle_edge_irq user-task-06d.h.1us : handle_irq_event_percpu <-handle_irq_event user-task-06d.h.1us : __handle_irq_event_percpu <-handle_irq_event_percpu user-task-06d.h.1us : amdgpu_irq_handler <-__handle_irq_event_percpu user-task-06d.h.2us : amdgpu_ih_process <-amdgpu_irq_handler user-task-06d.h.2us : tonga_ih_get_wptr <-amdgpu_ih_process user-task-06d.h.2us : __drm_dbg <-amdgpu_ih_process user-task-06d.h.2us : amdgpu_irq_dispatch <-amdgpu_ih_process user-task-06d.h.2us : tonga_ih_decode_iv <-amdgpu_irq_dispatch user-task-06d.h.3us : amdgpu_dm_irq_handler <-amdgpu_irq_dispatch user-task-06d.h.3us : dc_interrupt_to_irq_source <-amdgpu_dm_irq_handler user-task-06d.h.3us : dal_irq_service_to_irq_source <-amdgpu_dm_irq_handler user-task-06d.h.4us : to_dal_irq_source_dce110 <-amdgpu_dm_irq_handler user-task-06d.h.4us : dc_interrupt_ack <-amdgpu_dm_irq_handler user-task-06d.h.5us : dal_irq_service_ack <-amdgpu_dm_irq_handler user-task-06d.h.5us : dal_irq_service_ack_generic <-dal_irq_service_ack user-task-06d.h.5us : dm_read_reg_func <-dal_irq_service_ack_generic user-task-06d.h.5us : amdgpu_cgs_read_register <-dm_read_reg_func user-task-06d.h.6us : amdgpu_mm_rreg <-dm_read_reg_func user-task-06d.h.7us : amdgpu_cgs_write_register <-dal_irq_service_ack_generic user-task-06d.h.7us : amdgpu_mm_wreg <-dal_irq_service_ack_generic user-task-06d.h.7us : _raw_spin_lock_irqsave <-amdgpu_dm_irq_handler user-task-06d.h.8us : dm_crtc_high_irq <-amdgpu_dm_irq_handler user-task-06d.h.8us : get_crtc_by_otg_inst.isra.0 <-dm_crtc_high_irq user-task-06d.h.8us : __drm_dbg <-dm_crtc_high_irq user-task-06d.h.8us : drm_crtc_handle_vblank <-dm_crtc_high_irq user-task-06d.h.9us : drm_handle_vblank <-dm_crtc_high_irq user-task-06d.h.9us : _raw_spin_lock_irqsave <-drm_handle_vblank user-task-06d.h.9us : _raw_spin_lock <-drm_handle_vblank user-task-06d.h.9us : drm_update_vblank_count <-drm_handle_vblank user-task-06d.h.9us : __get_vblank_counter <-drm_update_vblank_count user-task-06d.h. 10us : drm_crtc_from_index <-__get_vblank_counter
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hi Tejun, Can you elaborate more on what are the missing pieces? Regards, Kenny On Tue, Mar 24, 2020 at 2:46 PM Tejun Heo wrote: > > On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote: > > What's your thoughts on this latest series? > > My overall impression is that the feedbacks aren't being incorporated > throughly > / sufficiently. > > Thanks. > > -- > tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
On Tue, Mar 17, 2020 at 12:03:20PM -0400, Kenny Ho wrote: > What's your thoughts on this latest series? My overall impression is that the feedbacks aren't being incorporated throughly / sufficiently. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Tue, Mar 24, 2020 at 06:31:08PM +0100, Karol Herbst wrote: > On Sat, Mar 21, 2020 at 2:02 AM Karol Herbst wrote: > > > > On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote: > > > > > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote: > > > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops > > > > with > > > > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU. > > > > > > > > Depending on the used kernel there might be messages like those in > > > > demsg: > > > > > > > > "nouveau :01:00.0: Refused to change power state, currently in D3" > > > > "nouveau :01:00.0: can't change power state from D3cold to D0 > > > > (config > > > > space inaccessible)" > > > > followed by backtraces of kernel crashes or timeouts within nouveau. > > > > > > > > It's still unkown why this issue exists, but this is a reliable > > > > workaround > > > > and solves a very annoying issue for user having to choose between a > > > > crashing kernel or higher power consumption of their Laptops. > > > > > > Thanks for the bugzilla link. The bugzilla mentions lots of mailing > > > list discussion. Can you include links to some of that? > > > > > > IIUC this basically just turns off PCI power management for the GPU. > > > Can you do that with something like the following? I don't know > > > anything about DRM, so I don't know where you could save the pm_cap, > > > but I'm sure the driver could keep it somewhere. > > > > > > > Sure this would work? From a quick look over the pci code, it looks > > like a of code would be skipped we really need, like the platform code > > to turn off the GPU via ACPI. But I could also remember incorrectly on > > how all of that worked again. I can of course try and see what the > > effect of this patch would be. And would the parent bus even go into > > D3hot if it knows one of its children is still at D0? Because that's > > what the result of that would be as well, no? And I know that if the > > bus stays in D0, that it has a negative impact on power consumption. > > > > Anyway, I will try that out, I am just not seeing how that would help. > > so it seems like that has worked unless I screwed up locally. Will do > some proper testing and then I think we won't need to go through the > pci tree anymore as no changes are required there with that. Hehe, looks like our responses crossed in the mail :) I hope further testing is still positive; let me know if not. Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Sat, Mar 21, 2020 at 02:02:22AM +0100, Karol Herbst wrote:
> On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote:
> >
> > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> > > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
> > >
> > > Depending on the used kernel there might be messages like those in demsg:
> > >
> > > "nouveau :01:00.0: Refused to change power state, currently in D3"
> > > "nouveau :01:00.0: can't change power state from D3cold to D0 (config
> > > space inaccessible)"
> > > followed by backtraces of kernel crashes or timeouts within nouveau.
> > >
> > > It's still unkown why this issue exists, but this is a reliable workaround
> > > and solves a very annoying issue for user having to choose between a
> > > crashing kernel or higher power consumption of their Laptops.
> >
> > Thanks for the bugzilla link. The bugzilla mentions lots of mailing
> > list discussion. Can you include links to some of that?
> >
> > IIUC this basically just turns off PCI power management for the GPU.
> > Can you do that with something like the following? I don't know
> > anything about DRM, so I don't know where you could save the pm_cap,
> > but I'm sure the driver could keep it somewhere.
>
> Sure this would work? From a quick look over the pci code, it looks
> like a of code would be skipped we really need, like the platform
> code to turn off the GPU via ACPI. But I could also remember
> incorrectly on how all of that worked again. I can of course try and
> see what the effect of this patch would be.
I'm not in a position to test this myself. I would expect that if a
device lacks a PCI power management capability, we could still use
ACPI power management. My idea with this patch was to simulate that
situation by clearing pdev->pm_cap so we treat the GPU as though it
had no PCI PM capability.
> And would the parent bus even go into D3hot if it knows one of its
> children is still at D0? Because that's what the result of that
> would be as well, no? And I know that if the bus stays in D0, that
> it has a negative impact on power consumption.
I don't understand this part. Are you saying you want the GPU in D0
and the upstream component (root port or switch) in D3hot?
I think the rule for the upstream component (the root port or switch
leading to the GPU) is in PCIe spec 5.0, sec 5.3.2. Basically it says
the upstream component cannot be in a lower power state than the GPU,
i.e.,
- if the GPU is in D0, the upstream component must be in D0;
- if the GPU is in D2, the upstream component can be in D0-D2;
- if the GPU is in D3hot, the upstream component can be in D0-D3hot
So I don't understand how we *could* have the GPU in D0 and the
upstream component in D3hot.
> Anyway, I will try that out, I am just not seeing how that would help.
>
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index b65ae817eabf..2ad825e8891c 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -618,6 +618,23 @@ nouveau_drm_device_fini(struct drm_device *dev)
> > kfree(drm);
> > }
> >
> > +static void quirk_broken_nv_runpm(struct drm_device *drm_dev)
> > +{
> > + struct pci_dev *pdev = drm_dev->pdev;
> > + struct pci_dev *bridge = pci_upstream_bridge(pdev);
> > +
> > + if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
> > + return;
> > +
> > + switch (bridge->device) {
> > + case 0x1901:
> > + STASH->pm_cap = pdev->pm_cap;
> > + pdev->pm_cap = 0;
> > + NV_INFO(drm_dev, "Disabling PCI power management to avoid
> > bug\n");
> > + break;
> > + }
> > +}
> > +
> > static int nouveau_drm_probe(struct pci_dev *pdev,
> > const struct pci_device_id *pent)
> > {
> > @@ -699,6 +716,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> > if (ret)
> > goto fail_drm_dev_init;
> >
> > + quirk_broken_nv_runpm(drm_dev);
> > return 0;
> >
> > fail_drm_dev_init:
> > @@ -735,6 +753,9 @@ nouveau_drm_remove(struct pci_dev *pdev)
> > {
> > struct drm_device *dev = pci_get_drvdata(pdev);
> >
> > + /* If we disabled PCI power management, restore it */
> > + if (STASH->pm_cap)
> > + pdev->pm_cap = STASH->pm_cap;
> > nouveau_drm_device_remove(dev);
> > pci_disable_device(pdev);
> > }
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Sat, Mar 21, 2020 at 2:02 AM Karol Herbst wrote:
>
> On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote:
> >
> > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> > > Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> > > Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
> > >
> > > Depending on the used kernel there might be messages like those in demsg:
> > >
> > > "nouveau :01:00.0: Refused to change power state, currently in D3"
> > > "nouveau :01:00.0: can't change power state from D3cold to D0 (config
> > > space inaccessible)"
> > > followed by backtraces of kernel crashes or timeouts within nouveau.
> > >
> > > It's still unkown why this issue exists, but this is a reliable workaround
> > > and solves a very annoying issue for user having to choose between a
> > > crashing kernel or higher power consumption of their Laptops.
> >
> > Thanks for the bugzilla link. The bugzilla mentions lots of mailing
> > list discussion. Can you include links to some of that?
> >
> > IIUC this basically just turns off PCI power management for the GPU.
> > Can you do that with something like the following? I don't know
> > anything about DRM, so I don't know where you could save the pm_cap,
> > but I'm sure the driver could keep it somewhere.
> >
>
> Sure this would work? From a quick look over the pci code, it looks
> like a of code would be skipped we really need, like the platform code
> to turn off the GPU via ACPI. But I could also remember incorrectly on
> how all of that worked again. I can of course try and see what the
> effect of this patch would be. And would the parent bus even go into
> D3hot if it knows one of its children is still at D0? Because that's
> what the result of that would be as well, no? And I know that if the
> bus stays in D0, that it has a negative impact on power consumption.
>
> Anyway, I will try that out, I am just not seeing how that would help.
>
so it seems like that has worked unless I screwed up locally. Will do
some proper testing and then I think we won't need to go through the
pci tree anymore as no changes are required there with that.
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index b65ae817eabf..2ad825e8891c 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -618,6 +618,23 @@ nouveau_drm_device_fini(struct drm_device *dev)
> > kfree(drm);
> > }
> >
> > +static void quirk_broken_nv_runpm(struct drm_device *drm_dev)
> > +{
> > + struct pci_dev *pdev = drm_dev->pdev;
> > + struct pci_dev *bridge = pci_upstream_bridge(pdev);
> > +
> > + if (!bridge || bridge->vendor != PCI_VENDOR_ID_INTEL)
> > + return;
> > +
> > + switch (bridge->device) {
> > + case 0x1901:
> > + STASH->pm_cap = pdev->pm_cap;
> > + pdev->pm_cap = 0;
> > + NV_INFO(drm_dev, "Disabling PCI power management to avoid
> > bug\n");
> > + break;
> > + }
> > +}
> > +
> > static int nouveau_drm_probe(struct pci_dev *pdev,
> > const struct pci_device_id *pent)
> > {
> > @@ -699,6 +716,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
> > if (ret)
> > goto fail_drm_dev_init;
> >
> > + quirk_broken_nv_runpm(drm_dev);
> > return 0;
> >
> > fail_drm_dev_init:
> > @@ -735,6 +753,9 @@ nouveau_drm_remove(struct pci_dev *pdev)
> > {
> > struct drm_device *dev = pci_get_drvdata(pdev);
> >
> > + /* If we disabled PCI power management, restore it */
> > + if (STASH->pm_cap)
> > + pdev->pm_cap = STASH->pm_cap;
> > nouveau_drm_device_remove(dev);
> > pci_disable_device(pdev);
> > }
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
On Tue, Mar 24, 2020 at 1:49 AM Masahiro Yamada wrote: > > If it is OK to queue this up to Kbuild tree, > I will send a pull request to Linus. Looks fine to me, assuming we didn't now get some confusion due to duplicate patches (I think Jason got his tree added to -next already). And yeah, that end result looks much better. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/radeon: remove unneeded header include path
Hi, I think this series is a good clean-up. Could you take a look at this please? On Fri, Feb 14, 2020 at 12:40 AM Masahiro Yamada wrote: > > A header include path without $(srctree)/ is suspicious because it does > not work with O= builds. > > You can build drivers/gpu/drm/radeon/ without this include path. > > Signed-off-by: Masahiro Yamada > --- > > drivers/gpu/drm/radeon/Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile > index c693b2ca0329..9d5d3dc1011f 100644 > --- a/drivers/gpu/drm/radeon/Makefile > +++ b/drivers/gpu/drm/radeon/Makefile > @@ -3,8 +3,6 @@ > # Makefile for the drm device driver. This driver provides support for the > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > -ccflags-y := -Idrivers/gpu/drm/amd/include > - > hostprogs := mkregtable > clean-files := rn50_reg_safe.h r100_reg_safe.h r200_reg_safe.h > rv515_reg_safe.h r300_reg_safe.h r420_reg_safe.h rs600_reg_safe.h > r600_reg_safe.h evergreen_reg_safe.h cayman_reg_safe.h > > -- > 2.17.1 > -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 23 March 2020 20:18
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: Lattannavar, Sameer ;
> > jani.nik...@linux.intel.com; dan...@ffwll.ch;
> > intel-...@lists.freedesktop.org;
> > dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > ; Vivi, Rodrigo ;
> > David Airlie ; Chris Wilson ;
> > Maarten Lankhorst ; Souza, Jose
> > ; Deak, Imre ; Shankar, Uma
> >
> > Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and
> > CRTC
> >
> > On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > > GEN >= 10 hardware supports the programmable scaler filter.
> > >
> > > Attach scaling filter property for CRTC and plane for GEN >= 10
> > > hardwares and program scaler filter based on the selected filter type.
> > >
> > > changes since v1:
> > > * None
> > > Changes since RFC:
> > > * Enable properties for GEN >= 10 platforms (Ville)
> > > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > > * Add new functions to handle scaling filter setup (Ville)
> > > * Remove coefficient set 0 hardcoding.
> > >
> > > Signed-off-by: Shashank Sharma
> > > Signed-off-by: Ankit Nautiyal
> > > Signed-off-by: Pankaj Bharadiya
> > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 32
> > > ++-- drivers/gpu/drm/i915/display/intel_sprite.c |
> > > 31 ++-
> > > 2 files changed, 60 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 791dd908aa89..4b3387ee332e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -6309,6 +6309,25 @@ void
> > skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private *dev_priv,
> > > }
> > > }
> > >
> > > +static u32
> > > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe
> > pipe,
> > > + int id, int set, enum drm_crtc_scaling_filter filter)
> > > {
> > > + u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > > +
> > > + if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > > + skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
> > > + set);
> > > + scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > > + PS_UV_VERT_FILTER_SELECT(set) |
> > > + PS_UV_HORZ_FILTER_SELECT(set) |
> > > + PS_Y_VERT_FILTER_SELECT(set) |
> > > + PS_Y_HORZ_FILTER_SELECT(set);
> > > +
> > > + }
> > > + return scaler_filter_ctl;
> >
> > This function does too many things.
>
> I was thinking to have a common function which configures the filter and also
> provides the register bits (ps_ctrl) to select a desired filter so that we
> need
> not have extra condition to figure out filter select register bits where this
> function is being called.
> How about renaming this function to some better name like
> skl_scaler_set_and_get_filter_select() or something else?
> Or shall I breakdown this function into multiple functions?
I'd just inline the PS_CTRL stuff into the current function.
>
> Any suggestions?
>
> >
> > > +}
> > > +
> > > static void skl_pfit_enable(const struct intel_crtc_state
> > > *crtc_state) {
> > > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > @@ -6316,12 +6335,14 @@ static void skl_pfit_enable(const struct
> > intel_crtc_state *crtc_state)
> > > enum pipe pipe = crtc->pipe;
> > > const struct intel_crtc_scaler_state *scaler_state =
> > > _state->scaler_state;
> > > + const struct drm_crtc_state *state = _state->uapi;
> >
> > Pls don't add this kind of aliases. We're moving away from using the drm_
> > types
> > as much as possible.
>
> OK.
>
> >
> > >
> > > if (crtc_state->pch_pfit.enabled) {
> > > u16 uv_rgb_hphase, uv_rgb_vphase;
> > > int pfit_w, pfit_h, hscale, vscale;
> > > unsigned long irqflags;
> > > int id;
> > > + int scaler_filter_ctl;
> >
> > It's a register value so u32. I'd also
>
> Yes, I missed it. Thanks for pointing out.
>
> > s/scaler_filter_ctl/filter_select/ or something like that.
> >
> > Alternatively we could just call it ps_ctrl and have it contain the full
> > register
> > value for that particular register.
>
> ps_ctrl sounds better, will use this name.
>
> >
> > >
> > > if (drm_WARN_ON(_priv->drm,
> > > crtc_state->scaler_state.scaler_id < 0)) @@ -
> > 6340,8 +6361,12 @@
> > > static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
> > >
> > > spin_lock_irqsave(_priv->uncore.lock, irqflags);
> > >
> > > - intel_de_write_fw(dev_priv,
[PATCH 2/3] drm/virtio: delete notify after virtio_gpu_cmd_context_create
The first 3D ioctl will take care of notification. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 336cc9143205..867c5e239d55 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -47,7 +47,6 @@ static void virtio_gpu_create_context(struct drm_device *dev, get_task_comm(dbgname, current); virtio_gpu_cmd_context_create(vgdev, vfpriv->ctx_id, strlen(dbgname), dbgname); - virtio_gpu_notify(vgdev); vfpriv->context_created = true; out_unlock: -- 2.25.1.696.g5e7596f4ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/virtio: delete notify in virtio_gpu_object_create
- For dumb buffers, virtio_gpu_gem_create can notify. - For 3D buffers, virtio_gpu_gem_object_open can notify. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_gem.c| 1 + drivers/gpu/drm/virtio/virtgpu_object.c | 1 - 2 files changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 90c0a8ea1708..aa14dd12928e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -49,6 +49,7 @@ static int virtio_gpu_gem_create(struct drm_file *file, return ret; } + virtio_gpu_notify(vgdev); *obj_p = >base.base; /* drop reference from allocate - handle holds it now */ diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index d9039bb7c5e3..51a8da7d5ef3 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, return ret; } - virtio_gpu_notify(vgdev); *bo_ptr = bo; return 0; -- 2.25.1.696.g5e7596f4ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] drm/i915: Introduce scaling filter related registers and bit fields.
On Tue, Mar 24, 2020 at 02:36:10PM +, Laxminarayan Bharadiya, Pankaj wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: 23 March 2020 20:09
> > To: Laxminarayan Bharadiya, Pankaj
> >
> > Cc: Lattannavar, Sameer ;
> > jani.nik...@linux.intel.com; dan...@ffwll.ch;
> > intel-...@lists.freedesktop.org;
> > dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> > ; Vivi, Rodrigo ;
> > David Airlie
> > Subject: Re: [PATCH v2 3/5] drm/i915: Introduce scaling filter related
> > registers
> > and bit fields.
> >
> > On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> > > Introduce scaler registers and bit fields needed to configure the
> > > scaling filter in prgrammed mode and configure scaling filter
> > > coefficients.
> > >
> > > changes since v1:
> > > * None
> > > changes since RFC:
> > > * Parametrize scaler coeffient macros by 'set' (Ville)
> > >
> > > Signed-off-by: Shashank Sharma
> > > Signed-off-by: Ankit Nautiyal
> > > Signed-off-by: Pankaj Bharadiya
> > >
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 48
> > > +
> > > 1 file changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 9c53fe918be6..d40f12d2a6b5
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7205,6 +7205,7 @@ enum {
> > > #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> > > #define PS_FILTER_MASK (3 << 23)
> > > #define PS_FILTER_MEDIUM (0 << 23)
> > > +#define PS_FILTER_PROGRAMMED (1 << 23)
> > > #define PS_FILTER_EDGE_ENHANCE (2 << 23)
> > > #define PS_FILTER_BILINEAR (3 << 23)
> > > #define PS_VERT3TAP(1 << 21)
> > > @@ -7219,6 +7220,10 @@ enum {
> > > #define PS_VADAPT_MODE_MOST_ADAPT (3 << 5) #define
> > > PS_PLANE_Y_SEL_MASK (7 << 5) #define PS_PLANE_Y_SEL(plane) (((plane)
> > > + 1) << 5)
> > > +#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
> > > +#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
> > > +#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2) #define
> > > +PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
> > >
> > > #define _PS_PWR_GATE_1A 0x68160
> > > #define _PS_PWR_GATE_2A 0x68260
> > > @@ -7281,6 +7286,25 @@ enum {
> > > #define _PS_ECC_STAT_2B 0x68AD0
> > > #define _PS_ECC_STAT_1C 0x691D0
> > >
> > > +#define _PS_COEF_SET0_INDEX_1A 0x68198
> > > +#define _PS_COEF_SET0_INDEX_2A 0x68298
> > > +#define _PS_COEF_SET0_INDEX_1B 0x68998
> > > +#define _PS_COEF_SET0_INDEX_2B 0x68A98
> > > +#define _PS_COEF_SET1_INDEX_1A 0x681A0
> > > +#define _PS_COEF_SET1_INDEX_2A 0x682A0
> > > +#define _PS_COEF_SET1_INDEX_1B 0x689A0
> > > +#define _PS_COEF_SET1_INDEX_2B 0x68AA0
> > > +#define PS_COEE_INDEX_AUTO_INC (1 << 10)
> > > +
> > > +#define _PS_COEF_SET0_DATA_1A 0x6819C
> > > +#define _PS_COEF_SET0_DATA_2A 0x6829C
> > > +#define _PS_COEF_SET0_DATA_1B 0x6899C
> > > +#define _PS_COEF_SET0_DATA_2B 0x68A9C
> > > +#define _PS_COEF_SET1_DATA_1A 0x681A4
> > > +#define _PS_COEF_SET1_DATA_2A 0x682A4
> > > +#define _PS_COEF_SET1_DATA_1B 0x689A4
> > > +#define _PS_COEF_SET1_DATA_2B 0x68AA4
> > > +
> > > #define _ID(id, a, b) _PICK_EVEN(id, a, b)
> > > #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
> > > _ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
> > > @@ -7310,6 +7334,30 @@ enum {
> > > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> > > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> > >
> > > +#define _SKL_PS_COEF_INDEX_SET0(pipe, id) _ID(pipe,\
> > > + _ID(id, _PS_COEF_SET0_INDEX_1A,
> > _PS_COEF_SET0_INDEX_2A), \
> > > + _ID(id, _PS_COEF_SET0_INDEX_1B,
> > _PS_COEF_SET0_INDEX_2B))
> > > +
> > > +#define _SKL_PS_COEF_INDEX_SET1(pipe, id) _ID(pipe,\
> > > + _ID(id, _PS_COEF_SET1_INDEX_1A,
> > _PS_COEF_SET1_INDEX_2A), \
> > > + _ID(id, _PS_COEF_SET1_INDEX_1B,
> > _PS_COEF_SET1_INDEX_2B))
> > > +
> > > +#define _SKL_PS_COEF_DATA_SET0(pipe, id) _ID(pipe, \
> > > + _ID(id, _PS_COEF_SET0_DATA_1A,
> > _PS_COEF_SET0_DATA_2A), \
> > > + _ID(id, _PS_COEF_SET0_DATA_1B,
> > _PS_COEF_SET0_DATA_2B))
> > > +
> > > +#define _SKL_PS_COEF_DATA_SET1(pipe, id) _ID(pipe, \
> > > + _ID(id, _PS_COEF_SET1_DATA_1A,
> > _PS_COEF_SET1_DATA_2A), \
> > > + _ID(id, _PS_COEF_SET1_DATA_1B,
> > _PS_COEF_SET1_DATA_2B))
> > > +
> > > +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \
> > > + _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id),
> > \
> > > + _SKL_PS_COEF_INDEX_SET1(pipe, id))
> > > +
> > > +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \
> > > + _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id),
> > \
>
[PATCH 1/3] drm/virtio: random virtgpu_drv.h cleanups
- Static-ify virtio_gpu_gem_create
- Delete unused prototypes
- Point to current implementation files
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 26 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 10 +-
2 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 824f9f15926c..79ad176aca5a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -218,26 +218,18 @@ struct virtio_gpu_fpriv {
struct mutex context_lock;
};
-/* virtio_ioctl.c */
+/* virtgpu_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
-/* virtio_kms.c */
+/* virtgpu_kms.c */
int virtio_gpu_init(struct drm_device *dev);
void virtio_gpu_deinit(struct drm_device *dev);
void virtio_gpu_release(struct drm_device *dev);
int virtio_gpu_driver_open(struct drm_device *dev, struct drm_file *file);
void virtio_gpu_driver_postclose(struct drm_device *dev, struct drm_file
*file);
-/* virtio_gem.c */
-void virtio_gpu_gem_free_object(struct drm_gem_object *gem_obj);
-int virtio_gpu_gem_init(struct virtio_gpu_device *vgdev);
-void virtio_gpu_gem_fini(struct virtio_gpu_device *vgdev);
-int virtio_gpu_gem_create(struct drm_file *file,
- struct drm_device *dev,
- struct virtio_gpu_object_params *params,
- struct drm_gem_object **obj_p,
- uint32_t *handle_p);
+/* virtgpu_gem.c */
int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
struct drm_file *file);
void virtio_gpu_gem_object_close(struct drm_gem_object *obj,
@@ -263,7 +255,7 @@ void virtio_gpu_array_put_free_delayed(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object_array *objs);
void virtio_gpu_array_put_free_work(struct work_struct *work);
-/* virtio vg */
+/* virtgpu_vq.c */
int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev);
void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev);
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
@@ -343,17 +335,17 @@ void virtio_gpu_dequeue_fence_func(struct work_struct
*work);
void virtio_gpu_notify(struct virtio_gpu_device *vgdev);
-/* virtio_gpu_display.c */
+/* virtgpu_display.c */
void virtio_gpu_modeset_init(struct virtio_gpu_device *vgdev);
void virtio_gpu_modeset_fini(struct virtio_gpu_device *vgdev);
-/* virtio_gpu_plane.c */
+/* virtgpu_plane.c */
uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc);
struct drm_plane *virtio_gpu_plane_init(struct virtio_gpu_device *vgdev,
enum drm_plane_type type,
int index);
-/* virtio_gpu_fence.c */
+/* virtgpu_fence.c */
struct virtio_gpu_fence *virtio_gpu_fence_alloc(
struct virtio_gpu_device *vgdev);
void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
@@ -362,7 +354,7 @@ void virtio_gpu_fence_emit(struct virtio_gpu_device *vgdev,
void virtio_gpu_fence_event_process(struct virtio_gpu_device *vdev,
u64 last_seq);
-/* virtio_gpu_object */
+/* virtgpu_object.c */
void virtio_gpu_cleanup_object(struct virtio_gpu_object *bo);
struct drm_gem_object *virtio_gpu_create_object(struct drm_device *dev,
size_t size);
@@ -378,7 +370,7 @@ struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
struct drm_device *dev, struct dma_buf_attachment *attach,
struct sg_table *sgt);
-/* virgl debugfs */
+/* virtgpu_debugfs.c */
void virtio_gpu_debugfs_init(struct drm_minor *minor);
#endif
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 0d6152c99a27..90c0a8ea1708 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -28,11 +28,11 @@
#include "virtgpu_drv.h"
-int virtio_gpu_gem_create(struct drm_file *file,
- struct drm_device *dev,
- struct virtio_gpu_object_params *params,
- struct drm_gem_object **obj_p,
- uint32_t *handle_p)
+static int virtio_gpu_gem_create(struct drm_file *file,
+struct drm_device *dev,
+struct virtio_gpu_object_params *params,
+struct drm_gem_object **obj_p,
+uint32_t *handle_p)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_object *obj;
--
2.25.1.696.g5e7596f4ac-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
> -Original Message-
> From: Ville Syrjälä
> Sent: 23 March 2020 20:18
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie ; Chris Wilson ;
> Maarten Lankhorst ; Souza, Jose
> ; Deak, Imre ; Shankar, Uma
>
> Subject: Re: [PATCH v2 5/5] drm/i915: Enable scaling filter for plane and CRTC
>
> On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> > GEN >= 10 hardware supports the programmable scaler filter.
> >
> > Attach scaling filter property for CRTC and plane for GEN >= 10
> > hardwares and program scaler filter based on the selected filter type.
> >
> > changes since v1:
> > * None
> > Changes since RFC:
> > * Enable properties for GEN >= 10 platforms (Ville)
> > * Do not round off the crtc co-ordinate (Danial Stone, Ville)
> > * Add new functions to handle scaling filter setup (Ville)
> > * Remove coefficient set 0 hardcoding.
> >
> > Signed-off-by: Shashank Sharma
> > Signed-off-by: Ankit Nautiyal
> > Signed-off-by: Pankaj Bharadiya
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 32
> > ++-- drivers/gpu/drm/i915/display/intel_sprite.c |
> > 31 ++-
> > 2 files changed, 60 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 791dd908aa89..4b3387ee332e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -6309,6 +6309,25 @@ void
> skl_scaler_setup_nearest_neighbor_filter(struct drm_i915_private *dev_priv,
> > }
> > }
> >
> > +static u32
> > +skl_scaler_crtc_setup_filter(struct drm_i915_private *dev_priv, enum pipe
> pipe,
> > + int id, int set, enum drm_crtc_scaling_filter filter)
> > {
> > + u32 scaler_filter_ctl = PS_FILTER_MEDIUM;
> > +
> > + if (filter == DRM_CRTC_SCALING_FILTER_NEAREST_NEIGHBOR) {
> > + skl_scaler_setup_nearest_neighbor_filter(dev_priv, pipe, id,
> > +set);
> > + scaler_filter_ctl = PS_FILTER_PROGRAMMED |
> > + PS_UV_VERT_FILTER_SELECT(set) |
> > + PS_UV_HORZ_FILTER_SELECT(set) |
> > + PS_Y_VERT_FILTER_SELECT(set) |
> > + PS_Y_HORZ_FILTER_SELECT(set);
> > +
> > + }
> > + return scaler_filter_ctl;
>
> This function does too many things.
I was thinking to have a common function which configures the filter and also
provides the register bits (ps_ctrl) to select a desired filter so that we need
not have extra condition to figure out filter select register bits where this
function is being called.
How about renaming this function to some better name like
skl_scaler_set_and_get_filter_select() or something else?
Or shall I breakdown this function into multiple functions?
Any suggestions?
>
> > +}
> > +
> > static void skl_pfit_enable(const struct intel_crtc_state
> > *crtc_state) {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -6316,12 +6335,14 @@ static void skl_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> > enum pipe pipe = crtc->pipe;
> > const struct intel_crtc_scaler_state *scaler_state =
> > _state->scaler_state;
> > + const struct drm_crtc_state *state = _state->uapi;
>
> Pls don't add this kind of aliases. We're moving away from using the drm_
> types
> as much as possible.
OK.
>
> >
> > if (crtc_state->pch_pfit.enabled) {
> > u16 uv_rgb_hphase, uv_rgb_vphase;
> > int pfit_w, pfit_h, hscale, vscale;
> > unsigned long irqflags;
> > int id;
> > + int scaler_filter_ctl;
>
> It's a register value so u32. I'd also
Yes, I missed it. Thanks for pointing out.
> s/scaler_filter_ctl/filter_select/ or something like that.
>
> Alternatively we could just call it ps_ctrl and have it contain the full
> register
> value for that particular register.
ps_ctrl sounds better, will use this name.
>
> >
> > if (drm_WARN_ON(_priv->drm,
> > crtc_state->scaler_state.scaler_id < 0)) @@ -
> 6340,8 +6361,12 @@
> > static void skl_pfit_enable(const struct intel_crtc_state *crtc_state)
> >
> > spin_lock_irqsave(_priv->uncore.lock, irqflags);
> >
> > - intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id),
> PS_SCALER_EN |
> > - PS_FILTER_MEDIUM | scaler_state-
> >scalers[id].mode);
> > + scaler_filter_ctl =
> > + skl_scaler_crtc_setup_filter(dev_priv, pipe, id, 0,
> > + state->scaling_filter);
> > + intel_de_write_fw(dev_priv,
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
On Tue, Mar 24, 2020 at 02:24:41PM +, Lee Jones wrote: > On Tue, 24 Mar 2020, Daniel Thompson wrote: > > > On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote: > > > Hello Lee, > > > > > > On Tue, Mar 24, 2020 at 11:07:10AM +, Lee Jones wrote: > > > > On Fri, 20 Mar 2020, Lee Jones wrote: > > > > > > > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > > > > > > > > > > > Since the PWM framework is switching struct pwm_state.period's > > > > > > datatype > > > > > > to u64, prepare for this transition by using div_u64 to handle a > > > > > > 64-bit > > > > > > dividend instead of a straight division operation. > > > > > > > > > > > > Cc: Lee Jones > > > > > > Cc: Daniel Thompson > > > > > > Cc: Jingoo Han > > > > > > Cc: Bartlomiej Zolnierkiewicz > > > > > > Cc: linux-...@vger.kernel.org > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > Cc: linux-fb...@vger.kernel.org > > > > > > > > > > > > Signed-off-by: Guru Das Srinagesh > > > > > > Reviewed-by: Daniel Thompson > > > > > > --- > > > > > > drivers/video/backlight/pwm_bl.c | 3 ++- > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > Can this patch be taken on its own? > > > > > > > > Hello ... > > > > > > Conceptually it can. As the last patch depends on this one (and the > > > others) some coordination might be beneficial. But that's up to Thierry > > > to decide how (and if) he want this series to be applied. > > > > ... and on the backlight side we definitely need to know about the "if" > > otherwise there's no point in taking it. > > Right. > > I'm happy to wait for Thierry. Although this isn't the only set he's > currently blocking. Is he okay? On holiday perhaps? The newest commit by him in next is from last week. My guess is he just didn't come around yet to care for the PWM duties. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 3/5] drm/i915: Introduce scaling filter related registers and bit fields.
> -Original Message-
> From: Ville Syrjälä
> Sent: 23 March 2020 20:09
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; dani...@collabora.com; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> David Airlie
> Subject: Re: [PATCH v2 3/5] drm/i915: Introduce scaling filter related
> registers
> and bit fields.
>
> On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> > Introduce scaler registers and bit fields needed to configure the
> > scaling filter in prgrammed mode and configure scaling filter
> > coefficients.
> >
> > changes since v1:
> > * None
> > changes since RFC:
> > * Parametrize scaler coeffient macros by 'set' (Ville)
> >
> > Signed-off-by: Shashank Sharma
> > Signed-off-by: Ankit Nautiyal
> > Signed-off-by: Pankaj Bharadiya
> >
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 48
> > +
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 9c53fe918be6..d40f12d2a6b5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7205,6 +7205,7 @@ enum {
> > #define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
> > #define PS_FILTER_MASK (3 << 23)
> > #define PS_FILTER_MEDIUM (0 << 23)
> > +#define PS_FILTER_PROGRAMMED (1 << 23)
> > #define PS_FILTER_EDGE_ENHANCE (2 << 23)
> > #define PS_FILTER_BILINEAR (3 << 23)
> > #define PS_VERT3TAP(1 << 21)
> > @@ -7219,6 +7220,10 @@ enum {
> > #define PS_VADAPT_MODE_MOST_ADAPT (3 << 5) #define
> > PS_PLANE_Y_SEL_MASK (7 << 5) #define PS_PLANE_Y_SEL(plane) (((plane)
> > + 1) << 5)
> > +#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
> > +#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
> > +#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2) #define
> > +PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
> >
> > #define _PS_PWR_GATE_1A 0x68160
> > #define _PS_PWR_GATE_2A 0x68260
> > @@ -7281,6 +7286,25 @@ enum {
> > #define _PS_ECC_STAT_2B 0x68AD0
> > #define _PS_ECC_STAT_1C 0x691D0
> >
> > +#define _PS_COEF_SET0_INDEX_1A0x68198
> > +#define _PS_COEF_SET0_INDEX_2A0x68298
> > +#define _PS_COEF_SET0_INDEX_1B0x68998
> > +#define _PS_COEF_SET0_INDEX_2B0x68A98
> > +#define _PS_COEF_SET1_INDEX_1A0x681A0
> > +#define _PS_COEF_SET1_INDEX_2A0x682A0
> > +#define _PS_COEF_SET1_INDEX_1B0x689A0
> > +#define _PS_COEF_SET1_INDEX_2B0x68AA0
> > +#define PS_COEE_INDEX_AUTO_INC(1 << 10)
> > +
> > +#define _PS_COEF_SET0_DATA_1A 0x6819C
> > +#define _PS_COEF_SET0_DATA_2A 0x6829C
> > +#define _PS_COEF_SET0_DATA_1B 0x6899C
> > +#define _PS_COEF_SET0_DATA_2B 0x68A9C
> > +#define _PS_COEF_SET1_DATA_1A 0x681A4
> > +#define _PS_COEF_SET1_DATA_2A 0x682A4
> > +#define _PS_COEF_SET1_DATA_1B 0x689A4
> > +#define _PS_COEF_SET1_DATA_2B 0x68AA4
> > +
> > #define _ID(id, a, b) _PICK_EVEN(id, a, b)
> > #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
> > _ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
> > @@ -7310,6 +7334,30 @@ enum {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >
> > +#define _SKL_PS_COEF_INDEX_SET0(pipe, id) _ID(pipe,\
> > + _ID(id, _PS_COEF_SET0_INDEX_1A,
> _PS_COEF_SET0_INDEX_2A), \
> > + _ID(id, _PS_COEF_SET0_INDEX_1B,
> _PS_COEF_SET0_INDEX_2B))
> > +
> > +#define _SKL_PS_COEF_INDEX_SET1(pipe, id) _ID(pipe,\
> > + _ID(id, _PS_COEF_SET1_INDEX_1A,
> _PS_COEF_SET1_INDEX_2A), \
> > + _ID(id, _PS_COEF_SET1_INDEX_1B,
> _PS_COEF_SET1_INDEX_2B))
> > +
> > +#define _SKL_PS_COEF_DATA_SET0(pipe, id) _ID(pipe, \
> > + _ID(id, _PS_COEF_SET0_DATA_1A,
> _PS_COEF_SET0_DATA_2A), \
> > + _ID(id, _PS_COEF_SET0_DATA_1B,
> _PS_COEF_SET0_DATA_2B))
> > +
> > +#define _SKL_PS_COEF_DATA_SET1(pipe, id) _ID(pipe, \
> > + _ID(id, _PS_COEF_SET1_DATA_1A,
> _PS_COEF_SET1_DATA_2A), \
> > + _ID(id, _PS_COEF_SET1_DATA_1B,
> _PS_COEF_SET1_DATA_2B))
> > +
> > +#define SKL_PS_COEF_INDEX_SET(pipe, id, set) \
> > + _MMIO_PIPE(set, _SKL_PS_COEF_INDEX_SET0(pipe, id),
> \
> > + _SKL_PS_COEF_INDEX_SET1(pipe, id))
> > +
> > +#define SKL_PS_COEF_DATA_SET(pipe, id, set) \
> > + _MMIO_PIPE(set, _SKL_PS_COEF_DATA_SET0(pipe, id),
> \
> > + _SKL_PS_COEF_DATA_SET1(pipe, id))
>
> I'd name those CNL_PS_COEF_{DATA,INDEX}(). Or maybe eeven GLK_ since it
> already has this despite not being officially supported.
All other existing scaler macros start will SKL_PS_*, adding new
Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
Hi, On Sun, Mar 22, 2020 at 11:14 PM Kalyan Thota wrote: > > "The PM core always increments the runtime usage counter > before calling the ->suspend() callback and decrements it > after calling the ->resume() callback" > > DPU and DSI are managed as runtime devices. When > suspend is triggered, PM core adds a refcount on all the > devices and calls device suspend, since usage count is > already incremented, runtime suspend was not getting called > and it kept the clocks on which resulted in target not > entering into XO shutdown. > > Add changes to manage runtime devices during pm sleep. > > Changes in v1: > - Remove unnecessary checks in the function > _dpu_kms_disable_dpu (Rob Clark). I'm wondering what happened with my feedback on v1, AKA: https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wm8mho8o7t5za1yosx7s...@mail.gmail.com Maybe you didn't see it? ...or if you or Rob think I'm way off base (always possible) then please tell me so. Thanks! -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
On 24/03/2020 15:20, Neil Armstrong wrote:
> Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
> a different superblock size for the Memory Saving mode.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_overlay.c | 14 --
> include/uapi/drm/drm_fourcc.h | 16 +++-
> 2 files changed, 27 insertions(+), 3 deletions(-)
>
[...]
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -840,6 +840,19 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC (1ULL << 0)
>
> +/*
> + * Amlogic FBC Scatter Memory layout
> + *
> + * Indicates the header contains IOMMU references to the compressed
> + * frames content to optimize memory access and layout.
> + *
> + * In this mode, only the header memory address is needed, thus the
> + * content memory organization is tied to the current producer
> + * execution and cannot be saved/dumped neither transferrable between
> + * Amlogic SoCs supporting this modifier.
> + */
> +#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER(2ULL << 0)
> +
> /*
> * Amlogic FBC Layout Options
> */
> @@ -852,7 +865,8 @@ extern "C" {
> * memory.
> *
> * This mode reduces body layout to 3072 bytes per 64x32 superblock with
> - * the basic layout.
> + * the basic layout and 3200 bytes per 64x32 superblock combined with
> + * the scatter layout.
> */
> #define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING(1ULL << 8)
>
>
Oops a commit got lost in the process... this change should be independent.
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
On Tue, 24 Mar 2020, Daniel Thompson wrote: > On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote: > > Hello Lee, > > > > On Tue, Mar 24, 2020 at 11:07:10AM +, Lee Jones wrote: > > > On Fri, 20 Mar 2020, Lee Jones wrote: > > > > > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > > > > > > > > > Since the PWM framework is switching struct pwm_state.period's > > > > > datatype > > > > > to u64, prepare for this transition by using div_u64 to handle a > > > > > 64-bit > > > > > dividend instead of a straight division operation. > > > > > > > > > > Cc: Lee Jones > > > > > Cc: Daniel Thompson > > > > > Cc: Jingoo Han > > > > > Cc: Bartlomiej Zolnierkiewicz > > > > > Cc: linux-...@vger.kernel.org > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Cc: linux-fb...@vger.kernel.org > > > > > > > > > > Signed-off-by: Guru Das Srinagesh > > > > > Reviewed-by: Daniel Thompson > > > > > --- > > > > > drivers/video/backlight/pwm_bl.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > Can this patch be taken on its own? > > > > > > Hello ... > > > > Conceptually it can. As the last patch depends on this one (and the > > others) some coordination might be beneficial. But that's up to Thierry > > to decide how (and if) he want this series to be applied. > > ... and on the backlight side we definitely need to know about the "if" > otherwise there's no point in taking it. Right. I'm happy to wait for Thierry. Although this isn't the only set he's currently blocking. Is he okay? On holiday perhaps? -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 1/5] drm: Introduce plane and CRTC scaling filter properties
> -Original Message-
> From: Ville Syrjälä
> Sent: 23 March 2020 19:52
> To: Laxminarayan Bharadiya, Pankaj
>
> Cc: Lattannavar, Sameer ;
> jani.nik...@linux.intel.com; dan...@ffwll.ch; intel-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; dani...@collabora.com; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie
> Subject: Re: [PATCH v2 1/5] drm: Introduce plane and CRTC scaling filter
> properties
>
> On Thu, Mar 19, 2020 at 03:50:59PM +0530, Pankaj Bharadiya wrote:
> > Introduce new plane and CRTC scaling filter properties to allow
> > userspace to select the driver's default scaling filter or
> > Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> > plane.
> >
> > Drivers can set up this property for a plane by calling
> > drm_plane_enable_scaling_filter() and for a CRTC by calling
> > drm_crtc_enable_scaling_filter().
> >
> > NN filter works by filling in the missing color values in the upscaled
> > image with that of the coordinate-mapped nearest source pixel value.
> >
> > NN filter for integer multiple scaling can be particularly useful for
> > for pixel art games that rely on sharp, blocky images to deliver their
> > distinctive look.
> >
> > changes since v1:
> > * None
> > changes since RFC:
> > * Add separate properties for plane and CRTC (Ville)
>
> I actually meant the prop should be per-object, not just separate prop for
> planes
> and crtcs.
My bad, I misunderstood it ☹.
Will add drm_property in drm_crtc and drm_plane.
Thanks,
Pankaj
>
> >
> > Signed-off-by: Shashank Sharma
> > Signed-off-by: Ankit Nautiyal
> > Signed-off-by: Pankaj Bharadiya
> >
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 8
> > drivers/gpu/drm/drm_crtc.c| 33 +++
> > drivers/gpu/drm/drm_mode_config.c | 26
> > drivers/gpu/drm/drm_plane.c | 33 +++
> > include/drm/drm_crtc.h| 13
> > include/drm/drm_mode_config.h | 12 +++
> > include/drm/drm_plane.h | 13
> > 7 files changed, 138 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..3c72ab52ff62 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct
> drm_crtc *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > + } else if (property == config->crtc_scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == config->crtc_scaling_filter_property)
> > + *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> > else
> > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane,
> > sizeof(struct drm_rect),
> > );
> > return ret;
> > + } else if (property == config->plane_scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane
> *plane,
> > } else if (property == config->prop_fb_damage_clips) {
> > *val = (state->fb_damage_clips) ?
> > state->fb_damage_clips->base.id : 0;
> > + } else if (property == config->plane_scaling_filter_property) {
> > + *val = state->scaling_filter;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 4936e1080e41..c8d387891dd5 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -748,3 +748,36 @@ int drm_mode_crtc_set_obj_prop(struct
> > drm_mode_object *obj,
> >
> > return ret;
> > }
> > +
> > +/**
> > + * DOC: CRTC scaling filter property
> > + *
> > + * SCALING_FILTER:
> > + *
> > + * Indicates scaling filter to be used for CRTC scaler
> > + *
> > + * The value of this property can be one of the following:
> > +
[PATCH v3 5/7] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
An option exist changing the layout superblock size to save memory when
using 8bit components pixels size.
The layout options starts at the 8th bit, keeping the first 8bits of the
modifiers bits to define the layout.
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6564813d2f7a..84edc5d69613 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -819,6 +819,12 @@ extern "C" {
* per component YCbCr 420, single plane :
* - DRM_FORMAT_YUV420_8BIT
* - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defined the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
@@ -834,6 +840,22 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/*
+ * Amlogic FBC Layout Options
+ */
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] drm/meson: overlay: setup overlay for Amlogic FBC
Setup the Amlogic FBC decoder for the VD1 video overlay plane.
The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.
This adds support for the basic layout, and needs to calculate the content
body size since the header is allocated after.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.h | 16 ++
drivers/gpu/drm/meson/meson_overlay.c | 233 +-
2 files changed, 241 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index 04fdf3826643..da951964e988 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -80,6 +80,7 @@ struct meson_drm {
bool vd1_enabled;
bool vd1_commit;
+ bool vd1_afbc;
unsigned int vd1_planes;
uint32_t vd1_if0_gen_reg;
uint32_t vd1_if0_luma_x0;
@@ -105,6 +106,21 @@ struct meson_drm {
uint32_t vd1_height0;
uint32_t vd1_height1;
uint32_t vd1_height2;
+ uint32_t vd1_afbc_mode;
+ uint32_t vd1_afbc_en;
+ uint32_t vd1_afbc_head_addr;
+ uint32_t vd1_afbc_body_addr;
+ uint32_t vd1_afbc_conv_ctrl;
+ uint32_t vd1_afbc_dec_def_color;
+ uint32_t vd1_afbc_vd_cfmt_ctrl;
+ uint32_t vd1_afbc_vd_cfmt_w;
+ uint32_t vd1_afbc_vd_cfmt_h;
+ uint32_t vd1_afbc_mif_hor_scope;
+ uint32_t vd1_afbc_mif_ver_scope;
+ uint32_t vd1_afbc_size_out;
+ uint32_t vd1_afbc_pixel_hor_scope;
+ uint32_t vd1_afbc_pixel_ver_scope;
+ uint32_t vd1_afbc_size_in;
uint32_t vpp_pic_in_height;
uint32_t vpp_postblend_vd1_h_start_end;
uint32_t vpp_postblend_vd1_v_start_end;
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 2468b0212d52..51fa038ad5d7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 Amlogic, Inc. All rights reserved.
*/
+#define DEBUG
#include
#include
@@ -76,6 +77,84 @@
#define VD_REGION24_START(value) FIELD_PREP(GENMASK(11, 0), value)
#define VD_REGION13_END(value) FIELD_PREP(GENMASK(27, 16), value)
+/* AFBC_ENABLE */
+#define AFBC_DEC_ENABLEBIT(8)
+#define AFBC_FRM_START BIT(0)
+
+/* AFBC_MODE */
+#define AFBC_HORZ_SKIP_UV(value) FIELD_PREP(GENMASK(1, 0), value)
+#define AFBC_VERT_SKIP_UV(value) FIELD_PREP(GENMASK(3, 2), value)
+#define AFBC_HORZ_SKIP_Y(value)FIELD_PREP(GENMASK(5, 4), value)
+#define AFBC_VERT_SKIP_Y(value)FIELD_PREP(GENMASK(7, 6), value)
+#define AFBC_COMPBITS_YUV(value) FIELD_PREP(GENMASK(13, 8), value)
+#define AFBC_COMPBITS_8BIT 0
+#define AFBC_COMPBITS_10BIT(2 | (2 << 2) | (2 << 4))
+#define AFBC_BURST_LEN(value) FIELD_PREP(GENMASK(15, 14), value)
+#define AFBC_HOLD_LINE_NUM(value) FIELD_PREP(GENMASK(22, 16), value)
+#define AFBC_MIF_URGENT(value) FIELD_PREP(GENMASK(25, 24), value)
+#define AFBC_REV_MODE(value) FIELD_PREP(GENMASK(27, 26), value)
+#define AFBC_BLK_MEM_MODE BIT(28)
+#define AFBC_SCATTER_MODE BIT(29)
+#define AFBC_SOFT_RESETBIT(31)
+
+/* AFBC_SIZE_IN */
+#define AFBC_HSIZE_IN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_IN(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_DEC_DEF_COLOR */
+#define AFBC_DEF_COLOR_Y(value)FIELD_PREP(GENMASK(29, 20),
value)
+#define AFBC_DEF_COLOR_U(value)FIELD_PREP(GENMASK(19, 10),
value)
+#define AFBC_DEF_COLOR_V(value)FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_CONV_CTRL */
+#define AFBC_CONV_LBUF_LEN(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_LBUF_DEPTH */
+#define AFBC_DEC_LBUF_DEPTH(value) FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_LBUF_DEPTH(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_OUT_XSCOPE/AFBC_SIZE_OUT */
+#define AFBC_HSIZE_OUT(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_OUT(value) FIELD_PREP(GENMASK(12, 0), value)
+#define AFBC_OUT_HORZ_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_HORZ_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_OUT_YSCOPE */
+#define AFBC_OUT_VERT_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_VERT_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_CTRL */
+#define AFBC_HORZ_RPT_PIXEL0 BIT(23)
+#define AFBC_HORZ_Y_C_RATIO(value) FIELD_PREP(GENMASK(22, 21), value)
+#define AFBC_HORZ_FMT_EN
[PATCH v3 2/7] drm/meson: add Amlogic Video FBC registers
Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing register. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_registers.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h index 8ea00546cd4e..08631fdfe4b9 100644 --- a/drivers/gpu/drm/meson/meson_registers.h +++ b/drivers/gpu/drm/meson/meson_registers.h @@ -144,10 +144,15 @@ #defineVIU_SW_RESET_OSD1 BIT(0) #define VIU_MISC_CTRL0 0x1a06 #defineVIU_CTRL0_VD1_AFBC_MASK 0x17 +#defineVIU_CTRL0_AFBC_TO_VD1 BIT(20) #define VIU_MISC_CTRL1 0x1a07 #defineMALI_AFBC_MISC GENMASK(15, 8) #define D2D3_INTF_LENGTH 0x1a08 #define D2D3_INTF_CTRL0 0x1a09 +#define VD1_AFBCD0_MISC_CTRL 0x1a0a +#defineVD1_AXI_SEL_AFBC(1 << 12) +#defineAFBC_VD1_SEL(1 << 10) +#define VD2_AFBCD1_MISC_CTRL 0x1a0b #define VIU_OSD1_CTRL_STAT 0x1a10 #defineVIU_OSD1_OSD_BLK_ENABLE BIT(0) #defineVIU_OSD1_OSD_MEM_MODE_LINEARBIT(2) @@ -365,6 +370,23 @@ #define VIU_OSD1_OETF_LUT_ADDR_PORT 0x1add #define VIU_OSD1_OETF_LUT_DATA_PORT 0x1ade #define AFBC_ENABLE 0x1ae0 +#define AFBC_MODE 0x1ae1 +#define AFBC_SIZE_IN 0x1ae2 +#define AFBC_DEC_DEF_COLOR 0x1ae3 +#define AFBC_CONV_CTRL 0x1ae4 +#define AFBC_LBUF_DEPTH 0x1ae5 +#define AFBC_HEAD_BADDR 0x1ae6 +#define AFBC_BODY_BADDR 0x1ae7 +#define AFBC_SIZE_OUT 0x1ae8 +#define AFBC_OUT_YSCOPE 0x1ae9 +#define AFBC_STAT 0x1aea +#define AFBC_VD_CFMT_CTRL 0x1aeb +#define AFBC_VD_CFMT_W 0x1aec +#define AFBC_MIF_HOR_SCOPE 0x1aed +#define AFBC_MIF_VER_SCOPE 0x1aee +#define AFBC_PIXEL_HOR_SCOPE 0x1aef +#define AFBC_PIXEL_VER_SCOPE 0x1af0 +#define AFBC_VD_CFMT_H 0x1af1 /* vpp */ #define VPP_DUMMY_DATA 0x1d00 -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/7] drm/meson: add support for Amlogic Video FBC
Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders. It considerably reduces memory bandwidth while writing and reading frames in memory. The underlying storage is considered to be 3 components, 8bit or 10-bit per component, YCbCr 420, single plane : - DRM_FORMAT_YUV420_8BIT - DRM_FORMAT_YUV420_10BIT This modifier will be notably added to DMA-BUF frames imported from the V4L2 Amlogic VDEC decoder. At least two layout are supported : - Basic: composed of a body and a header - Scatter: the buffer is filled with a IOMMU scatter table referring to the encoder current memory layout. This mode if more efficient in terms of memory allocation but frames are not dumpable and only valid during until the buffer is freed and back in control of the encoder At least two options are supported : - Memory saving: when the pixel bpp is 8b, the size of the superblock can be reduced, thus saving memory. This serie adds the missing register, updated the FBC decoder registers content to be committed by the crtc code. The Amlogic FBC has been tested with compressed content from the Amlogic HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit (Scatter on G12A/SM1, default on GXL). It's expected to work as-is on GXM and G12B SoCs. Changes since v2 at [2]: - Added "BASIC" layout and moved the SCATTER mode as layout, making BASIC and SCATTER layout exclusives - Moved the Memory Saving at bit 8 for options fields - Split fourcc and overlay patch to introduce basic, mem saving and then scatter in separate patches - Added comment about "transferability" of the buffers Changes since v1 at [1]: - s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h [1] https://patchwork.freedesktop.org/series/73722/#rev1 [2] https://patchwork.freedesktop.org/series/73722/#rev2 Neil Armstrong (7): drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression drm/meson: add Amlogic Video FBC registers drm/meson: overlay: setup overlay for Amlogic FBC drm/meson: crtc: handle commit of Amlogic FBC frames drm/fourcc: amlogic: Add modifier definitions for Memory Saving option drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout drivers/gpu/drm/meson/meson_crtc.c | 118 --- drivers/gpu/drm/meson/meson_drv.h | 16 ++ drivers/gpu/drm/meson/meson_overlay.c | 257 +++- drivers/gpu/drm/meson/meson_registers.h | 22 ++ include/uapi/drm/drm_fourcc.h | 66 ++ 5 files changed, 441 insertions(+), 38 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 14 --
include/uapi/drm/drm_fourcc.h | 16 +++-
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 51fa038ad5d7..8b9d4984b2a7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
+ priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -672,12 +675,17 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
unsigned long body_size;
- /* Default mode is 4k per superblock */
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
(ALIGN(priv->viu.vd1_height0, 32) / 32) *
- 4096;
+ block_size;
priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
@@ -763,6 +771,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 84edc5d69613..b49f1d45e1b4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -840,6 +840,19 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER (2ULL << 0)
+
/*
* Amlogic FBC Layout Options
*/
@@ -852,7 +865,8 @@ extern "C" {
* memory.
*
* This mode reduces body layout to 3072 bytes per 64x32 superblock with
- * the basic layout.
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.
This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
superblock in default mode.
- a 32 bytes per 128x64 header block
This layout is tranferrable between Amlogic SoCs supporting this modifier.
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..6564813d2f7a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -309,6 +309,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
/* add more to the end as needed */
@@ -804,6 +805,35 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ * superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/meson: crtc: handle commit of Amlogic FBC frames
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..d6dcfd654e9c 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
VPP_COLOR_MNG_ENABLE,
priv->io_base + _REG(VPP_MISC));
+
+ writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+ priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+ priv->io_base + _REG(VIU_MISC_CTRL0));
}
static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm
*priv)
VD_BLEND_POSTBLD_SRC_VD1 |
VD_BLEND_POSTBLD_PREMULT_EN,
priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+ writel_relaxed(priv->viu.vd1_afbc ?
+ (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+ priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
}
void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
/* Update the VD1 registers */
if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
- switch (priv->viu.vd1_planes) {
- case 3:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_2,
- priv->viu.vd1_addr2,
- priv->viu.vd1_stride2,
- priv->viu.vd1_height2,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 2:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_1,
- priv->viu.vd1_addr1,
- priv->viu.vd1_stride1,
- priv->viu.vd1_height1,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 1:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_0,
- priv->viu.vd1_addr0,
- priv->viu.vd1_stride0,
- priv->viu.vd1_height0,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
+ if (priv->viu.vd1_afbc) {
+ writel_relaxed(priv->viu.vd1_afbc_head_addr,
+ priv->io_base +
+ _REG(AFBC_HEAD_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_body_addr,
+ priv->io_base +
+ _REG(AFBC_BODY_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_en,
+ priv->io_base +
+ _REG(AFBC_ENABLE));
+ writel_relaxed(priv->viu.vd1_afbc_mode,
+ priv->io_base +
+ _REG(AFBC_MODE));
+ writel_relaxed(priv->viu.vd1_afbc_size_in,
+ priv->io_base +
+ _REG(AFBC_SIZE_IN));
+ writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+ priv->io_base +
+ _REG(AFBC_DEC_DEF_COLOR));
+ writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+ priv->io_base +
+ _REG(AFBC_CONV_CTRL));
+ writel_relaxed(priv->viu.vd1_afbc_size_out,
+ priv->io_base +
+ _REG(AFBC_SIZE_OUT));
+
[PATCH v3 7/7] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 48 +--
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 8b9d4984b2a7..af4698ae5281 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_SCATTER)
+ priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
@@ -675,23 +678,32 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
- /* Default mode is 4k per superblock */
- unsigned long block_size = 4096;
- unsigned long body_size;
-
- /* 8bit mem saving mode is 3072bytes per superblock */
- if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
- block_size = 3072;
-
- body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
- (ALIGN(priv->viu.vd1_height0, 32) / 32) *
- block_size;
-
- priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
- /* Header is after body content */
- priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
- body_size) >> 4;
+ if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+ /*
+* In Scatter mode, the header contains the physical
+* body content layout, thus the body content
+* size isn't needed.
+*/
+ priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+ priv->viu.vd1_afbc_body_addr = 0;
+ } else {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
+ unsigned long body_size;
+
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
+ body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+ (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+ block_size;
+
+ priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+ /* Header is after body content */
+ priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+ body_size) >> 4;
+ }
}
priv->viu.vd1_enabled = true;
@@ -771,6 +783,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] video: fbdev: vesafb: add missed release_region
On 3/24/20 2:35 PM, Chuhong Yuan wrote:
> On Fri, Mar 20, 2020 at 8:01 PM Bartlomiej Zolnierkiewicz
> wrote:
>>
>>
>> On 3/10/20 3:35 AM, Chuhong Yuan wrote:
>>> The driver forgets to free the I/O region in remove and probe
>>> failure.
>>> Add the missed calls to fix it.
>>>
>>> Signed-off-by: Chuhong Yuan
>>> ---
>>> Changes in v3:
>>> - Revise the commit message.
>>> - Add an error handler to suit the "goto error" before request_region().
>>> - Revise the order of operations in remove.
>>>
>>> drivers/video/fbdev/vesafb.c | 9 ++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
>>> index a1fe24ea869b..c7bc9ace47d4 100644
>>> --- a/drivers/video/fbdev/vesafb.c
>>> +++ b/drivers/video/fbdev/vesafb.c
>>> @@ -439,7 +439,7 @@ static int vesafb_probe(struct platform_device *dev)
>>> "vesafb: abort, cannot ioremap video memory 0x%x @
>>> 0x%lx\n",
>>> vesafb_fix.smem_len, vesafb_fix.smem_start);
>>> err = -EIO;
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>>
>>> printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
>>> @@ -458,15 +458,17 @@ static int vesafb_probe(struct platform_device *dev)
>>>
>>> if (fb_alloc_cmap(>cmap, 256, 0) < 0) {
>>> err = -ENOMEM;
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>> if (register_framebuffer(info)<0) {
>>> err = -EINVAL;
>>> fb_dealloc_cmap(>cmap);
>>> - goto err;
>>> + goto err_release_region;
>>> }
>>> fb_info(info, "%s frame buffer device\n", info->fix.id);
>>> return 0;
>>> +err_release_region:
>>> + release_region(0x3c0, 32);
>>
>> This is incorrect.
>>
>> The cleanup order should be the reverse of the probing order.
>>
>> Also request_region() return value is not checked by the driver
>> (there is a comment that it can fail and is optional):
>>
>> /* request failure does not faze us, as vgacon probably has this
>> * region already (FIXME) */
>> request_region(0x3c0, 32, "vesafb");
>>
>> so what would happen in such case? It seems that unconditionally
>> doing the release will result in freeing the I/O region owned by
>> the other driver (vgacon)..
>>
>
> Maybe we can add a field to represent whether the request succeeds?
> request_region() returns source *, we can store it and check whether
> it is null when
> we are going to call release_region().
Yes, this is a preferred approach.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
>>> err:
>>> arch_phys_wc_del(par->wc_cookie);
>>> if (info->screen_base)
>>> @@ -481,6 +483,7 @@ static int vesafb_remove(struct platform_device *pdev)
>>> struct fb_info *info = platform_get_drvdata(pdev);
>>>
>>> unregister_framebuffer(info);
>>> + release_region(0x3c0, 32);
>>> framebuffer_release(info);
>>>
>>> return 0;
>>>
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R Institute Poland
>> Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/6] video: fbdev: controlfb: add COMPILE_TEST support
Add COMPILE_TEST support to controlfb driver for better compile
testing coverage.
While at it:
- convert driver to use eieio() and dcbf() helpers instead of
open-coding them
- add invalid_vram_cache() helper to avoid code duplication
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/controlfb.c | 41 ++---
2 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 91b0a719d221..fa88e8b9a83d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -472,7 +472,7 @@ config FB_OF
config FB_CONTROL
bool "Apple \"control\" display support"
- depends on (FB = y) && PPC_PMAC && PPC32
+ depends on (FB = y) && ((PPC_PMAC && PPC32) || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 9625792f4413..b347bc78bc4a 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -48,12 +48,37 @@
#include
#include
#include
+#ifdef CONFIG_PPC_PMAC
#include
#include
+#endif
#include "macmodes.h"
#include "controlfb.h"
+#ifndef CONFIG_PPC_PMAC
+#define invalid_vram_cache(addr)
+#undef in_8
+#undef out_8
+#undef in_le32
+#undef out_le32
+#define in_8(addr) 0
+#define out_8(addr, val)
+#define in_le32(addr) 0
+#define out_le32(addr, val)
+#define pgprot_cached_wthru(prot) (prot)
+#else
+static void invalid_vram_cache(void __force *addr)
+{
+ eieio();
+ dcbf(addr);
+ mb();
+ eieio();
+ dcbf(addr);
+ mb();
+}
+#endif
+
struct fb_par_control {
int vmode, cmode;
int xres, yres;
@@ -309,7 +334,7 @@ static int controlfb_mmap(struct fb_info *info,
static int controlfb_blank(int blank_mode, struct fb_info *info)
{
- struct fb_info_control *p =
+ struct fb_info_control __maybe_unused *p =
container_of(info, struct fb_info_control, info);
unsigned ctrl;
@@ -605,12 +630,7 @@ static void __init find_vram_size(struct fb_info_control
*p)
out_8(>frame_buffer[0x60], 0xb3);
out_8(>frame_buffer[0x61], 0x71);
- asm volatile("eieio; dcbf 0,%0" : : "r" (>frame_buffer[0x60])
- : "memory" );
- mb();
- asm volatile("eieio; dcbi 0,%0" : : "r" (>frame_buffer[0x60])
- : "memory" );
- mb();
+ invalid_vram_cache(>frame_buffer[0x60]);
bank2 = (in_8(>frame_buffer[0x60]) == 0xb3)
&& (in_8(>frame_buffer[0x61]) == 0x71);
@@ -624,12 +644,7 @@ static void __init find_vram_size(struct fb_info_control
*p)
out_8(>frame_buffer[0], 0x5a);
out_8(>frame_buffer[1], 0xc7);
- asm volatile("eieio; dcbf 0,%0" : : "r" (>frame_buffer[0])
- : "memory" );
- mb();
- asm volatile("eieio; dcbi 0,%0" : : "r" (>frame_buffer[0])
- : "memory" );
- mb();
+ invalid_vram_cache(>frame_buffer[0]);
bank1 = (in_8(>frame_buffer[0]) == 0x5a)
&& (in_8(>frame_buffer[1]) == 0xc7);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] video: fbdev: controlfb: small cleanup
Hi, Small cleanup for controlfb driver: - fix sparse warnings - remove not working module support - add COMPILE_TEST support - remove redundant function prototypes Changes since v1 (https://lore.kernel.org/lkml/20200116140900.26363-1-b.zolnier...@samsung.com/): - use in_le32() instead of le32_to_cpup() - use eieio() and dcbf() helpers - add invalid_vram_cache() helper - add more dummy CONFIG_PPC_PMAC=n helpers to avoid ifdefs - add ACKs from Sam Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (6): video: fbdev: controlfb: fix sparse warning about using incorrect type video: fbdev: controlfb: add COMPILE_TEST support video: fbdev: controlfb: remove obsolete module support video: fbdev: controlfb: remove function prototypes part #1 video: fbdev: controlfb: remove function prototypes part #2 video: fbdev: controlfb: remove function prototypes part #3 drivers/video/fbdev/Kconfig | 2 +- drivers/video/fbdev/controlfb.c | 828 +++- 2 files changed, 391 insertions(+), 439 deletions(-) -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/6] video: fbdev: controlfb: remove obsolete module support
CONFIG_FB_CONTROL is bool, hence the Apple "control" frame buffer
driver cannot be built as a module.
Replace module_init() by device_initcall().
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index b347bc78bc4a..92cffd2d0219 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -31,7 +31,6 @@
* more details.
*/
-#include
#include
#include
#include
@@ -198,28 +197,6 @@ static const struct fb_ops controlfb_ops = {
/ The functions for controlfb_ops /
-#ifdef MODULE
-MODULE_LICENSE("GPL");
-
-int init_module(void)
-{
- struct device_node *dp;
- int ret = -ENXIO;
-
- dp = of_find_node_by_name(NULL, "control");
- if (dp && !control_of_init(dp))
- ret = 0;
- of_node_put(dp);
-
- return ret;
-}
-
-void cleanup_module(void)
-{
- control_cleanup();
-}
-#endif
-
/*
* Checks a var structure
*/
@@ -612,7 +589,7 @@ static int __init control_init(void)
return ret;
}
-module_init(control_init);
+device_initcall(control_init);
/* Work out which banks of VRAM we have installed. */
/* danj: I guess the card just ignores writes to nonexistant VRAM... */
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] video: fbdev: controlfb: remove function prototypes part #3
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 302 +++-
1 file changed, 145 insertions(+), 157 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index c67d37103705..7f8f0081396e 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -141,16 +141,6 @@ struct fb_info_control {
#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs->REG).r))
-/ Prototypes for internal functions **/
-
-static void control_set_hardware(struct fb_info_control *p,
- struct fb_par_control *par);
-static int control_var_to_par(struct fb_var_screeninfo *var,
- struct fb_par_control *par, const struct fb_info *fb_info);
-static inline void control_par_to_var(struct fb_par_control *par,
- struct fb_var_screeninfo *var);
-
-
/** Internal variables ***/
static struct fb_info_control *control_fb;
@@ -159,153 +149,6 @@ static int default_vmode __initdata = VMODE_NVRAM;
static int default_cmode __initdata = CMODE_NVRAM;
-/ The functions for controlfb_ops /
-
-/*
- * Checks a var structure
- */
-static int controlfb_check_var (struct fb_var_screeninfo *var, struct fb_info
*info)
-{
- struct fb_par_control par;
- int err;
-
- err = control_var_to_par(var, , info);
- if (err)
- return err;
- control_par_to_var(, var);
-
- return 0;
-}
-
-/*
- * Applies current var to display
- */
-static int controlfb_set_par (struct fb_info *info)
-{
- struct fb_info_control *p =
- container_of(info, struct fb_info_control, info);
- struct fb_par_control par;
- int err;
-
- if((err = control_var_to_par(>var, , info))) {
- printk (KERN_ERR "controlfb_set_par: error calling"
-" control_var_to_par: %d.\n", err);
- return err;
- }
-
- control_set_hardware(p, );
-
- info->fix.visual = (p->par.cmode == CMODE_8) ?
- FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
- info->fix.line_length = p->par.pitch;
- info->fix.xpanstep = 32 >> p->par.cmode;
- info->fix.ypanstep = 1;
-
- return 0;
-}
-
-/*
- * Set screen start address according to var offset values
- */
-static inline void set_screen_start(int xoffset, int yoffset,
- struct fb_info_control *p)
-{
- struct fb_par_control *par = >par;
-
- par->xoffset = xoffset;
- par->yoffset = yoffset;
- out_le32(CNTRL_REG(p,start_addr),
-par->yoffset * par->pitch + (par->xoffset << par->cmode));
-}
-
-
-static int controlfb_pan_display(struct fb_var_screeninfo *var,
-struct fb_info *info)
-{
- unsigned int xoffset, hstep;
- struct fb_info_control *p =
- container_of(info, struct fb_info_control, info);
- struct fb_par_control *par = >par;
-
- /*
-* make sure start addr will be 32-byte aligned
-*/
- hstep = 0x1f >> par->cmode;
- xoffset = (var->xoffset + hstep) & ~hstep;
-
- if (xoffset+par->xres > par->vxres ||
- var->yoffset+par->yres > par->vyres)
- return -EINVAL;
-
- set_screen_start(xoffset, var->yoffset, p);
-
- return 0;
-}
-
-
-/*
- * Private mmap since we want to have a different caching on the framebuffer
- * for controlfb.
- * Note there's no locking in here; it's done in fb_mmap() in fbmem.c.
- */
-static int controlfb_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
- unsigned long mmio_pgoff;
- unsigned long start;
- u32 len;
-
- start = info->fix.smem_start;
- len = info->fix.smem_len;
- mmio_pgoff = PAGE_ALIGN((start & ~PAGE_MASK) + len) >> PAGE_SHIFT;
- if (vma->vm_pgoff >= mmio_pgoff) {
- if (info->var.accel_flags)
- return -EINVAL;
- vma->vm_pgoff -= mmio_pgoff;
- start = info->fix.mmio_start;
- len = info->fix.mmio_len;
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- } else {
- /* framebuffer */
- vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
- }
-
- return vm_iomap_memory(vma, start, len);
-}
-
-static int controlfb_blank(int blank_mode, struct fb_info *info)
-{
- struct fb_info_control __maybe_unused *p =
- container_of(info, struct fb_info_control, info);
- unsigned ctrl;
-
- ctrl = in_le32(CNTRL_REG(p, ctrl));
- if (blank_mode > 0)
- switch (blank_mode) {
- case FB_BLANK_VSYNC_SUSPEND:
- ctrl &=
[PATCH v2 5/6] video: fbdev: controlfb: remove function prototypes part #2
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 410 +++-
1 file changed, 198 insertions(+), 212 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 83b7a219f557..c67d37103705 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -143,20 +143,12 @@ struct fb_info_control {
/ Prototypes for internal functions **/
-static void set_control_clock(unsigned char *params);
-static int init_control(struct fb_info_control *p);
static void control_set_hardware(struct fb_info_control *p,
struct fb_par_control *par);
-static int control_of_init(struct device_node *dp);
-static void find_vram_size(struct fb_info_control *p);
-static int read_control_sense(struct fb_info_control *p);
-static int calc_clock_params(unsigned long clk, unsigned char *param);
static int control_var_to_par(struct fb_var_screeninfo *var,
struct fb_par_control *par, const struct fb_info *fb_info);
static inline void control_par_to_var(struct fb_par_control *par,
struct fb_var_screeninfo *var);
-static void control_init_info(struct fb_info *info, struct fb_info_control *p);
-static void control_cleanup(void);
/** Internal variables ***/
@@ -370,77 +362,6 @@ static void set_control_clock(unsigned char *params)
#endif
}
-
-/*
- * finish off the driver initialization and register
- */
-static int __init init_control(struct fb_info_control *p)
-{
- int full, sense, vmode, cmode, vyres;
- struct fb_var_screeninfo var;
- int rc;
-
- printk(KERN_INFO "controlfb: ");
-
- full = p->total_vram == 0x40;
-
- /* Try to pick a video mode out of NVRAM if we have one. */
- cmode = default_cmode;
- if (IS_REACHABLE(CONFIG_NVRAM) && cmode == CMODE_NVRAM)
- cmode = nvram_read_byte(NV_CMODE);
- if (cmode < CMODE_8 || cmode > CMODE_32)
- cmode = CMODE_8;
-
- vmode = default_vmode;
- if (IS_REACHABLE(CONFIG_NVRAM) && vmode == VMODE_NVRAM)
- vmode = nvram_read_byte(NV_VMODE);
- if (vmode < 1 || vmode > VMODE_MAX ||
- control_mac_modes[vmode - 1].m[full] < cmode) {
- sense = read_control_sense(p);
- printk(KERN_CONT "Monitor sense value = 0x%x, ", sense);
- vmode = mac_map_monitor_sense(sense);
- if (control_mac_modes[vmode - 1].m[full] < 0)
- vmode = VMODE_640_480_60;
- cmode = min(cmode, control_mac_modes[vmode - 1].m[full]);
- }
-
- /* Initialize info structure */
- control_init_info(>info, p);
-
- /* Setup default var */
- if (mac_vmode_to_var(vmode, cmode, ) < 0) {
- /* This shouldn't happen! */
- printk("mac_vmode_to_var(%d, %d,) failed\n", vmode, cmode);
-try_again:
- vmode = VMODE_640_480_60;
- cmode = CMODE_8;
- if (mac_vmode_to_var(vmode, cmode, ) < 0) {
- printk(KERN_ERR "controlfb: mac_vmode_to_var()
failed\n");
- return -ENXIO;
- }
- printk(KERN_INFO "controlfb: ");
- }
- printk("using video mode %d and color mode %d.\n", vmode, cmode);
-
- vyres = (p->total_vram - CTRLFB_OFF) / (var.xres << cmode);
- if (vyres > var.yres)
- var.yres_virtual = vyres;
-
- /* Apply default var */
- var.activate = FB_ACTIVATE_NOW;
- rc = fb_set_var(>info, );
- if (rc && (vmode != VMODE_640_480_60 || cmode != CMODE_8))
- goto try_again;
-
- /* Register with fbdev layer */
- if (register_framebuffer(>info) < 0)
- return -ENXIO;
-
- fb_info(>info, "control display adapter\n");
-
- return 0;
-}
-
#define RADACAL_WRITE(a,d) \
out_8(>cmap_regs->addr, (a)); \
out_8(>cmap_regs->dat, (d))
@@ -502,67 +423,6 @@ static void control_set_hardware(struct fb_info_control
*p, struct fb_par_contro
#endif /* CONFIG_BOOTX_TEXT */
}
-
-/*
- * Parse user specified options (`video=controlfb:')
- */
-static void __init control_setup(char *options)
-{
- char *this_opt;
-
- if (!options || !*options)
- return;
-
- while ((this_opt = strsep(, ",")) != NULL) {
- if (!strncmp(this_opt, "vmode:", 6)) {
- int vmode = simple_strtoul(this_opt+6, NULL, 0);
- if (vmode > 0 && vmode <= VMODE_MAX &&
- control_mac_modes[vmode - 1].m[1] >= 0)
- default_vmode = vmode;
- } else if (!strncmp(this_opt, "cmode:", 6)) {
- int depth =
[PATCH v2 4/6] video: fbdev: controlfb: remove function prototypes part #1
Reorder code a bit and then remove no longer needed function
prototypes.
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 41 +++--
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 92cffd2d0219..83b7a219f557 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -141,20 +141,6 @@ struct fb_info_control {
#define CNTRL_REG(INFO,REG) (&(((INFO)->control_regs->REG).r))
-/ Prototypes for exported functions /
-/*
- * struct fb_ops
- */
-static int controlfb_pan_display(struct fb_var_screeninfo *var,
- struct fb_info *info);
-static int controlfb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
- u_int transp, struct fb_info *info);
-static int controlfb_blank(int blank_mode, struct fb_info *info);
-static int controlfb_mmap(struct fb_info *info,
- struct vm_area_struct *vma);
-static int controlfb_set_par (struct fb_info *info);
-static int controlfb_check_var (struct fb_var_screeninfo *var, struct fb_info
*info);
-
/ Prototypes for internal functions **/
static void set_control_clock(unsigned char *params);
@@ -181,20 +167,6 @@ static int default_vmode __initdata = VMODE_NVRAM;
static int default_cmode __initdata = CMODE_NVRAM;
-static const struct fb_ops controlfb_ops = {
- .owner = THIS_MODULE,
- .fb_check_var = controlfb_check_var,
- .fb_set_par = controlfb_set_par,
- .fb_setcolreg = controlfb_setcolreg,
- .fb_pan_display = controlfb_pan_display,
- .fb_blank = controlfb_blank,
- .fb_mmap= controlfb_mmap,
- .fb_fillrect= cfb_fillrect,
- .fb_copyarea= cfb_copyarea,
- .fb_imageblit = cfb_imageblit,
-};
-
-
/ The functions for controlfb_ops /
/*
@@ -1012,6 +984,19 @@ static inline void control_par_to_var(struct
fb_par_control *par,
var->pixclock >>= par->regvals.clock_params[2];
}
+static const struct fb_ops controlfb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = controlfb_check_var,
+ .fb_set_par = controlfb_set_par,
+ .fb_setcolreg = controlfb_setcolreg,
+ .fb_pan_display = controlfb_pan_display,
+ .fb_blank = controlfb_blank,
+ .fb_mmap= controlfb_mmap,
+ .fb_fillrect= cfb_fillrect,
+ .fb_copyarea= cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
/*
* Set misc info vars for this driver
*/
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] video: fbdev: controlfb: fix sparse warning about using incorrect type
Use in_le32() instead of le32_to_cpup() to fix sparse warning about
improper type of the argument.
Also add missing inline keyword to control_par_to_var() definition
(to match function prototype).
Acked-by: Sam Ravnborg
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 38b61cdb5ca4..9625792f4413 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -313,7 +313,7 @@ static int controlfb_blank(int blank_mode, struct fb_info
*info)
container_of(info, struct fb_info_control, info);
unsigned ctrl;
- ctrl = le32_to_cpup(CNTRL_REG(p,ctrl));
+ ctrl = in_le32(CNTRL_REG(p, ctrl));
if (blank_mode > 0)
switch (blank_mode) {
case FB_BLANK_VSYNC_SUSPEND:
@@ -952,7 +952,8 @@ static int control_var_to_par(struct fb_var_screeninfo *var,
* Convert hardware data in par to an fb_var_screeninfo
*/
-static void control_par_to_var(struct fb_par_control *par, struct
fb_var_screeninfo *var)
+static inline void control_par_to_var(struct fb_par_control *par,
+ struct fb_var_screeninfo *var)
{
struct control_regints *rv;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
On Tue, Mar 24, 2020 at 01:57:35PM +0100, Uwe Kleine-König wrote: > Hello Lee, > > On Tue, Mar 24, 2020 at 11:07:10AM +, Lee Jones wrote: > > On Fri, 20 Mar 2020, Lee Jones wrote: > > > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > > > > > > > Since the PWM framework is switching struct pwm_state.period's datatype > > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit > > > > dividend instead of a straight division operation. > > > > > > > > Cc: Lee Jones > > > > Cc: Daniel Thompson > > > > Cc: Jingoo Han > > > > Cc: Bartlomiej Zolnierkiewicz > > > > Cc: linux-...@vger.kernel.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linux-fb...@vger.kernel.org > > > > > > > > Signed-off-by: Guru Das Srinagesh > > > > Reviewed-by: Daniel Thompson > > > > --- > > > > drivers/video/backlight/pwm_bl.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > Can this patch be taken on its own? > > > > Hello ... > > Conceptually it can. As the last patch depends on this one (and the > others) some coordination might be beneficial. But that's up to Thierry > to decide how (and if) he want this series to be applied. ... and on the backlight side we definitely need to know about the "if" otherwise there's no point in taking it. Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text
Am 24.03.2020 13:54 schrieb Geert Uytterhoeven :
Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by:
1. Removing duplicated single quotes,
2. Adding a missing subject,
3. Fixing a misspelling of "yet",
4. Wrapping long lines.
Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Christian König
---
drivers/dma-buf/Kconfig | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ef73b678419c6d86..9626673f1d83ae64 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -43,11 +43,12 @@ config DMABUF_MOVE_NOTIFY
bool "Move notify between drivers (EXPERIMENTAL)"
default n
help
- Don''t pin buffers if the dynamic DMA-buf interface is available on
both the
- exporter as well as the importer. This fixes a security problem where
- userspace is able to pin unrestricted amounts of memory through
DMA-buf.
- But marked experimental because we don''t jet have a consistent
execution
- context and memory management between drivers.
+ Don't pin buffers if the dynamic DMA-buf interface is available on
+ both the exporter as well as the importer. This fixes a security
+ problem where userspace is able to pin unrestricted amounts of memory
+ through DMA-buf.
+ This is marked experimental because we don't yet have a consistent
+ execution context and memory management between drivers.
config DMABUF_SELFTESTS
tristate "Selftests for the dma-buf interfaces"
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
Hello Lee, On Tue, Mar 24, 2020 at 11:07:10AM +, Lee Jones wrote: > On Fri, 20 Mar 2020, Lee Jones wrote: > > > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > > > > > Since the PWM framework is switching struct pwm_state.period's datatype > > > to u64, prepare for this transition by using div_u64 to handle a 64-bit > > > dividend instead of a straight division operation. > > > > > > Cc: Lee Jones > > > Cc: Daniel Thompson > > > Cc: Jingoo Han > > > Cc: Bartlomiej Zolnierkiewicz > > > Cc: linux-...@vger.kernel.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linux-fb...@vger.kernel.org > > > > > > Signed-off-by: Guru Das Srinagesh > > > Reviewed-by: Daniel Thompson > > > --- > > > drivers/video/backlight/pwm_bl.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Can this patch be taken on its own? > > Hello ... Conceptually it can. As the last patch depends on this one (and the others) some coordination might be beneficial. But that's up to Thierry to decide how (and if) he want this series to be applied. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text
Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by:
1. Removing duplicated single quotes,
2. Adding a missing subject,
3. Fixing a misspelling of "yet",
4. Wrapping long lines.
Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15")
Signed-off-by: Geert Uytterhoeven
---
drivers/dma-buf/Kconfig | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ef73b678419c6d86..9626673f1d83ae64 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -43,11 +43,12 @@ config DMABUF_MOVE_NOTIFY
bool "Move notify between drivers (EXPERIMENTAL)"
default n
help
- Don''t pin buffers if the dynamic DMA-buf interface is available on
both the
- exporter as well as the importer. This fixes a security problem where
- userspace is able to pin unrestricted amounts of memory through
DMA-buf.
- But marked experimental because we don''t jet have a consistent
execution
- context and memory management between drivers.
+ Don't pin buffers if the dynamic DMA-buf interface is available on
+ both the exporter as well as the importer. This fixes a security
+ problem where userspace is able to pin unrestricted amounts of memory
+ through DMA-buf.
+ This is marked experimental because we don't yet have a consistent
+ execution context and memory management between drivers.
config DMABUF_SELFTESTS
tristate "Selftests for the dma-buf interfaces"
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2020 X.Org Board of Directors Elections Nomination period is NOW
Another reminder that we're in the election process, and the next deadline is approaching: - Send board nominations to elections AT x DOT org - Got to https://members.x.org/ to renew your membership (or become one to begin with!) On Tue, Mar 17, 2020 at 7:21 AM Daniel Vetter wrote: > > Just a quick reminder that both board nomination and membership > renewal periods are still opening: > > - Send board nominations to elections AT x DOT org > > - Got to https://members.x.org/ to renew your membership (or become > one to begin with!) > > Cheers, Daniel > > On Sun, Mar 8, 2020 at 8:51 PM Daniel Vetter wrote: > > > > We are seeking nominations for candidates for election to the X.Org > > Foundation Board of Directors. All X.Org Foundation members are > > eligible for election to the board. > > > > Nominations for the 202 election are now open and will remain open > > until 23:59 UTC on 29th March 2020. > > > > The Board consists of directors elected from the membership. Each > > year, an election is held to bring the total number of directors to > > eight. The four members receiving the highest vote totals will serve > > as directors for two year terms. > > > > The directors who received two year terms starting in 2019 wereSamuel > > Iglesias Gonsálvez, Manasi D Navare, Lyude Paul and Daniel Vetter. > > They will continue to serve until their term ends in 2021. Current > > directors whose term expires in 2020 are Eric Anholt, Bryce > > Harrington, Keith Packard and Harry Wentland. > > > > A director is expected to participate in the fortnightly IRC meeting > > to discuss current business and to attend the annual meeting of the > > X.Org Foundation, which will be held at a location determined in > > advance by the Board of Directors. > > > > A member may nominate themselves or any other member they feel is > > qualified. Nominations should be sent to the Election Committee at > > elections at x.org. > > > > Nominees shall be required to be current members of the X.Org > > Foundation, and submit a personal statement of up to 200 words that > > will be provided to prospective voters. The collected statements, > > along with the statement of contribution to the X.Org Foundation in > > the member's account page on http://members.x.org, will be made > > available to all voters to help them make their voting decisions. > > > > Nominations, membership applications or renewals and completed > > personal statements must be received no later than 23:59 UTC on 02 > > April 2020. > > > > The slate of candidates will be published 6 April 2020 and candidate > > Q will begin then. The deadline for Xorg membership applications and > > renewals is 02 April 2020. > > > > Cheers, Daniel, on behalf of the X.Org BoD > > > > PS: I cc'ed the usual dev lists since not many members put in the renewal > > yet. > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: add managed resources tied to drm_device
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after a hotunplug while userspace has open
files and mmap'ed buffers). Give people what they want, but with more
correctness.
Mostly copied from devres.c, with types adjusted to fit drm_device and
a few simplifications - I didn't (yet) copy over everything. Since
the types don't match code sharing looked like a hopeless endeavour.
For now it's only super simplified, no groups, you can't remove
actions (but kfree exists, we'll need that soon). Plus all specific to
drm_device ofc, including the logging. Which I didn't bother to make
compile-time optional, since none of the other drm logging is compile
time optional either.
One tricky bit here is the chicken between allocating your
drm_device structure and initiliazing it with drm_dev_init. For
perfect onion unwinding we'd need to have the action to kfree the
allocation registered before drm_dev_init registers any of its own
release handlers. But drm_dev_init doesn't know where exactly the
drm_device is emebedded into the overall structure, and by the time it
returns it'll all be too late. And forcing drivers to be able clean up
everything except the one kzalloc is silly.
Work around this by having a very special final_kfree pointer. This
also avoids troubles with the list head possibly disappearing from
underneath us when we release all resources attached to the
drm_device.
v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless
shuffling while getting everything into shape.
v3: Add static to add/del_dr (Neil)
Move typo fix to the right patch (Neil)
v4: Enforce contract for drmm_add_final_kfree:
Use ksize() to check that the drm_device is indeed contained somewhere
in the final kfree(). Because we need that or the entire managed
release logic blows up in a pile of use-after-frees. Motivated by a
discussion with Laurent.
v5: Review from Laurent:
- %zu instead of casting size_t
- header guards
- sorting of includes
- guarding of data assignment if we didn't allocate it for a NULL
pointer
- delete spurious newline
- cast void* data parameter correctly in ->release call, no idea how
this even worked before
v6: Review from Sam
- Add the kerneldoc for the managed sub-struct back in, even if it
doesn't show up in the generated html somehow.
- Explain why __always_inline.
- Fix bisectability around the final kfree() in drm_dev_relase(). This
is just interim code which will disappear again.
- Some whitespace polish.
- Add debug output when drmm_add_action or drmm_kmalloc fail.
v7: My bisectability fix wasn't up to par as noticed by smatch.
v8: Remove unecessary {} around if else
v9: Use kstrdup_const, which requires kfree_const and introducing a free_dr()
helper (Thomas).
v10: kfree_const goes boom on the plain "kmalloc" assignment, somehow
we need to wrap that in kstrdup_const() too!! Also renumber revision
log, I somehow reset it midway thruh.
Cc: Thomas Zimmermann
Cc: Dan Carpenter
Cc: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Neil Armstrong
Cc: "Rafael J. Wysocki"
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-internals.rst | 6 +
drivers/gpu/drm/Makefile| 3 +-
drivers/gpu/drm/drm_drv.c | 15 ++-
drivers/gpu/drm/drm_internal.h | 3 +
drivers/gpu/drm/drm_managed.c | 193
include/drm/drm_device.h| 15 +++
include/drm/drm_managed.h | 30 +
include/drm/drm_print.h | 6 +
8 files changed, 267 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/drm_managed.c
create mode 100644 include/drm/drm_managed.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index a73320576ca9..a6b6145fda78 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder is
shared with
other BARs, so leaving it mapped could cause undesired behaviour like
hangs or memory corruption.
+Managed Resources
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_managed.c
+ :doc: managed resources
+
Bus-specific Device Registration and PCI Support
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7f72ef5e7811..183c60048307 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,8 @@ drm-y :=drm_auth.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o
+
Re: [PATCH] drm/vkms: enable cursor by default
Hi Melissa, First of all, thanks for your patch. I agree with you, it makes more sense to me if we enable cursors by default. I don't remember why we decided to add it as a disabled by default. Reviewed-by: Rodrigo Siqueira On 03/21, Melissa Wen wrote: > This patch proposes a change in the behavior of the cursor to enable it as > soon as the vkms module is added. Enabling the cursor by default appears > to be an expected and more friendly behavior, especially when running IGT > tests. > > Signed-off-by: Melissa Wen > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 860de052e820..6e6feecf7f20 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -34,7 +34,7 @@ > > static struct vkms_device *vkms_device; > > -bool enable_cursor; > +bool enable_cursor = true; > module_param_named(enable_cursor, enable_cursor, bool, 0444); > MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support"); > > -- > 2.25.1 > -- Rodrigo Siqueira https://siqueira.tech signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Align a comment block
Hi,
Reviewed-by: Rodrigo Siqueira
On 03/19, Igor Matheus Andrade Torrente wrote:
> Fix a checkpatch warning caused by a misaligned comment block.
>
> Signed-off-by: Igor Matheus Andrade Torrente
>
> ---
> Changes in v2:
> - Change subject text
>
> Changes in V3
> - Fix a typo in the commit message
>
> drivers/gpu/drm/drm_gem.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index a9e4a610445a..564acc1f4030 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -222,10 +222,10 @@ drm_gem_object_handle_put_unlocked(struct
> drm_gem_object *obj)
> return;
>
> /*
> - * Must bump handle count first as this may be the last
> - * ref, in which case the object would disappear before we
> - * checked for a name
> - */
> + * Must bump handle count first as this may be the last
> + * ref, in which case the object would disappear before we
> + * checked for a name
> + */
>
> mutex_lock(>object_name_lock);
> if (--obj->handle_count == 0) {
> --
> 2.20.1
>
--
Rodrigo Siqueira
https://siqueira.tech
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/22] drm/vkms: Use simple encoder
Hi Thomas,
First of all, thanks for your patch!
I applied all your series, compiled it, and when I tried
`make INSTALL_MOD_PATH=/PATH/ modules_instal` I got the following
message:
depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
depmod: ERROR: Found 2 modules in dependency cycles!
make: *** [Makefile:1317: _modinst_post] Error 1
I cleaned up my local files and tried again, but I got the same error;
If I just use `drm-misc-next` everything is fine. Did I miss something?
Thanks
On 03/05, Thomas Zimmermann wrote:
> The vkms driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/vkms/vkms_output.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index fb1941a6522c..85afb77e97f0 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -3,6 +3,7 @@
> #include "vkms_drv.h"
> #include
> #include
> +#include
>
> static void vkms_connector_destroy(struct drm_connector *connector)
> {
> @@ -17,10 +18,6 @@ static const struct drm_connector_funcs
> vkms_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> -static const struct drm_encoder_funcs vkms_encoder_funcs = {
> - .destroy = drm_encoder_cleanup,
> -};
> -
> static int vkms_conn_get_modes(struct drm_connector *connector)
> {
> int count;
> @@ -70,8 +67,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
>
> drm_connector_helper_add(connector, _conn_helper_funcs);
>
> - ret = drm_encoder_init(dev, encoder, _encoder_funcs,
> -DRM_MODE_ENCODER_VIRTUAL, NULL);
> + ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_VIRTUAL);
> if (ret) {
> DRM_ERROR("Failed to init encoder\n");
> goto err_encoder;
> --
> 2.25.1
>
--
Rodrigo Siqueira
https://siqueira.tech
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 10/12] backlight: pwm_bl: Use 64-bit division function
On Fri, 20 Mar 2020, Lee Jones wrote: > On Thu, 19 Mar 2020, Guru Das Srinagesh wrote: > > > Since the PWM framework is switching struct pwm_state.period's datatype > > to u64, prepare for this transition by using div_u64 to handle a 64-bit > > dividend instead of a straight division operation. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Bartlomiej Zolnierkiewicz > > Cc: linux-...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fb...@vger.kernel.org > > > > Signed-off-by: Guru Das Srinagesh > > Reviewed-by: Daniel Thompson > > --- > > drivers/video/backlight/pwm_bl.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > Can this patch be taken on its own? Hello ... > > diff --git a/drivers/video/backlight/pwm_bl.c > > b/drivers/video/backlight/pwm_bl.c > > index efb4efc..3e5dbcf 100644 > > --- a/drivers/video/backlight/pwm_bl.c > > +++ b/drivers/video/backlight/pwm_bl.c > > @@ -625,7 +625,8 @@ static int pwm_backlight_probe(struct platform_device > > *pdev) > > pb->scale = data->max_brightness; > > } > > > > - pb->lth_brightness = data->lth_brightness * (state.period / pb->scale); > > + pb->lth_brightness = data->lth_brightness * (div_u64(state.period, > > + pb->scale)); > > > > props.type = BACKLIGHT_RAW; > > props.max_brightness = data->max_brightness; > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/21] drm: mxsfb: Enable vblank handling
On 2020-03-24 00:08, Stefan Agner wrote:
> On 2020-03-09 20:52, Laurent Pinchart wrote:
>> Enable vblank handling when the CRTC is turned on and disable it when it
>> is turned off. This requires moving vblank init after the KMS pipeline
>> initialisation, otherwise drm_vblank_init() gets called with 0 CRTCs.
>>
>> Signed-off-by: Laurent Pinchart
>
> With this patch applied I start to get system resets on my Colibri iMX7
> test device during system boot shortly after initializing mxsfb. It
> happens not on every boot, but rather often, I would say every second or
> third. From what I can tell the interrupt handling should be safe, but
> it seems that every now and then something races. Any idea what that
> could be?
Disregard this: It seems that my power supply was a bit too weak which
lead to the system reset every now and then. With enough juice, I run
now quite some boots with the complete patchset applied without seeing
any issues.
Sorry about that.
--
Stefan
>
> --
> Stefan
>
>> ---
>> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +--
>> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
>> 2 files changed, 14 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> index e324bd2a63a5..72b4f6a947a4 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> @@ -160,12 +160,6 @@ static int mxsfb_load(struct drm_device *drm,
>> unsigned long flags)
>>
>> pm_runtime_enable(drm->dev);
>>
>> -ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
>> -if (ret < 0) {
>> -dev_err(drm->dev, "Failed to initialise vblank\n");
>> -goto err_vblank;
>> -}
>> -
>> /* Modeset init */
>> drm_mode_config_init(drm);
>>
>> @@ -175,6 +169,15 @@ static int mxsfb_load(struct drm_device *drm,
>> unsigned long flags)
>> goto err_vblank;
>> }
>>
>> +ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
>> +if (ret < 0) {
>> +dev_err(drm->dev, "Failed to initialise vblank\n");
>> +goto err_vblank;
>> +}
>> +
>> +/* Start with vertical blanking interrupt reporting disabled. */
>> +drm_crtc_vblank_off(>crtc);
>> +
>> ret = mxsfb_attach_bridge(mxsfb);
>> if (ret) {
>> dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> index ac2696c8483d..640305fb1068 100644
>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>> @@ -322,8 +322,10 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> dma_addr_t paddr;
>>
>> pm_runtime_get_sync(drm->dev);
>> -
>> mxsfb_enable_axi_clk(mxsfb);
>> +
>> +drm_crtc_vblank_on(crtc);
>> +
>> mxsfb_crtc_mode_set_nofb(mxsfb);
>>
>> /* Write cur_buf as well to avoid an initial corrupt frame */
>> @@ -353,6 +355,8 @@ static void mxsfb_crtc_atomic_disable(struct drm_crtc
>> *crtc,
>> }
>> spin_unlock_irq(>event_lock);
>>
>> +drm_crtc_vblank_off(crtc);
>> +
>> mxsfb_disable_axi_clk(mxsfb);
>> pm_runtime_put_sync(drm->dev);
>> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM
Yeah, sure go ahead.
It's just that I am out of office because of COVID-19 and won't be able to help
if it goes up in flames :)
Cheers,
Christian
Am 24.03.2020 11:03 schrieb "Thomas Hellström (VMware)"
:
On 3/4/20 11:28 AM, Thomas Hellström (VMware) wrote:
> In order to reduce CPU usage [1] and in theory TLB misses this patchset
> enables
> huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
>
> Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
> take the same path as DAX when splitting huge- and giant page table entries,
> (which currently means zapping the page-table entry and rely on re-faulting).
>
> Patch 3 makes the mm code split existing huge page-table entries
> on huge_fault fallbacks. Typically on COW or on buffer-objects that want
> write-notify. COW and write-notification is always done on the lowest
> page-table level. See the patch log message for additional considerations.
>
> Patch 4 introduces functions to allow the graphics drivers to manipulate
> the caching- and encryption flags of huge page-table entries without ugly
> hacks.
>
> Patch 5 implements the huge_fault handler in TTM.
> This enables huge page-table entries, provided that the kernel is configured
> to support transhuge pages, either by default or using madvise().
> However, they are unlikely to be inserted unless the kernel buffer object
> pfns and user-space addresses align perfectly. There are various options
> here, but since buffer objects that reside in system pages typically start
> at huge page boundaries if they are backed by huge pages, we try to enforce
> buffer object starting pfns and user-space addresses to be huge page-size
> aligned if their size exceeds a huge page-size. If pud-size transhuge
> ("giant") pages are enabled by the arch, the same holds for those.
>
> Patch 6 implements a specialized huge_fault handler for vmwgfx.
> The vmwgfx driver may perform dirty-tracking and needs some special code
> to handle that correctly.
>
> Patch 7 implements a drm helper to align user-space addresses according
> to the above scheme, if possible.
>
> Patch 8 implements a TTM range manager for vmwgfx that does the same for
> graphics IO memory. This may later be reused by other graphics drivers
> if necessary.
>
> Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
> A similar change is needed for graphics drivers that want a reasonable
> likelyhood of actually using huge page-table entries.
>
> If a buffer object size is not huge-page or giant-page aligned,
> its size will NOT be inflated by this patchset. This means that the buffer
> object tail will use smaller size page-table entries and thus no memory
> overhead occurs. Drivers that want to pay the memory overhead price need to
> implement their own scheme to inflate buffer-object sizes.
>
> PMD size huge page-table-entries have been tested with vmwgfx and found to
> work well both with system memory backed and IO memory backed buffer objects.
>
> PUD size giant page-table-entries have seen limited (fault and COW) testing
> using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
> TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
> memory resources.
>
> Comments and suggestions welcome.
> Thomas
>
> Changes since RFC:
> * Check for buffer objects present in contigous IO Memory (Christian König)
> * Rebased on the vmwgfx emulated coherent memory functionality. That rebase
>adds patch 5.
> Changes since v1:
> * Make the new TTM range manager vmwgfx-specific. (Christian König)
> * Minor fixes for configs that don't support or only partially support
>transhuge pages.
> Changes since v2:
> * Minor coding style and doc fixes in patch 5/9 (Christian König)
> * Patch 5/9 doesn't touch mm. Remove from the patch title.
> Changes since v3:
> * Added reviews and acks
> * Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch
>specific code.
> Changes since v4:
> * Added timings (Andrew Morton)
> * Updated function documentation (Andrew Morton)
> Changes since v6:
> * Fix drm build error with !CONFIG_MMU
>
> [1]
> The below test program generates the following gnu time output when run on a
> vmwgfx-enabled kernel without the patch series:
>
> 4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k
> 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
>
> and with the patch series:
>
> 1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k
> 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
>
> A consistent number of reduced graphics page-faults can be seen with normal
> graphics applications, but due to the aggressive buffer object caching in
> vmwgfx user-space drivers the CPU time reduction is within the error marginal.
>
> #include
> #include
> #include
> #include
>
> static void checkerr(int ret, const char *name)
> {
>if (ret < 0) {
> perror(name);
>
Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM
On 3/4/20 11:28 AM, Thomas Hellström (VMware) wrote:
In order to reduce CPU usage [1] and in theory TLB misses this patchset enables
huge- and giant page-table entries for TTM and TTM-enabled graphics drivers.
Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm code
take the same path as DAX when splitting huge- and giant page table entries,
(which currently means zapping the page-table entry and rely on re-faulting).
Patch 3 makes the mm code split existing huge page-table entries
on huge_fault fallbacks. Typically on COW or on buffer-objects that want
write-notify. COW and write-notification is always done on the lowest
page-table level. See the patch log message for additional considerations.
Patch 4 introduces functions to allow the graphics drivers to manipulate
the caching- and encryption flags of huge page-table entries without ugly
hacks.
Patch 5 implements the huge_fault handler in TTM.
This enables huge page-table entries, provided that the kernel is configured
to support transhuge pages, either by default or using madvise().
However, they are unlikely to be inserted unless the kernel buffer object
pfns and user-space addresses align perfectly. There are various options
here, but since buffer objects that reside in system pages typically start
at huge page boundaries if they are backed by huge pages, we try to enforce
buffer object starting pfns and user-space addresses to be huge page-size
aligned if their size exceeds a huge page-size. If pud-size transhuge
("giant") pages are enabled by the arch, the same holds for those.
Patch 6 implements a specialized huge_fault handler for vmwgfx.
The vmwgfx driver may perform dirty-tracking and needs some special code
to handle that correctly.
Patch 7 implements a drm helper to align user-space addresses according
to the above scheme, if possible.
Patch 8 implements a TTM range manager for vmwgfx that does the same for
graphics IO memory. This may later be reused by other graphics drivers
if necessary.
Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx driver.
A similar change is needed for graphics drivers that want a reasonable
likelyhood of actually using huge page-table entries.
If a buffer object size is not huge-page or giant-page aligned,
its size will NOT be inflated by this patchset. This means that the buffer
object tail will use smaller size page-table entries and thus no memory
overhead occurs. Drivers that want to pay the memory overhead price need to
implement their own scheme to inflate buffer-object sizes.
PMD size huge page-table-entries have been tested with vmwgfx and found to
work well both with system memory backed and IO memory backed buffer objects.
PUD size giant page-table-entries have seen limited (fault and COW) testing
using a modified kernel (to support 1GB page allocations) and a fake vmwgfx
TTM memory type. The vmwgfx driver does otherwise not support 1GB-size IO
memory resources.
Comments and suggestions welcome.
Thomas
Changes since RFC:
* Check for buffer objects present in contigous IO Memory (Christian König)
* Rebased on the vmwgfx emulated coherent memory functionality. That rebase
adds patch 5.
Changes since v1:
* Make the new TTM range manager vmwgfx-specific. (Christian König)
* Minor fixes for configs that don't support or only partially support
transhuge pages.
Changes since v2:
* Minor coding style and doc fixes in patch 5/9 (Christian König)
* Patch 5/9 doesn't touch mm. Remove from the patch title.
Changes since v3:
* Added reviews and acks
* Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of arch
specific code.
Changes since v4:
* Added timings (Andrew Morton)
* Updated function documentation (Andrew Morton)
Changes since v6:
* Fix drm build error with !CONFIG_MMU
[1]
The below test program generates the following gnu time output when run on a
vmwgfx-enabled kernel without the patch series:
4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresident)k
0inputs+0outputs (0major+640077minor)pagefaults 0swaps
and with the patch series:
1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresident)k
0inputs+0outputs (0major+20079minor)pagefaults 0swaps
A consistent number of reduced graphics page-faults can be seen with normal
graphics applications, but due to the aggressive buffer object caching in
vmwgfx user-space drivers the CPU time reduction is within the error marginal.
#include
#include
#include
#include
static void checkerr(int ret, const char *name)
{
if (ret < 0) {
perror(name);
exit(-1);
}
}
int main(int agc, const char *argv[])
{
struct drm_mode_create_dumb c_arg = {0};
struct drm_mode_map_dumb m_arg = {0};
struct drm_mode_destroy_dumb d_arg = {0};
int ret, i, fd;
void *map;
fd = open("/dev/dri/card0", O_RDWR);
checkerr(fd, argv[0]);
for (i = 0; i < 1; ++i) {
c_arg.bpp = 32;
c_arg.width = 1024;
Re: [PATCH] drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
Hi i915 maintainers,
On Mon, Mar 23, 2020 at 11:12 AM Masahiro Yamada wrote:
>
> CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
> Use SSE4.1 movntdqa to accelerate reads from WC memory").
>
> We raise the minimal supported binutils version from time to time.
> The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
> required binutils version to 2.21").
>
> I confirmed the code in $(call as-instr,...) can be assembled by the
> binutils 2.21 assembler and also by Clang's integrated assembler.
>
> Remove CONFIG_AS_MOVNTDQA, which is always defined.
>
> Signed-off-by: Masahiro Yamada
> ---
Please discard this.
I decided to fold this (10/16) into the following big series
because I was suggested to do so.
https://lore.kernel.org/patchwork/project/lkml/list/?series=435391
--
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 49/51] drm/udl: Drop explicit drm_mode_config_cleanup call
Am 23.03.20 um 15:49 schrieb Daniel Vetter:
> It's right above the drm_dev_put().
>
> This allows us to delete a bit of onion unwinding in
> udl_modeset_init().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup is check the new error code for _init().
>
> v2: Explain why this cleanup is possible (Laurent).
>
> v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
>
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Sean Paul
> Cc: Daniel Vetter
> Cc: Thomas Zimmermann
> Cc: Emil Velikov
> Cc: Gerd Hoffmann
> Cc: "Noralf Trønnes"
> Cc: Thomas Gleixner
> Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_drv.c | 1 -
> drivers/gpu/drm/udl/udl_drv.h | 1 -
> drivers/gpu/drm/udl/udl_modeset.c | 21 ++---
> 3 files changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index 8b78c356beb5..b447fb053e78 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -37,7 +37,6 @@ DEFINE_DRM_GEM_FOPS(udl_driver_fops);
> static void udl_driver_release(struct drm_device *dev)
> {
> udl_fini(dev);
> - udl_modeset_cleanup(dev);
> }
>
> static struct drm_driver driver = {
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index e67227c44cc4..1de7eb1b6aac 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -68,7 +68,6 @@ struct udl_device {
>
> /* modeset */
> int udl_modeset_init(struct drm_device *dev);
> -void udl_modeset_cleanup(struct drm_device *dev);
> struct drm_connector *udl_connector_init(struct drm_device *dev);
>
> struct urb *udl_get_urb(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index d59ebac70b15..8cad01f3d163 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -468,7 +468,9 @@ int udl_modeset_init(struct drm_device *dev)
> struct drm_connector *connector;
> int ret;
>
> - drm_mode_config_init(dev);
> + ret = drmm_mode_config_init(dev);
> + if (ret)
> + return ret;
>
> dev->mode_config.min_width = 640;
> dev->mode_config.min_height = 480;
> @@ -482,10 +484,8 @@ int udl_modeset_init(struct drm_device *dev)
> dev->mode_config.funcs = _mode_funcs;
>
> connector = udl_connector_init(dev);
> - if (IS_ERR(connector)) {
> - ret = PTR_ERR(connector);
> - goto err_drm_mode_config_cleanup;
> - }
> + if (IS_ERR(connector))
> + return PTR_ERR(connector);
>
> format_count = ARRAY_SIZE(udl_simple_display_pipe_formats);
>
> @@ -494,18 +494,9 @@ int udl_modeset_init(struct drm_device *dev)
> udl_simple_display_pipe_formats,
> format_count, NULL, connector);
> if (ret)
> - goto err_drm_mode_config_cleanup;
> + return ret;
>
> drm_mode_config_reset(dev);
>
> return 0;
> -
> -err_drm_mode_config_cleanup:
> - drm_mode_config_cleanup(dev);
> - return ret;
> -}
> -
> -void udl_modeset_cleanup(struct drm_device *dev)
> -{
> - drm_mode_config_cleanup(dev);
> }
>
--
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 22/51] drm: manage drm_minor cleanup with drmm_
Hi
Am 23.03.20 um 15:49 schrieb Daniel Vetter:
> The cleanup here is somewhat tricky, since we can't tell apart the
> allocated minor index from 0. So register a cleanup action first, and
> if the index allocation fails, unregister that cleanup action again to
> avoid bad mistakes.
>
> The kdev for the minor already handles NULL, so no problem there.
>
> Hence add drmm_remove_action() to the drm_managed library.
>
> v2: Make pointer math around void ** consistent with what Laurent
> suggested.
>
> v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> because of some questions from Thomas. This also means we need to move
> the drmm_add_action_or_reset helper earlier in the series.
>
> Cc: Thomas Zimmermann
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
This code looks easier to understand than the previous patch.
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_drv.c | 70 ---
> drivers/gpu/drm/drm_managed.c | 14 +++
> include/drm/drm_managed.h | 9 -
> 3 files changed, 46 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a710c53d13a8..25fc2107057c 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
> drm_device *dev,
> }
> }
>
> +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> +{
> + struct drm_minor *minor = data;
> + unsigned long flags;
> +
> + put_device(minor->kdev);
> +
> + spin_lock_irqsave(_minor_lock, flags);
> + idr_remove(_minors_idr, minor->index);
> + spin_unlock_irqrestore(_minor_lock, flags);
> +}
> +
> static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> {
> struct drm_minor *minor;
> unsigned long flags;
> int r;
>
> - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> if (!minor)
> return -ENOMEM;
>
> @@ -117,46 +129,19 @@ static int drm_minor_alloc(struct drm_device *dev,
> unsigned int type)
> idr_preload_end();
>
> if (r < 0)
> - goto err_free;
> + return r;
>
> - minor->index = r;
> + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> + if (r)
> + return r;
>
> + minor->index = r;
> minor->kdev = drm_sysfs_minor_alloc(minor);
> - if (IS_ERR(minor->kdev)) {
> - r = PTR_ERR(minor->kdev);
> - goto err_index;
> - }
> + if (IS_ERR(minor->kdev))
> + return PTR_ERR(minor->kdev);
>
> *drm_minor_get_slot(dev, type) = minor;
> return 0;
> -
> -err_index:
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -err_free:
> - kfree(minor);
> - return r;
> -}
> -
> -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> -{
> - struct drm_minor **slot, *minor;
> - unsigned long flags;
> -
> - slot = drm_minor_get_slot(dev, type);
> - minor = *slot;
> - if (!minor)
> - return;
> -
> - put_device(minor->kdev);
> -
> - spin_lock_irqsave(_minor_lock, flags);
> - idr_remove(_minors_idr, minor->index);
> - spin_unlock_irqrestore(_minor_lock, flags);
> -
> - kfree(minor);
> - *slot = NULL;
> }
>
> static int drm_minor_register(struct drm_device *dev, unsigned int type)
> @@ -678,16 +663,16 @@ int drm_dev_init(struct drm_device *dev,
> if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> - goto err_minors;
> + goto err;
> }
>
> ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> if (ret)
> - goto err_minors;
> + goto err;
>
> ret = drm_legacy_create_map_hash(dev);
> if (ret)
> - goto err_minors;
> + goto err;
>
> drm_legacy_ctxbitmap_init(dev);
>
> @@ -695,7 +680,7 @@ int drm_dev_init(struct drm_device *dev,
> ret = drm_gem_init(dev);
> if (ret) {
> DRM_ERROR("Cannot initialize graphics execution manager
> (GEM)\n");
> - goto err_ctxbitmap;
> + goto err;
> }
> }
>
> @@ -708,10 +693,6 @@ int drm_dev_init(struct drm_device *dev,
> err_setunique:
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
> -err_ctxbitmap:
> -err_minors:
> - drm_minor_free(dev, DRM_MINOR_PRIMARY);
> - drm_minor_free(dev, DRM_MINOR_RENDER);
> err:
> drm_managed_release(dev);
>
> @@ -776,9 +757,6 @@ void drm_dev_fini(struct drm_device *dev)
>
> if (drm_core_check_feature(dev,
[PATCH 10/16] drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
Use SSE4.1 movntdqa to accelerate reads from WC memory").
We raise the minimal supported binutils version from time to time.
The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
required binutils version to 2.21").
I confirmed the code in $(call as-instr,...) can be assembled by the
binutils 2.21 assembler and also by LLVM integrated assembler.
Remove CONFIG_AS_MOVNTDQA, which is always defined.
Signed-off-by: Masahiro Yamada
Reviewed-by: Nick Desaulniers
---
drivers/gpu/drm/i915/Makefile | 3 ---
drivers/gpu/drm/i915/i915_memcpy.c | 5 -
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a1f2411aa21b..e559e53fc634 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,9 +28,6 @@ subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
-subdir-ccflags-y += \
- $(call as-instr,movntdqa (%eax)$(comma)%xmm0,-DCONFIG_AS_MOVNTDQA)
-
subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers/gpu/drm/i915/i915_memcpy.c
index fdd550405fd3..7b3b83bd5ab8 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -35,7 +35,6 @@
static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
-#ifdef CONFIG_AS_MOVNTDQA
static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
{
kernel_fpu_begin();
@@ -93,10 +92,6 @@ static void __memcpy_ntdqu(void *dst, const void *src,
unsigned long len)
kernel_fpu_end();
}
-#else
-static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len) {}
-static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len) {}
-#endif
/**
* i915_memcpy_from_wc: perform an accelerated *aligned* read from WC
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/16] x86, crypto: remove always-defined CONFIG_AS_* and cosolidate Kconfig/Makefiles
This series of cleanups was prompted by Linus:
https://lkml.org/lkml/2020/3/12/726
First, this series drop always-on CONFIG_AS_* options.
Some of those options were introduced in old days.
For example, the check for CONFIG_AS_CFI dates back to 2006.
We raise the minimal tool versions from time to time.
Currently, we require binutils 2.21
(and we plan to bump it to 2.23 for v5.7-rc1).
After cleaning away the old checks,
as-instr calls are moved to Kconfig from Makefiles.
(patch 11)
This allows more Kconfig / Makefile cleanups.
Patch 12 is complex, but I double-checked it does the equivalent.
Patch 14 bumps the binutils version to 2.23,
and patch 15 removes more CONFIG_AS_* options.
I folded all relevanet patches into this series,
as suggested by Jason A. Donenfeld.
If x86 maintainers take care of this series, that's good.
If it is OK to queue this up to Kbuild tree,
I will send a pull request to Linus.
Thank you.
Borislav Petkov (1):
Documentation/changes: Raise minimum supported binutils version to
2.23
Jason A. Donenfeld (4):
x86: probe assembler capabilities via kconfig instead of makefile
crypto: x86 - rework configuration based on Kconfig
crypto: curve25519 - do not pollute dispatcher based on assembler
x86: update AS_* macros to binutils >=2.23, supporting ADX and AVX2
Masahiro Yamada (11):
lib/raid6/test: fix build on distros whose /bin/sh is not bash
x86: remove unneeded defined(__ASSEMBLY__) check from asm/dwarf2.h
x86: remove always-defined CONFIG_AS_CFI
x86: remove unneeded (CONFIG_AS_)CFI_SIGNAL_FRAME
x86: remove always-defined CONFIG_AS_CFI_SECTIONS
x86: remove always-defined CONFIG_AS_SSSE3
x86: remove always-defined CONFIG_AS_AVX
x86: add comments about the binutils version to support code in
as-instr
x86: replace arch macros from compiler with CONFIG_X86_{32,64}
drm/i915: remove always-defined CONFIG_AS_MOVNTDQA
crypto: x86 - clean up poly1305-x86_64-cryptogams.S by 'make clean'
Documentation/process/changes.rst | 4 +-
arch/x86/Kconfig | 2 +
arch/x86/Kconfig.assembler| 14 ++
arch/x86/Makefile | 22 ---
arch/x86/crypto/Makefile | 162 +++---
arch/x86/crypto/aesni-intel_avx-x86_64.S | 6 -
arch/x86/crypto/aesni-intel_glue.c| 21 +--
arch/x86/crypto/blake2s-core.S| 2 -
arch/x86/crypto/chacha_glue.c | 6 +-
arch/x86/crypto/poly1305-x86_64-cryptogams.pl | 16 --
arch/x86/crypto/poly1305_glue.c | 11 +-
arch/x86/crypto/sha1_ssse3_asm.S | 4 -
arch/x86/crypto/sha1_ssse3_glue.c | 13 --
arch/x86/crypto/sha256-avx-asm.S | 3 -
arch/x86/crypto/sha256-avx2-asm.S | 3 -
arch/x86/crypto/sha256_ssse3_glue.c | 12 --
arch/x86/crypto/sha512-avx-asm.S | 2 -
arch/x86/crypto/sha512-avx2-asm.S | 3 -
arch/x86/crypto/sha512_ssse3_glue.c | 10 --
arch/x86/include/asm/dwarf2.h | 44 -
arch/x86/include/asm/xor_avx.h| 9 -
drivers/gpu/drm/i915/Makefile | 3 -
drivers/gpu/drm/i915/i915_memcpy.c| 5 -
include/crypto/curve25519.h | 6 +-
kernel/signal.c | 2 +-
lib/raid6/algos.c | 12 +-
lib/raid6/avx2.c | 4 -
lib/raid6/recov_avx2.c| 6 -
lib/raid6/recov_ssse3.c | 6 -
lib/raid6/test/Makefile | 9 +-
30 files changed, 98 insertions(+), 324 deletions(-)
create mode 100644 arch/x86/Kconfig.assembler
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
Hi Am 14.03.20 um 11:59 schrieb Krzysztof Kozlowski: > On Thu, Mar 12, 2020 at 11:49:05AM +0100, Thomas Zimmermann wrote: >> Hi Krzysztof, >> >> I just received a resend email from 3 weeks ago :/ >> >> Do you want me to merge the mgag200 patch into drm-misc-next? > > Thanks but it depends on the first patch in the series so either it > could go with your ack through other tree or I will send it later (once > 1st patch gets to mainline). Ok. You're welcome to send it through any tree that works best for you. mgag200 sees only little change. I wouldn't expect major merge conflicts, if any. Best regards Thomas > > > Best regards, > Krzysztof > -- 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 v1 0/3] drm: drm_encoder_init() => drm_encoder_init_funcs()
Hi Sam Am 13.03.20 um 21:17 schrieb Sam Ravnborg: > Thomas Zimmermann had made a nice patch-set that introduced > drm_simple_encoder_init() which is already present in drm-misc-next. > > While looking at this it was suddenly obvious to me that > this was functionalty that really should be included in drm_encoder.c > The case where the core could handle the callback is pretty > common and not part of the simple pipe line. The original patchset put the new function into the core implementation and was shot down for this. So it ended up in the simple-KMS helpers. > > So after some dialog on dri-devel the conclusion was to go for > a change like this: > > drm_encoder_init_funcs() for all users that specified a > drm_encoder_funcs to extend the functionality. > > drm_encoder_init() for all users that did not > need to extend the basic functionality with > drm_encoder_funcs. TBH, my take-away was to keep the core as it is ans maybe rename drm_simple_encoder_init() to some better name. > > A similar approach with a _funcs() prefix is used elsewhere in drm/ IMHO, there are a few things to consider: From grepping, I could only find drm_gem_fb_create_with_funcs(). And the proposed change would make the encoder's function name inconsistent with drm_connector_init(), drm_crtc_init(), and others. Finally, drm_connector_init_with_ddc() was criticiced for being mid-layerish and could lead to many combinations of postfixes (e.g., _with_funcs(), with_ddc(), _with_ddc_and_funcs(), etc). If there is consent that the drm_simple_encoder_init() should go away, I'd propose to change drm_encoder_init(). It could use a default implementation for funcs, if no funcs argument has been specified. We already have such behavior for some GEM callbacks. In later patches, drm_gem_fb_create_with_funcs() and drm_connector_init_with_ddc() could go away as well. Best regards Thomas > > This required a rename of the existing users, and > a follow-up patch that moves drm_simple_encoder_init() > to drm_encoder.c > > Patches 3 in this set demonstrate the use of drm_encoder_init(). > There are many more drivers that can be converted as Thomas > has already demonstrated. > > This is all based on work done by Thomas Zimmermann, > I just wanted to implement my suggestion so > we could select the best way forward. > > Note: Daniel Vetter has hinted the approach implemented > here smelled like middle-layer. > IMO this is not so, it is just a way to handle cleanup > for the simple cases. > > Sam > > > Sam Ravnborg (3): > drm: drm_encoder_init() => drm_encoder_init_funcs() > drm: drm_simple_encoder_init() => drm_encoder_init() > drm/atmel-hlcdc: Use drm_encoder_init() > > drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 28 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 28 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 28 ++--- > drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 28 ++--- > drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++--- > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 ++--- > drivers/gpu/drm/arc/arcpgu_hdmi.c | 4 +- > drivers/gpu/drm/arc/arcpgu_sim.c | 4 +- > drivers/gpu/drm/ast/ast_mode.c | 3 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 8 +--- > drivers/gpu/drm/drm_encoder.c | 49 > +++--- > drivers/gpu/drm/drm_encoder_slave.c| 2 +- > drivers/gpu/drm/drm_simple_kms_helper.c| 45 +--- > drivers/gpu/drm/drm_writeback.c| 6 +-- > drivers/gpu/drm/exynos/exynos_dp.c | 4 +- > drivers/gpu/drm/exynos/exynos_drm_dpi.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 4 +- > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 4 +- > drivers/gpu/drm/gma500/cdv_intel_crt.c | 5 ++- > drivers/gpu/drm/gma500/cdv_intel_dp.c | 4 +- > drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 4 +- > drivers/gpu/drm/gma500/cdv_intel_lvds.c| 6 +-- > drivers/gpu/drm/gma500/mdfld_dsi_dpi.c | 7 ++-- > drivers/gpu/drm/gma500/oaktrail_hdmi.c | 6 +-- > drivers/gpu/drm/gma500/oaktrail_lvds.c | 4 +- > drivers/gpu/drm/gma500/psb_intel_lvds.c| 6 +-- > drivers/gpu/drm/gma500/psb_intel_sdvo.c| 4 +- > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 4 +- > drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 4 +- > drivers/gpu/drm/i2c/tda998x_drv.c | 5 ++- > drivers/gpu/drm/i915/display/icl_dsi.c | 4 +- > drivers/gpu/drm/i915/display/intel_crt.c
[PATCH V4 0/4] Add support for WLED5
Currently, WLED driver supports only WLED4 peripherals that is present on pmi8998 and pm660L. This patch series converts the existing WLED4 bindings from .txt to .yaml format and adds the support for WLED5 peripheral that is present on PM8150L. PM8150L WLED supports the following. - Two modulators and each sink can use any of the modulator - Multiple CABC selection options - Multiple brightness width selection (12 bits to 15 bits) Changes from V1: - Rebased on top of the below commit. backlight: qcom-wled: Fix unsigned comparison to zero Changes from V2: - Addressed Bjorn's comments by splitting the WLED4 changes in a seperate patch. - Added WLED5 auto calibration support Changes from V3: - Addressed comments from Daniel Thompson and Rob Herring - Seperated the WLED5 bindings from the driver changes - Squashed wled5 auto string detection and wled5 basic changes to avoid the NULL callback function pointer issue. Kiran Gunda (3): backlight: qcom-wled: convert the wled bindings to .yaml format backlight: qcom-wled: Add callback functions backlight: qcom-wled: Add WLED5 bindings Subbaraman Narayanamurthy (1): backlight: qcom-wled: Add support for WLED5 peripheral in PM8150L .../bindings/leds/backlight/qcom-wled.txt | 154 -- .../bindings/leds/backlight/qcom-wled.yaml | 223 drivers/video/backlight/qcom-wled.c| 613 ++--- 3 files changed, 764 insertions(+), 226 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 hmm 2/9] mm/hmm: return the fault type from hmm_pte_need_fault()
From: Jason Gunthorpe
Using two bools instead of flags return is not necessary and leads to
bugs. Returning a value is easier for the compiler to check and easier to
pass around the code flow.
Convert the two bools into flags and push the change to all callers.
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 183 ---
1 file changed, 81 insertions(+), 102 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 3a2610e0713329..2a0eda1534bcda 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -32,6 +32,12 @@ struct hmm_vma_walk {
unsigned intflags;
};
+enum {
+ HMM_NEED_FAULT = 1 << 0,
+ HMM_NEED_WRITE_FAULT = HMM_NEED_FAULT | (1 << 1),
+ HMM_NEED_ALL_BITS = HMM_NEED_FAULT | HMM_NEED_WRITE_FAULT,
+};
+
static int hmm_pfns_fill(unsigned long addr, unsigned long end,
struct hmm_range *range, enum hmm_pfn_value_e value)
{
@@ -49,8 +55,7 @@ static int hmm_pfns_fill(unsigned long addr, unsigned long
end,
* hmm_vma_fault() - fault in a range lacking valid pmd or pte(s)
* @addr: range virtual start address (inclusive)
* @end: range virtual end address (exclusive)
- * @fault: should we fault or not ?
- * @write_fault: write fault ?
+ * @required_fault: HMM_NEED_* flags
* @walk: mm_walk structure
* Return: -EBUSY after page fault, or page fault error
*
@@ -58,8 +63,7 @@ static int hmm_pfns_fill(unsigned long addr, unsigned long
end,
* or whenever there is no page directory covering the virtual address range.
*/
static int hmm_vma_fault(unsigned long addr, unsigned long end,
- bool fault, bool write_fault,
- struct mm_walk *walk)
+unsigned int required_fault, struct mm_walk *walk)
{
struct hmm_vma_walk *hmm_vma_walk = walk->private;
struct hmm_range *range = hmm_vma_walk->range;
@@ -68,13 +72,13 @@ static int hmm_vma_fault(unsigned long addr, unsigned long
end,
unsigned long i = (addr - range->start) >> PAGE_SHIFT;
unsigned int fault_flags = FAULT_FLAG_REMOTE;
- WARN_ON_ONCE(!fault && !write_fault);
+ WARN_ON_ONCE(!required_fault);
hmm_vma_walk->last = addr;
if (!vma)
goto out_error;
- if (write_fault) {
+ if ((required_fault & HMM_NEED_WRITE_FAULT) == HMM_NEED_WRITE_FAULT) {
if (!(vma->vm_flags & VM_WRITE))
return -EPERM;
fault_flags |= FAULT_FLAG_WRITE;
@@ -91,14 +95,13 @@ static int hmm_vma_fault(unsigned long addr, unsigned long
end,
return -EFAULT;
}
-static inline void hmm_pte_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
- uint64_t pfns, uint64_t cpu_flags,
- bool *fault, bool *write_fault)
+static unsigned int hmm_pte_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
+ uint64_t pfns, uint64_t cpu_flags)
{
struct hmm_range *range = hmm_vma_walk->range;
if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
- return;
+ return 0;
/*
* So we not only consider the individual per page request we also
@@ -114,37 +117,37 @@ static inline void hmm_pte_need_fault(const struct
hmm_vma_walk *hmm_vma_walk,
/* We aren't ask to do anything ... */
if (!(pfns & range->flags[HMM_PFN_VALID]))
- return;
+ return 0;
- /* If CPU page table is not valid then we need to fault */
- *fault = !(cpu_flags & range->flags[HMM_PFN_VALID]);
/* Need to write fault ? */
if ((pfns & range->flags[HMM_PFN_WRITE]) &&
- !(cpu_flags & range->flags[HMM_PFN_WRITE])) {
- *write_fault = true;
- *fault = true;
- }
+ !(cpu_flags & range->flags[HMM_PFN_WRITE]))
+ return HMM_NEED_WRITE_FAULT;
+
+ /* If CPU page table is not valid then we need to fault */
+ if (!(cpu_flags & range->flags[HMM_PFN_VALID]))
+ return HMM_NEED_FAULT;
+ return 0;
}
-static void hmm_range_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
-const uint64_t *pfns, unsigned long npages,
-uint64_t cpu_flags, bool *fault,
-bool *write_fault)
+static unsigned int
+hmm_range_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
+const uint64_t *pfns, unsigned long npages,
+uint64_t cpu_flags)
{
+ unsigned int required_fault = 0;
unsigned long i;
- if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT) {
- *fault = *write_fault = false;
- return;
- }
+ if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
+ return 0;
- *fault = *write_fault = false;
for (i = 0; i < npages; ++i) {
[PATCH 1/2] drm/prime: correct logic for mapping sg to arrays
Previously drm_prime_sg_to_page_addr_arrays did not allow for
scatter-gather tables where the length had been reduced in a
dma_map.
This commit enables this via drm_prime_dma_sg_to_page_addr_arrays
while still keeping the original logic in place for tables that
that have not been through dma mapping
Signed-off-by: Shane Francis
---
drivers/gpu/drm/drm_prime.c | 71 -
include/drm/drm_prime.h | 5 +++
2 files changed, 67 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..ed045043323e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -943,21 +943,22 @@ struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
}
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
* @addrs: optional array to store the dma bus address of each page
* @max_entries: size of both the passed-in arrays
+ * @sg_length: size of scatter-gather table
+ * @dma_mapped: if the supplied scatter-gather table has been dma mapped
*
- * Exports an sg table into an array of pages and addresses. This is currently
- * required by the TTM driver in order to do correct fault handling.
- *
- * Drivers can use this in their _driver.gem_prime_import_sg_table
- * implementation.
+ * Used internally to dri for both drm_prime_sg_to_page_addr_arrays and
+ * drm_prime_dma_sg_to_page_addr_arrays
*/
-int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
-dma_addr_t *addrs, int max_entries)
+static int drm_prime_sg_to_arrays(struct sg_table *sgt, struct page **pages,
+dma_addr_t *addrs, int max_entries,
+unsigned sg_length, bool dma_mapped)
{
unsigned count;
struct scatterlist *sg;
@@ -966,8 +967,11 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt,
struct page **pages,
dma_addr_t addr;
index = 0;
- for_each_sg(sgt->sgl, sg, sgt->nents, count) {
- len = sg->length;
+ for_each_sg(sgt->sgl, sg, sg_length, count) {
+ if (!dma_mapped)
+ len = sg->length;
+ else
+ len = sg_dma_len(sg);
page = sg_page(sg);
addr = sg_dma_address(sg);
@@ -987,8 +991,57 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt,
struct page **pages,
}
return 0;
}
+
+
+/**
+ * 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
+ * @addrs: optional array to store the dma bus address of each page
+ * @max_entries: size of both the passed-in arrays
+ *
+ * Exports an sg table into an array of pages and addresses. This is currently
+ * required by the TTM driver in order to do correct fault handling.
+ *
+ * Used in instances when sgt->nents is the true length of the scatter-gather
+ * table
+ *
+ * Drivers can use this in their _driver.gem_prime_import_sg_table
+ * implementation.
+ */
+int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
+dma_addr_t *addrs, int max_entries)
+{
+return drm_prime_sg_to_arrays(sgt, pages, addrs, max_entries, sgt->nents,
+ false);
+}
EXPORT_SYMBOL(drm_prime_sg_to_page_addr_arrays);
+
+/**
+ * drm_prime_dma_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
+ * @addrs: optional array to store the dma bus address of each page
+ * @max_entries: size of both the passed-in arrays
+ * @sg_length: size of scatter-gather table (this has the potential to differ
+ * from sgt->nents due to dma_mapping)
+ *
+ *
+ * Used in instances when sgt->nents is not a valid length of the
scatter-gather
+ * table
+ */
+int drm_prime_dma_sg_to_page_addr_arrays(struct sg_table *sgt,
+ struct page **pages,
+ dma_addr_t *addrs, int max_entries,
+ unsigned sg_length)
+{
+return drm_prime_sg_to_arrays(sgt, pages, addrs, max_entries, sg_length,
+ true);
+}
+EXPORT_SYMBOL(drm_prime_dma_sg_to_page_addr_arrays);
+
+
/**
* drm_prime_gem_destroy - helper to clean up a PRIME-imported GEM object
* @obj: GEM object which was created from a dma-buf
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 9af7422b44cf..83fa7b28fc1f 100644
--- a/include/drm/drm_prime.h
+++
[PATCH v2 hmm 6/9] mm/hmm: use device_private_entry_to_pfn()
From: Jason Gunthorpe
swp_offset() should not be called directly, the wrappers are supposed to
abstract away the encoding of the device_private specific information in
the swap entry.
Reviewed-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f59e59fb303e95..e114110ad498a2 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -266,7 +266,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
*/
if (hmm_is_device_private_entry(range, entry)) {
*pfn = hmm_device_entry_from_pfn(range,
- swp_offset(entry));
+ device_private_entry_to_pfn(entry));
*pfn |= range->flags[HMM_PFN_VALID];
if (is_write_device_private_entry(entry))
*pfn |= range->flags[HMM_PFN_WRITE];
--
2.25.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 hmm 5/9] mm/hmm: remove the CONFIG_TRANSPARENT_HUGEPAGE #ifdef
From: Jason Gunthorpe
This code can be compiled when CONFIG_TRANSPARENT_HUGEPAGE is off, so
remove the ifdef.
The function is only ever called under
if (pmd_devmap(pmd) || pmd_trans_huge(pmd))
Which is statically false if !CONFIG_TRANSPARENT_HUGEPAGE, so the compiler
reliably eliminates all of this code.
Reviewed-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 43d107a4d9dec6..f59e59fb303e95 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -198,7 +198,6 @@ static inline uint64_t pmd_to_hmm_pfn_flags(struct
hmm_range *range, pmd_t pmd)
range->flags[HMM_PFN_VALID];
}
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
static int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr,
unsigned long end, uint64_t *pfns, pmd_t pmd)
{
@@ -221,11 +220,6 @@ static int hmm_vma_handle_pmd(struct mm_walk *walk,
unsigned long addr,
hmm_vma_walk->last = end;
return 0;
}
-#else /* CONFIG_TRANSPARENT_HUGEPAGE */
-/* stub to allow the code below to compile */
-int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr,
- unsigned long end, uint64_t *pfns, pmd_t pmd);
-#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
static inline bool hmm_is_device_private_entry(struct hmm_range *range,
swp_entry_t entry)
--
2.25.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 2/6] mm/hmm: return the fault type from hmm_pte_need_fault()
On Sat, Mar 21, 2020 at 09:37:26AM +0100, Christoph Hellwig wrote:
> On Fri, Mar 20, 2020 at 01:49:01PM -0300, Jason Gunthorpe wrote:
> > +enum {
> > + NEED_FAULT = 1 << 0,
> > + NEED_WRITE_FAULT = 1 << 1,
> > +};
>
> Maybe add a HMM_ prefix?
Yes, OK, the existing names are pretty generic
> > for (i = 0; i < npages; ++i) {
> > + required_fault |=
> > + hmm_pte_need_fault(hmm_vma_walk, pfns[i], cpu_flags);
> > + if (required_fault == (NEED_FAULT | NEED_WRITE_FAULT))
> > + return required_fault;
>
> No need for the inner braces.
Techincally yes, but gcc demands them:
mm/hmm.c:146:22: warning: suggest parentheses around comparison in operand of
'|' [-Wparentheses]
if (required_fault == NEED_FAULT | NEED_WRITE_FAULT)
~~~^
Probably because | vs || is a common confusion?
Actually this whole NEED_FAULT | WRITE_FAULT thing is silly, I'm going
to define NEED_WRITE_FAULT == NEED_FAULT | (1<<1) and add a
NEED_ALL_BITS to make this clear what this test is for (early loop
exit once there is no possible change to required_fault).
> > @@ -532,17 +515,15 @@ static int hmm_vma_walk_test(unsigned long start,
> > unsigned long end,
> > */
> > if ((vma->vm_flags & (VM_IO | VM_PFNMAP | VM_MIXEDMAP)) ||
> > !(vma->vm_flags & VM_READ)) {
> > - bool fault, write_fault;
> > -
>
> No that there is no need for local variables I'd invert the test and
> return early:
This is more readable, I reworked the comment too
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 hmm 7/9] mm/hmm: do not unconditionally set pfns when returning EBUSY
From: Jason Gunthorpe
In hmm_vma_handle_pte() and hmm_vma_walk_hugetlb_entry() if fault happens
then -EBUSY will be returned and the pfns input flags will have been
destroyed.
For hmm_vma_handle_pte() set HMM_PFN_NONE only on the success returns that
don't otherwise store to pfns.
For hmm_vma_walk_hugetlb_entry() all exit paths already set pfns, so
remove the redundant store.
Fixes: 2aee09d8c116 ("mm/hmm: change hmm_vma_fault() to allow write fault on
page basis")
Signed-off-by: Jason Gunthorpe
---
mm/hmm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index e114110ad498a2..bf77b852f12d3a 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -249,11 +249,11 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
pte_t pte = *ptep;
uint64_t orig_pfn = *pfn;
- *pfn = range->values[HMM_PFN_NONE];
if (pte_none(pte)) {
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
if (required_fault)
goto fault;
+ *pfn = range->values[HMM_PFN_NONE];
return 0;
}
@@ -274,8 +274,10 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
unsigned long addr,
}
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
- if (!required_fault)
+ if (!required_fault) {
+ *pfn = range->values[HMM_PFN_NONE];
return 0;
+ }
if (!non_swap_entry(entry))
goto fault;
@@ -493,7 +495,6 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned
long hmask,
i = (start - range->start) >> PAGE_SHIFT;
orig_pfn = range->pfns[i];
- range->pfns[i] = range->values[HMM_PFN_NONE];
cpu_flags = pte_to_hmm_pfn_flags(range, entry);
required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, cpu_flags);
if (required_fault) {
--
2.25.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/5] drm/panfrost: Register devfreq cooling and attempt to add Energy Model
On 3/18/20 1:11 PM, Alyssa Rosenzweig wrote: Reviewed-by: Alyssa Rosenzweig Thank you Alyssa for the review. Regards, Lukasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4 3/4] backlight: qcom-wled: Add WLED5 bindings
Add WLED5 specific bindings. Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy --- .../bindings/leds/backlight/qcom-wled.yaml | 39 ++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 8a388bf..159115f 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -20,6 +20,7 @@ properties: - qcom,pm8941-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm8150l-wled reg: maxItems: 1 @@ -28,10 +29,23 @@ properties: maxItems: 1 description: brightness value on boot, value from 0-4095. + For pm8150l this value vary from 0-4095 or 0-32767 + depending on the brightness control mode. If CABC is + enabled 0-4095 range is used. allOf: - $ref: /schemas/types.yaml#/definitions/uint32 default: 2048 + max-brightness: +maxItems: 1 +description: + Maximum brightness level. Allowed values are, + for pmi8998 it is 0-4095. + For pm8150l, this can be either 4095 or 32767. + If CABC is enabled, this is capped to 4095. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + label: maxItems: 1 description: @@ -124,6 +138,31 @@ properties: value for PM8941 from 1 to 3. Default 2 For PMI8998 from 1 to 4. + qcom,modulator-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + If not specified, then modulator A will be used by default. + This property is applicable only to WLED5 peripheral. + + qcom,cabc-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. + interrupts: maxItems: 2 description: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
