Re: [PATCHv3/RFC 4/4] drm/rockchip: Add support for afbc
Hello Andrzej,
Thanks a lot for the patch.
Reviewed-by: Ezequiel Garcia
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> This patch adds support for afbc handling. afbc is a compressed format
> which reduces the necessary memory bandwidth.
>
> Co-developed-by: Mark Yao
> Signed-off-by: Mark Yao
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 29
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 142 +++-
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 12 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 84 +++-
> 4 files changed, 263 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index ca01234c037c..7eaa3fdc03b2 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -18,6 +19,8 @@
> #include "rockchip_drm_fb.h"
> #include "rockchip_drm_gem.h"
>
> +#define ROCKCHIP_MAX_AFBC_WIDTH 2560
> +
> static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> .destroy = drm_gem_fb_destroy,
> .create_handle = drm_gem_fb_create_handle,
> @@ -32,6 +35,32 @@ rockchip_fb_alloc(struct drm_device *dev, const struct
> drm_mode_fb_cmd2 *mode_cm
> int ret;
> int i;
>
> + if (drm_is_afbc(mode_cmd->modifier[0])) {
> + struct drm_afbc afbc;
> +
> + drm_afbc_get_parameters(mode_cmd, );
> +
> + if (afbc.offset) {
> + DRM_WARN("AFBC plane offset must be zero!\n");
> +
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (afbc.tile_w != 16 || afbc.tile_h != 16) {
> + DRM_WARN("Unsupported afbc tile w/h [%d/%d]\n",
> + afbc.tile_w, afbc.tile_h);
> +
I think it's important to stick to using always "AFBC" or
always ", i.e. to be consisten in user messages.
Makes grepping easier.
[..]
> @@ -846,6 +960,23 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>
> spin_lock(>reg_lock);
>
> + if (fb->modifier ==
> + DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 |
> + AFBC_FORMAT_MOD_SPARSE)) {
You check this modifier condition a few times, how about
having a helper for it?
> + int afbc_format = vop_convert_afbc_format(fb->format->format);
> +
> + VOP_AFBC_SET(vop, format, afbc_format | AFBC_TILE_16x16);
> + VOP_AFBC_SET(vop, hreg_block_split, 0);
> + VOP_AFBC_SET(vop, win_sel, VOP_WIN_TO_INDEX(vop_win));
> + VOP_AFBC_SET(vop, hdr_ptr, dma_addr);
> + VOP_AFBC_SET(vop, pic_size, act_info);
> +
> + /*
> + * The window being udated becomes the AFBC window
> + */
> + vop->afbc_win = vop_win;
> + }
> +
> VOP_WIN_SET(vop, win, format, format);
> VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
> VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
> @@ -1001,6 +1132,7 @@ static const struct drm_plane_funcs vop_plane_funcs = {
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> + .format_mod_supported = rockchip_mod_supported,
> };
>
> static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
> @@ -1340,6 +1472,10 @@ static void vop_crtc_atomic_flush(struct drm_crtc
> *crtc,
>
> spin_lock(>reg_lock);
>
> + /*
> + * Enable AFBC if there is some AFBC window, disable otherwise
> + */
Nitpick: no need for multi-line style comments, if the comment
is a single line. Also, you might want to end the comment with a stop.
Thanks!
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3/RFC 1/4] drm/arm: Factor out generic afbc helpers
Hi Andrzej,
Thanks for the series. It's certainly going well.
Please see some minor comments below.
On Thu, 2019-11-21 at 18:22 +0100, Andrzej Pietrasiewicz wrote:
> These are useful for other users of afbc, e.g. rockchip.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_afbc.c| 84 +++
> drivers/gpu/drm/drm_fourcc.c | 11 +++-
> drivers/gpu/drm/drm_framebuffer.c | 71 +-
> include/drm/drm_afbc.h| 35 +
> 5 files changed, 199 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_afbc.c
> create mode 100644 include/drm/drm_afbc.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index d9bcc9f2a0a4..3a58f30b83a6 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -44,7 +44,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_dsc.o drm_probe_helper
> drm_simple_kms_helper.o drm_modeset_helper.o \
> drm_scdc_helper.o drm_gem_framebuffer_helper.o \
> drm_atomic_state_helper.o drm_damage_helper.o \
> - drm_format_helper.o drm_self_refresh_helper.o
> + drm_format_helper.o drm_self_refresh_helper.o drm_afbc.o
>
> drm_kms_helper-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_afbc.c b/drivers/gpu/drm/drm_afbc.c
> new file mode 100644
> index ..f308c4719546
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_afbc.c
> @@ -0,0 +1,84 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * (C) 2019 Collabora Ltd.
> + *
> + * author: Andrzej Pietrasiewicz
> + *
> + */
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * drm_afbc_get_superblk_wh - extract afbc block width/height from modifier
> + * @modifier: the modifier to be looked at
> + * @w: address of a place to store the block width
> + * @h: address of a place to store the block height
> + *
> + * Returns: true if the modifier describes a supported block size
> + */
> +bool drm_afbc_get_superblk_wh(u64 modifier, u32 *w, u32 *h)
> +{
Name nitpicking: drm_afbc_get_superblock_size. The coding-style
guide has a chapter on naming and suggests avoiding stuff like
"superblk".
> + switch (modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
> + *w = 16;
> + *h = 16;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8:
> + *w = 32;
> + *h = 8;
> + break;
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_64x4:
> + /* fall through */
> + case AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4:
> + /* fall through */
> + default:
> + DRM_DEBUG_KMS("Invalid AFBC_FORMAT_MOD_BLOCK_SIZE: %lld.\n",
> + modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK);
> + return false;
> + }
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_afbc_get_superblk_wh);
> +
> +/**
> + * drm_afbc_get_parameters - extract afbc parameters from mode command
> + * @mode_cmd: mode command to be looked at
> + * @afbc: address of a struct to be filled in
> + */
> +void drm_afbc_get_parameters(const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_afbc *afbc)
> +{
> + drm_afbc_get_superblk_wh(mode_cmd->modifier[0],
> + >tile_w, >tile_h);
> + afbc->width = mode_cmd->pitches[0];
> + afbc->height =
> + DIV_ROUND_UP(mode_cmd->height, afbc->tile_h) * afbc->tile_h;
> + afbc->offset = mode_cmd->offsets[0];
> +}
> +EXPORT_SYMBOL(drm_afbc_get_parameters);
> +
Not sure if this was discussed before, but why some
are EXPORT_SYMBOL and others are exported as _GPL?
> +/**
> + * drm_is_afbc - test if the modifier describes an afbc buffer
> + * @modifier - modifier to be tested
> + *
> + * Returns: true if the modifier describes an afbc buffer
> + */
> +bool drm_is_afbc(u64 modifier)
> +{
> + /* is it ARM AFBC? */
> + if ((modifier & DRM_FORMAT_MOD_ARM_AFBC(0)) == 0)
> + return false;
> +
> + /* Block size must be known */
> + if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) == 0)
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(drm_is_afbc);
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index c630064ccf41..8d9f197cc0ab 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -27,6 +27,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -322,8 +323,14 @@ drm_get_format_info(struct drm_device *dev,
> {
> const struct drm_format_info *info = NULL;
>
> - if (dev->mode_config.funcs->get_format_info)
> - info =
Re: [RFC 06/13] drm/i915/svm: Page table mirroring support
On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote:
On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:
+static inline bool
+i915_range_done(struct hmm_range *range)
+{
+ bool ret = hmm_range_valid(range);
+
+ hmm_range_unregister(range);
+ return ret;
+}
This needs to be updated to follow the new API, but this pattern is
generally wrong, failure if hmm_range_valid should retry the
range_fault and so forth. See the hmm.rst.
Thanks Jason for the feedback.
Yah, will update as per new API in the next revision.
The caller of this function is indeed retrying if the range is not valid.
But I got the point. I made changes in my local build as per hmm.rst
and it is working fine. Will include the change in next revision.
Noticed that as hmm_range_fault() retuns number of valid pages, hmm.rst
example probably should be updated to check for that instead of non-zero
return value.
+static int
+i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
+{
+ long ret;
+
+ range->default_flags = 0;
+ range->pfn_flags_mask = -1UL;
+
+ ret = hmm_range_register(range, >mirror);
+ if (ret) {
+ up_read(>mm->mmap_sem);
+ return (int)ret;
+ }
Using a temporary range is the pattern from nouveau, is it really
necessary in this driver?
Yah, not required. In my local build I tried with proper default_flags
and set pfn_flags_mask to 0 and it is working fine.
+static u32 i915_svm_build_sg(struct i915_address_space *vm,
+struct hmm_range *range,
+struct sg_table *st)
+{
+ struct scatterlist *sg;
+ u32 sg_page_sizes = 0;
+ u64 i, npages;
+
+ sg = NULL;
+ st->nents = 0;
+ npages = (range->end - range->start) / PAGE_SIZE;
+
+ /*
+* No needd to dma map the host pages and later unmap it, as
+* GPU is not allowed to access it with SVM. Hence, no need
+* of any intermediate data strucutre to hold the mappings.
+*/
+ for (i = 0; i < npages; i++) {
+ u64 addr = range->pfns[i] & ~((1UL << range->pfn_shift) - 1);
+
+ if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
+ sg->length += PAGE_SIZE;
+ sg_dma_len(sg) += PAGE_SIZE;
+ continue;
+ }
+
+ if (sg)
+ sg_page_sizes |= sg->length;
+
+ sg = sg ? __sg_next(sg) : st->sgl;
+ sg_dma_address(sg) = addr;
+ sg_dma_len(sg) = PAGE_SIZE;
+ sg->length = PAGE_SIZE;
+ st->nents++;
It is odd to build the range into a sgl.
IMHO it is not a good idea to use the sg_dma_address like this, that
should only be filled in by a dma map. Where does it end up being
used?
The sgl is used to plug into the page table update function in i915.
For the device memory in discrete card, we don't need dma map which
is the case here. Here we don't expect any access to host memory
as mentioned in the comment above.
Well for integrated gfx, if we need to use SVM (with iommu is enabled),
we need to dma map. This requires we maintain the dma address for
each page in some intermediate data structure. Currently, this is TBD.
+ range.pfn_shift = PAGE_SHIFT;
+ range.start = args->start;
+ range.flags = i915_range_flags;
+ range.values = i915_range_values;
+ range.end = range.start + args->length;
+ for (i = 0; i < npages; ++i) {
+ range.pfns[i] = range.flags[HMM_PFN_VALID];
+ if (!(args->flags & I915_BIND_READONLY))
+ range.pfns[i] |= range.flags[HMM_PFN_WRITE];
+ }
+
+ down_read(>mm->mmap_sem);
+ vma = find_vma(svm->mm, range.start);
Why is find_vma needed?
Ok, looks like not needed, will remove it.
+ if (unlikely(!vma || vma->vm_end < range.end)) {
+ ret = -EFAULT;
+ goto vma_done;
+ }
+again:
+ ret = i915_range_fault(svm, );
+ if (unlikely(ret))
+ goto vma_done;
+
+ sg_page_sizes = i915_svm_build_sg(vm, , );
Keep in mind what can be done with the range values is limited until
the lock is obtained. Reading the pfns and flags is OK though.
Yah, I either have to build sgl here now and discard later if the range
is not valid. Or, do it while holding the lock which increases contention
period. So, settled on doing it here as it seemed better choice to me.
+int i915_svm_bind_mm(struct i915_address_space *vm)
+{
+ struct i915_svm *svm;
+ struct mm_struct *mm;
+ int ret = 0;
+
+ mm = get_task_mm(current);
I don't think the get_task_mm(current) is needed, the mmget is already
done for current->mm ?
No, I don't think mmget is already done for current->mm here.
Jason
___
dri-devel
[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward
https://bugs.freedesktop.org/show_bug.cgi?id=108514 --- Comment #37 from Kati K --- thank you for your tip, we can face a problem. Can I use free this -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward
https://bugs.freedesktop.org/show_bug.cgi?id=108514 Kati K changed: What|Removed |Added URL||https://statuslife.in/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/14] mm/mmu_notifier: add an interval tree notifier
On 11/13/19 8:46 AM, Jason Gunthorpe wrote: On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote: +int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni, + struct mm_struct *mm, unsigned long start, + unsigned long length, + const struct mmu_interval_notifier_ops *ops); +int mmu_interval_notifier_insert_locked( + struct mmu_interval_notifier *mni, struct mm_struct *mm, + unsigned long start, unsigned long length, + const struct mmu_interval_notifier_ops *ops); Very inconsistent indentation between these two related functions. clang-format.. The kernel config is set to prefer a line up under the ( if all the arguments will fit within the 80 cols otherwise it does a 1 tab continuation indent. + /* +* The inv_end incorporates a deferred mechanism like +* rtnl_unlock(). Adds and removes are queued until the final inv_end +* happens then they are progressed. This arrangement for tree updates +* is used to avoid using a blocking lock during +* invalidate_range_start. Nitpick: That comment can be condensed into one less line: The rtnl_unlock can move up a line too. My editor is failing me on this. + /* +* TODO: Since we already have a spinlock above, this would be faster +* as wake_up_q +*/ + if (need_wake) + wake_up_all(_mm->wq); So why is this important enough for a TODO comment, but not important enough to do right away? Lets drop the comment, I'm noto sure wake_up_q is even a function this layer should be calling. Actually, I think you can remove the "need_wake" variable since it is unconditionally set to "true". Also, the comment in__mmu_interval_notifier_insert() says "mni->mr_invalidate_seq" and I think that should be "mni->invalidate_seq". ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] msm:disp:dpu1: add support for display for SC7180 target
On Wed, Nov 20, 2019 at 05:49:28PM +0530, Kalyan Thota wrote: > Add display hw catalog changes for SC7180 target. > > Changes in v1: > - Configure register offsets and capabilities for the >display hw blocks. > > Changes in v2: > - mdss_irq data type has changed in the dependent >patch, accommodate the necessary changes. > - Add co-developed-by tags in the commit msg (Stephen Boyd). > > Changes in v3: > - fix kernel checkpatch errors in v2 But not the one telling you to split bindings to separate patch? > > This patch has dependency on the below series > > https://patchwork.kernel.org/patch/11253647/ > > Co-developed-by: Shubhashree Dhar > Signed-off-by: Shubhashree Dhar > Co-developed-by: Raviteja Tamatam > Signed-off-by: Raviteja Tamatam > Signed-off-by: Kalyan Thota > --- > .../devicetree/bindings/display/msm/dpu.txt| 4 +- Acked-by: Rob Herring > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 189 > +++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 3 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 + > drivers/gpu/drm/msm/msm_drv.c | 4 +- > 6 files changed, 190 insertions(+), 15 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt > b/Documentation/devicetree/bindings/display/msm/dpu.txt > index a61dd40..512f022 100644 > --- a/Documentation/devicetree/bindings/display/msm/dpu.txt > +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt > @@ -8,7 +8,7 @@ The DPU display controller is found in SDM845 SoC. > > MDSS: > Required properties: > -- compatible: "qcom,sdm845-mdss" > +- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss" > - reg: physical base address and length of contoller's registers. > - reg-names: register region names. The following region is required: >* "mdss" > @@ -41,7 +41,7 @@ Optional properties: > > MDP: > Required properties: > -- compatible: "qcom,sdm845-dpu" > +- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu" > - reg: physical base address and length of controller's registers. > - reg-names : register region names. The following region is required: >* "mdp" ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] dt-bindings: display: add IMX MIPI DSI host controller doc
On Mon, Nov 18, 2019 at 05:25:18PM +0200, Adrian Ratiu wrote:
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Martyn Welch
> Signed-off-by: Adrian Ratiu
> ---
> .../bindings/display/imx/mipi-dsi.txt | 56 +++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
> b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
> new file mode 100644
> index ..3f05c32ef963
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/mipi-dsi.txt
> @@ -0,0 +1,56 @@
> +Freescale i.MX6 DW MIPI DSI Host Controller
> +===
> +
> +The DSI host controller is a Synopsys DesignWare MIPI DSI v1.01 IP
> +with a companion PHY IP.
> +
> +These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
> +Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
> +the following device-specific properties.
> +
> +Required properties:
> +
> +- #address-cells: Should be <1>.
> +- #size-cells: Should be <0>.
> +- compatible: "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi".
> +- reg: See dw_mipi_dsi.txt.
> +- interrupts: The controller's CPU interrupt.
> +- clocks, clock-names: Phandles to the controller's pll reference
> + clock(ref) and APB clock(pclk), as described in [1].
> +- ports: a port node with endpoint definitions as defined in [2].
> +- gpr: Should be <>.
fsl,gpr
> + Phandle to the iomuxc-gpr region containing the multiplexer
> + control register.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + mipi_dsi: mipi@21e {
dsi@...
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
> + reg = <0x021e 0x4000>;
> + interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
> + gpr = <>;
> + clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
> + < IMX6QDL_CLK_MIPI_IPG>;
> + clock-names = "ref", "pclk";
> + status = "okay";
Don't show status in examples.
> +
> + ports {
> + port@0 {
> + reg = <0>;
> + mipi_mux_0: endpoint {
> + remote-endpoint = <_di0_mipi>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + mipi_mux_1: endpoint {
> + remote-endpoint = <_di1_mipi>;
> + };
> + };
> + };
> +};
> --
> 2.24.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] dt-bindings: Add binding for IT6505.
On Fri, Nov 15, 2019 at 05:52:19PM +0800, allen wrote:
> From: Allen Chen
>
> Add a DT binding documentation for IT6505.
>
> Signed-off-by: Allen Chen
> Signed-off-by: Pi-Hsun Shih
> ---
> .../bindings/display/bridge/ite,it6505.txt | 28
> ++
> 1 file changed, 28 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
Please make this a DT schema. See
Documentation/devicetree/writing-schema.rst.
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> new file mode 100644
> index ..72da0c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> @@ -0,0 +1,28 @@
> +iTE it6505 DP bridge bindings
> +
> +Required properties:
> +- compatible: "ite,it6505"
> +- reg: i2c address of the bridge
> +- ovdd-supply: I/O voltage
> +- pwr18-supply: Core voltage
> +- interrupts: interrupt specifier of INT pin
> +- reset-gpios: gpio specifier of RESET pin
> + - hpd-gpios:
> + Hotplug detect GPIO.
> + Indicates which GPIO should be used for hotplug detection
Indentation is not consistent.
> + - port@[x]: SoC specific port nodes with endpoint definitions as defined
> + in
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
You need to define what each port is. With the schema, that will be
'port@0' and 'port@1' properties.
> +
> +Example:
> + dp-bridge@5c {
> +compatible = "ite,it6505";
> +interrupts = <152 IRQ_TYPE_EDGE_RISING 152 0>;
> +reg = <0x5c>;
> +pinctrl-names = "default";
> +pinctrl-0 = <_pins>;
> +ovdd-supply = <_vsim1_reg>;
> +pwr18-supply = <_pp18_reg>;
> +reset-gpios = < 179 1>;
> +hpd-gpios = < 9 0>;
> +extcon = <_extcon>;
Not documented plus it's deprecated.
You're missing ports here and they are required.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=110730 --- Comment #10 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110730] [CI][RESUME] igt@kms_chamelium@hdmi-crc-single - crash - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=110730 swathi.dhanavant...@intel.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #9 from swathi.dhanavant...@intel.com --- Not seen on drm tip, so closing and archiving this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] drm/msm/a6xx: Support split pagetables
Attempt to enable split pagetables if the arm-smmu driver supports it.
This will move the default address space from the default region to
the address range assigned to TTBR1. The behavior should be transparent
to the driver for now but it gets the default buffers out of the way
when we want to start swapping TTBR0 for context-specific pagetables.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 ++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5dc0b2c..96b3b28 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -811,6 +811,50 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
return (unsigned long)busy_time;
}
+static struct msm_gem_address_space *
+a6xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+{
+ struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
+ struct msm_gem_address_space *aspace;
+ struct msm_mmu *mmu;
+ u64 start, size;
+ u32 val = 1;
+ int ret;
+
+ if (!iommu)
+ return ERR_PTR(-ENOMEM);
+
+ /* Try to request split pagetables */
+ iommu_domain_set_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, );
+
+ mmu = msm_iommu_new(>dev, iommu);
+ if (IS_ERR(mmu)) {
+ iommu_domain_free(iommu);
+ return ERR_CAST(mmu);
+ }
+
+ /* Check to see if split pagetables were successful */
+ ret = iommu_domain_get_attr(iommu, DOMAIN_ATTR_SPLIT_TABLES, );
+ if (!ret && val) {
+ /*
+* The aperture start will be at the beginning of the TTBR1
+* space so use that as a base
+*/
+ start = iommu->geometry.aperture_start;
+ size = 0x;
+ } else {
+ /* Otherwise use the legacy 32 bit region */
+ start = SZ_16M;
+ size = 0x - SZ_16M;
+ }
+
+ aspace = msm_gem_address_space_create(mmu, "gpu", start, size);
+ if (IS_ERR(aspace))
+ iommu_domain_free(iommu);
+
+ return aspace;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -832,7 +876,7 @@ static const struct adreno_gpu_funcs funcs = {
#if defined(CONFIG_DRM_MSM_GPU_STATE)
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
- .create_address_space = adreno_iommu_create_address_space,
+ .create_address_space = a6xx_create_address_space,
#endif
},
.get_timestamp = a6xx_get_timestamp,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] drm/msm: Refactor address space initialization
Refactor how address space initialization works. Instead of having the
address space function create the MMU object (and thus require separate but
equal functions for gpummu and iommu) use a single function and pass the
MMU struct in. Make the generic code cleaner by using target specific
functions to create the address space so a2xx can do its own thing in its
own space. For all the other targets use a generic helper to initialize
IOMMU but leave the door open for newer targets to use customization
if they need it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c| 16 ++
drivers/gpu/drm/msm/adreno/a3xx_gpu.c| 1 +
drivers/gpu/drm/msm/adreno/a4xx_gpu.c| 1 +
drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c| 1 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 23 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 8 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 +++---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 14 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 4 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11 +--
drivers/gpu/drm/msm/msm_drv.h| 8 ++---
drivers/gpu/drm/msm/msm_gem_vma.c| 52 +---
drivers/gpu/drm/msm/msm_gpu.c| 40 ++--
drivers/gpu/drm/msm/msm_gpu.h| 4 +--
drivers/gpu/drm/msm/msm_iommu.c | 3 ++
16 files changed, 83 insertions(+), 114 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 1f83bc1..60f6472 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -401,6 +401,21 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct
msm_gpu *gpu)
return state;
}
+static struct msm_gem_address_space *
+a2xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+{
+ struct msm_mmu *mmu = msm_gpummu_new(>dev, gpu);
+ struct msm_gem_address_space *aspace;
+
+ aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
+ SZ_16M + 0xfff * SZ_64K);
+
+ if (IS_ERR(aspace) && !IS_ERR(mmu))
+ mmu->funcs->destroy(mmu);
+
+ return aspace;
+}
+
/* Register offset defines for A2XX - copy of A3XX */
static const unsigned int a2xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -429,6 +444,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a2xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+ .create_address_space = a2xx_create_address_space,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 7ad1493..41e51e0 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -441,6 +441,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+ .create_address_space = adreno_iommu_create_address_space,
},
};
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index b01388a..3655440 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -532,6 +532,7 @@ static const struct adreno_gpu_funcs funcs = {
#endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
+ .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a4xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b02e204..0f5db72 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1432,6 +1432,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_busy = a5xx_gpu_busy,
.gpu_state_get = a5xx_gpu_state_get,
.gpu_state_put = a5xx_gpu_state_put,
+ .create_address_space = adreno_iommu_create_address_space,
},
.get_timestamp = a5xx_get_timestamp,
};
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index dc8ec2c..5dc0b2c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -832,6 +832,7 @@ static const struct adreno_gpu_funcs funcs = {
#if defined(CONFIG_DRM_MSM_GPU_STATE)
.gpu_state_get = a6xx_gpu_state_get,
.gpu_state_put = a6xx_gpu_state_put,
+ .create_address_space = adreno_iommu_create_address_space,
#endif
},
.get_timestamp = a6xx_get_timestamp,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index
[PATCH v2 5/8] drm/msm: Attach the IOMMU device during initialization
Everywhere an IOMMU object is created by msm_gpu_create_address_space
the IOMMU device is attached immediately after. Instead of carrying around
the infrastructure to do the attach from the device specific code do it
directly in the msm_iommu_init() function. This gets it out of the way for
more aggressive cleanups that follow.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 4
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 7 ---
drivers/gpu/drm/msm/msm_gem_vma.c| 23 +++
drivers/gpu/drm/msm/msm_gpu.c| 11 +--
drivers/gpu/drm/msm/msm_gpummu.c | 6 --
drivers/gpu/drm/msm/msm_iommu.c | 15 +++
drivers/gpu/drm/msm/msm_mmu.h| 1 -
8 files changed, 27 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 6c92f0f..b082b23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -704,7 +704,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
{
struct iommu_domain *domain;
struct msm_gem_address_space *aspace;
- int ret;
domain = iommu_domain_alloc(_bus_type);
if (!domain)
@@ -720,13 +719,6 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return PTR_ERR(aspace);
}
- ret = aspace->mmu->funcs->attach(aspace->mmu);
- if (ret) {
- DPU_ERROR("failed to attach iommu %d\n", ret);
- msm_gem_address_space_put(aspace);
- return ret;
- }
-
dpu_kms->base.aspace = aspace;
return 0;
}
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index dda0543..9dba37c 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -518,10 +518,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
}
kms->aspace = aspace;
-
- ret = aspace->mmu->funcs->attach(aspace->mmu);
- if (ret)
- goto fail;
} else {
DRM_DEV_INFO(dev->dev, "no iommu, fallback to phys "
"contig buffers for scanout\n");
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index e43ecd4..653dab2 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -736,13 +736,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
kms->aspace = aspace;
-
- ret = aspace->mmu->funcs->attach(aspace->mmu);
- if (ret) {
- DRM_DEV_ERROR(>dev, "failed to attach iommu:
%d\n",
- ret);
- goto fail;
- }
} else {
DRM_DEV_INFO(>dev,
"no iommu, fallback to phys contig buffers for
scanout\n");
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 1af5354..91d993a 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -131,8 +131,8 @@ msm_gem_address_space_create(struct device *dev, struct
iommu_domain *domain,
const char *name)
{
struct msm_gem_address_space *aspace;
- u64 size = domain->geometry.aperture_end -
- domain->geometry.aperture_start;
+ u64 start = domain->geometry.aperture_start;
+ u64 size = domain->geometry.aperture_end - start;
aspace = kzalloc(sizeof(*aspace), GFP_KERNEL);
if (!aspace)
@@ -141,9 +141,18 @@ msm_gem_address_space_create(struct device *dev, struct
iommu_domain *domain,
spin_lock_init(>lock);
aspace->name = name;
aspace->mmu = msm_iommu_new(dev, domain);
+ if (IS_ERR(aspace->mmu)) {
+ int ret = PTR_ERR(aspace->mmu);
- drm_mm_init(>mm, (domain->geometry.aperture_start >>
PAGE_SHIFT),
- size >> PAGE_SHIFT);
+ kfree(aspace);
+ return ERR_PTR(ret);
+ }
+
+ /*
+* Attaching the IOMMU device changes the aperture values so use the
+* cached values instead
+*/
+ drm_mm_init(>mm, start >> PAGE_SHIFT, size >> PAGE_SHIFT);
kref_init(>kref);
@@ -164,6 +173,12 @@ msm_gem_address_space_create_a2xx(struct device *dev,
struct msm_gpu *gpu,
spin_lock_init(>lock);
aspace->name = name;
aspace->mmu = msm_gpummu_new(dev, gpu);
+ if (IS_ERR(aspace->mmu)) {
+ int ret = PTR_ERR(aspace->mmu);
+
+ kfree(aspace);
+ return ERR_PTR(ret);
+ }
drm_mm_init(>mm, (va_start >> PAGE_SHIFT),
size >> PAGE_SHIFT);
diff --git
[PATCH v2 0/8] iommu/arm-smmu: Split pagetable support for Adreno GPUs
Another refresh to support split pagetables for Adreno GPUs as part of an incremental process to enable per-context pagetables. In order to support per-context pagetables the GPU needs to enable split tables so that we can store global buffers in the TTBR1 space leaving the GPU free to program the TTBR0 register with the address of a context specific pagetable. This patchset adds split pagetable support for devices identified with the compatible string qcom,adreno-smmu-v2. If the compatible string is enabled and DOMAIN_ATTR_SPLIT_TABLES is non zero at attach time, the implementation will set up the TTBR0 and TTBR1 spaces with identical configurations and program the domain pagetable into the TTBR1 register. The TTBR0 register will be unused. The driver can determine if split pagetables were programmed by querying DOMAIN_ATTR_SPLIT_TABLES after attaching. The domain geometry will also be updated to reflect the virtual address space for the TTBR1 range. These patches are on based on top of linux-next-20191120 with [1], [2], and [3] from Robin on the iommu list. The first four patches add the device tree bindings and implementation specific support for arm-smmu and the rest of the patches add the drm/msm implementation followed by the device tree update for sdm845. [1] https://lists.linuxfoundation.org/pipermail/iommu/2019-October/039718.html [2] https://lists.linuxfoundation.org/pipermail/iommu/2019-October/039719.html [3] https://lists.linuxfoundation.org/pipermail/iommu/2019-October/039720.html Jordan Crouse (8): dt-bindings: arm-smmu: Add Adreno GPU variant iommu: Add DOMAIN_ATTR_SPLIT_TABLES iommu/arm-smmu: Pass io_pgtable_cfg to impl specific init_context iommu/arm-smmu: Add split pagetables for Adreno IOMMU implementations drm/msm: Attach the IOMMU device during initialization drm/msm: Refactor address space initialization drm/msm/a6xx: Support split pagetables arm64: dts: qcom: sdm845: Update Adreno GPU SMMU compatible string .../devicetree/bindings/iommu/arm,smmu.yaml| 6 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +- drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 16 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 1 + drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 1 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 45 ++ drivers/gpu/drm/msm/adreno/adreno_gpu.c| 23 -- drivers/gpu/drm/msm/adreno/adreno_gpu.h| 8 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 18 ++-- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 18 ++-- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 4 - drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 18 ++-- drivers/gpu/drm/msm/msm_drv.h | 8 +- drivers/gpu/drm/msm/msm_gem_vma.c | 37 ++--- drivers/gpu/drm/msm/msm_gpu.c | 49 +-- drivers/gpu/drm/msm/msm_gpu.h | 4 +- drivers/gpu/drm/msm/msm_gpummu.c | 6 -- drivers/gpu/drm/msm/msm_iommu.c| 18 ++-- drivers/gpu/drm/msm/msm_mmu.h | 1 - drivers/iommu/arm-smmu-impl.c | 6 +- drivers/iommu/arm-smmu-qcom.c | 96 ++ drivers/iommu/arm-smmu.c | 52 +--- drivers/iommu/arm-smmu.h | 14 +++- include/linux/iommu.h | 1 + 25 files changed, 295 insertions(+), 158 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel
Annoyingly, the VBT on the ThinkPad X1 Extreme 2nd Gen indicates that
the system uses plain PWM based backlight controls, when in reality the
only backlight controls that work are the standard VESA eDP DPCD
backlight controls.
Honestly, this makes me wonder how many other systems have these issues
or lie about this in their VBT. Not sure we have any good way of finding
out until panels like this become more common place in the laptop
market. For now, just add a DRM DP quirk to indicate that this panel is
telling the truth and is being a good LCD.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 4
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 10 --
include/drm/drm_dp_helper.h | 8
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870aef469..ec7061e3a99b 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1155,6 +1155,10 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
BIT(DP_DPCD_QUIRK_NO_PSR) },
/* CH7511 seems to leave SINK_COUNT zeroed */
{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
+ /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
+* only supports DPCD backlight controls, despite advertising otherwise
+*/
+ { OUI(0xba, 0x41, 0x59), DEVICE_ID_ANY, false,
BIT(DP_DPCD_QUIRK_FORCE_DPCD_BACKLIGHT) },
};
#undef OUI
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 87b59db9ffe3..3d61260b08ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -325,11 +325,17 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
{
struct intel_panel *panel = _connector->panel;
- struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
+ struct intel_dp *intel_dp =
+ enc_to_intel_dp(_connector->encoder->base);
+ struct drm_i915_private *dev_priv =
+ to_i915(intel_connector->base.dev);
if (i915_modparams.enable_dpcd_backlight == 0 ||
(i915_modparams.enable_dpcd_backlight == -1 &&
- dev_priv->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
+dev_priv->vbt.backlight.type !=
+INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
+!drm_dp_has_quirk(_dp->desc,
+ DP_DPCD_QUIRK_FORCE_DPCD_BACKLIGHT)))
return -ENODEV;
if (!intel_dp_aux_display_control_capable(intel_connector))
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 51ecb5112ef8..a444209cd54b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1520,6 +1520,14 @@ enum drm_dp_quirk {
* The driver should ignore SINK_COUNT during detection.
*/
DP_DPCD_QUIRK_NO_SINK_COUNT,
+ /**
+* @DP_DPCD_QUIRK_FORCE_DPCD_BACKLIGHT:
+*
+* The device is telling the truth when it says that it uses DPCD
+* backlight controls, even if the system's firmware disagrees.
+* The driver should honor the DPCD backlight capabilities advertised.
+*/
+ DP_DPCD_QUIRK_FORCE_DPCD_BACKLIGHT,
};
/**
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i915: Fix eDP DPCD aux max backlight calculations
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel uses 2 byte setting, it might not use
all the control bits. Thus, max backlight should be set based on the
value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255.
Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT
frequency which results in a different max backlight value. Thus,
setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of
enable so that max backlight can be calculated correctly. Only the
frequency divider is set during the enable phase using the value of
EDP_PWMGEN_BIT_COUNT.
This is based off the original patch series from Furquan Shaikh
:
https://patchwork.freedesktop.org/patch/317255/?series=62326=3
Changes since original patch:
* Remove unused intel_dp variable in intel_dp_aux_setup_backlight()
* Fix checkpatch issues
* Make sure that we rewrite the pwmgen bit count whenever we bring the
panel out of D3 mode
Cc: Furquan Shaikh
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_display_types.h| 3 +
.../drm/i915/display/intel_dp_aux_backlight.c | 139 --
2 files changed, 95 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 83ea04149b77..2a8d8cae638e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -214,6 +214,9 @@ struct intel_panel {
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
+ /* DPCD backlight */
+ u8 pwmgen_bit_count;
+
struct backlight_device *device;
/* Connector and platform specific backlight functions */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 020422da2ae2..fad470553cf9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -111,61 +111,28 @@ static bool intel_dp_aux_set_pwm_freq(struct
intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
- int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
- u8 pn, pn_min, pn_max;
+ const u8 pn = connector->panel.backlight.pwmgen_bit_count;
+ int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
- /* Find desired value of (F x P)
-* Note that, if F x P is out of supported range, the maximum value or
-* minimum value will applied automatically. So no need to check that.
-*/
freq = dev_priv->vbt.backlight.pwm_freq_hz;
- DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
if (!freq) {
DRM_DEBUG_KMS("Use panel default backlight frequency\n");
return false;
}
fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+ f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
+ fxp_actual = f << pn;
- /* Use highest possible value of Pn for more granularity of brightness
-* adjustment while satifying the conditions below.
-* - Pn is in the range of Pn_min and Pn_max
-* - F is in the range of 1 and 255
-* - FxP is within 25% of desired value.
-* Note: 25% is arbitrary value and may need some tweak.
-*/
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
- DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
- return false;
- }
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
- DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
- return false;
- }
- pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
- pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
-
+ /* Ensure frequency is within 25% of desired value */
fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
- if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
- DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
- return false;
- }
-
- for (pn = pn_max; pn >= pn_min; pn--) {
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
- if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
- break;
- }
- if (drm_dp_dpcd_writeb(_dp->aux,
-
[PATCH 4/5] drm/i915: Auto detect DPCD backlight support by default
Turns out we actually already have some companies, such as Lenovo, shipping machines with AMOLED screens that don't allow controlling the backlight through the usual PWM interface and only allow controlling it through the standard EDP DPCD interface. One example of one of these laptops is the X1 Extreme 2nd Generation. Since we've got systems that need this turned on by default now to have backlight controls working out of the box, let's start auto-detecting it for systems by default based on what the VBT tells us. We do this by changing the default value for the enable_dpcd_backlight module param from 0 to -1. Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 1dd1f3652795..31eed60c167e 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -172,7 +172,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400, i915_param_named(enable_dpcd_backlight, int, 0600, "Enable support for DPCD backlight control" - "(-1=use per-VBT LFP backlight type setting, 0=disabled [default], 1=enabled)"); + "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 1=enabled)"); #if IS_ENABLED(CONFIG_DRM_I915_GVT) i915_param_named(enable_gvt, bool, 0400, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 31b88f297fbc..a79d0867f77a 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -64,7 +64,7 @@ struct drm_printer; param(int, reset, 3) \ param(unsigned int, inject_probe_failure, 0) \ param(int, fastboot, -1) \ - param(int, enable_dpcd_backlight, 0) \ + param(int, enable_dpcd_backlight, -1) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE) \ param(unsigned long, fake_lmem_start, 0) \ /* leave bools at the end to not create holes */ \ -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()
For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index 0bf8772bc7bb..87b59db9ffe3 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -205,8 +205,9 @@ static void intel_dp_aux_enable_backlight(const struct intel_crtc_state *crtc_st } } + intel_dp_aux_set_backlight(conn_state, + connector->panel.backlight.level); set_aux_backlight_enable(intel_dp, true); - intel_dp_aux_set_backlight(conn_state, connector->panel.backlight.level); } static void intel_dp_aux_disable_backlight(const struct drm_connector_state *old_conn_state) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/i915: Assume 100% brightness when not in DPCD control mode
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed in the first place.
This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd
Generation, where the default value in these registers is always 0 on
boot despite the fact the panel runs at max brightness by default.
Getting the initial brightness value correct here is important as well,
since the panel on this laptop doesn't behave well if it's ever put into
DPCD control mode while the brightness level is programmed to 0.
So, let's fix this by checking what the current backlight control mode
is before reading the brightness level. If it's in DPCD control mode, we
return the programmed brightness level. Otherwise we assume 100%
brightness and return the highest possible brightness level. This also
prevents us from accidentally programming a brightness level of 0.
This is one of the many fixes that gets backlight controls working on
the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen.
Signed-off-by: Lyude Paul
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index fad470553cf9..0bf8772bc7bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -59,8 +59,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
u8 read_val[2] = { 0x0 };
+ u8 control_reg;
u16 level = 0;
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ _reg) != 1) {
+ DRM_DEBUG_KMS("Failed to read the DPCD register 0x%x\n",
+ DP_EDP_DISPLAY_CONTROL_REGISTER);
+ return 0;
+ }
+
+ /*
+* If we're not in DPCD control mode yet, the programmed brightness
+* value is meaningless and we should assume max brightness
+*/
+ if (!(control_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD))
+ return connector->panel.backlight.max;
+
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val, sizeof(read_val)) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm/i915: eDP DPCD aux backlight fixes
I recently got a ThinkPad X1 Extreme 2nd Generation for fixing some issues on, and noticed that out of the box the backlight doesn't work. Along the way of fixing that, I found a few issues with how i915 handles DPCD AUX backlight control and fixed them. Now I've got working backlight controls, hooray! Note that this patch series also enables DPCD aux backlight control by default based on what the VBT tells us. Lyude Paul (5): drm/i915: Fix eDP DPCD aux max backlight calculations drm/i915: Assume 100% brightness when not in DPCD control mode drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight() drm/i915: Auto detect DPCD backlight support by default drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel drivers/gpu/drm/drm_dp_helper.c | 4 + .../drm/i915/display/intel_display_types.h| 3 + .../drm/i915/display/intel_dp_aux_backlight.c | 167 -- drivers/gpu/drm/i915/i915_params.c| 2 +- drivers/gpu/drm/i915/i915_params.h| 2 +- include/drm/drm_dp_helper.h | 8 + 6 files changed, 134 insertions(+), 52 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: remove redundant assignment to variable ret
From: Colin Ian King
The variable ret is being initialized with a value that is never
read and it is being updated later with a new value. The
initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/radeon/si_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 8148a7883de4..346315b3eebe 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -5899,7 +5899,7 @@ static int
si_patch_single_dependency_table_based_on_leakage(struct radeon_devic
static int si_patch_dependency_tables_based_on_leakage(struct radeon_device
*rdev)
{
- int ret = 0;
+ int ret;
ret = si_patch_single_dependency_table_based_on_leakage(rdev,
>pm.dpm.dyn_state.vddc_dependency_on_sclk);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: remove redundant assignment to variables HiSidd and LoSidd
From: Colin Ian King
The variables HiSidd and LoSidd are being initialized with values that
are never read and are being updated a little later with a new value.
The initialization is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
index 15590fd86ef4..868e2d5f6e62 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c
@@ -653,8 +653,8 @@ static int ci_min_max_v_gnbl_pm_lid_from_bapm_vddc(struct
pp_hwmgr *hwmgr)
static int ci_populate_bapm_vddc_base_leakage_sidd(struct pp_hwmgr *hwmgr)
{
struct ci_smumgr *smu_data = (struct ci_smumgr *)(hwmgr->smu_backend);
- uint16_t HiSidd = smu_data->power_tune_table.BapmVddCBaseLeakageHiSidd;
- uint16_t LoSidd = smu_data->power_tune_table.BapmVddCBaseLeakageLoSidd;
+ uint16_t HiSidd;
+ uint16_t LoSidd;
struct phm_cac_tdp_table *cac_table = hwmgr->dyn_state.cac_dtp_table;
HiSidd = (uint16_t)(cac_table->usHighCACLeakage / 100 * 256);
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 04/13] drm/i915/svm: Implicitly migrate BOs upon CPU access
From: Venkata Sandeep Dhanalakota
As PCIe is non-coherent link, do not allow direct access to buffer
objects across the PCIe link for SVM case. Upon CPU accesses (mmap, pread),
migrate buffer object to host memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Cc: Niranjana Vishwanathapura
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10
drivers/gpu/drm/i915/gem/i915_gem_object.c | 29 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +++
drivers/gpu/drm/i915/intel_memory_region.c | 4 ---
drivers/gpu/drm/i915/intel_memory_region.h | 4 +++
5 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d60973603cc1..0b41e2f3098c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -13,6 +13,7 @@
#include "i915_drv.h"
#include "i915_gem_gtt.h"
#include "i915_gem_ioctls.h"
+#include "i915_gem_lmem.h"
#include "i915_gem_object.h"
#include "i915_trace.h"
#include "i915_vma.h"
@@ -235,6 +236,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
if (i915_gem_object_is_readonly(obj) && write)
return VM_FAULT_SIGBUS;
+ /* Implicitly migrate BO to SMEM if it is SVM mapped */
+ if (i915_gem_object_svm_mapped(obj) && i915_gem_object_is_lmem(obj)) {
+ u32 regions[] = { REGION_MAP(INTEL_MEMORY_SYSTEM, 0) };
+
+ ret = i915_gem_object_migrate_region(obj, regions, 1);
+ if (ret)
+ goto err;
+ }
+
/* We don't use vmf->pgoff since that has the fake offset */
page_offset = (vmf->address - area->vm_start) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 10defa723bc9..a7dee1b749cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -493,12 +493,17 @@ __region_id(u32 region)
return INTEL_REGION_UNKNOWN;
}
+bool
+i915_gem_object_svm_mapped(struct drm_i915_gem_object *obj)
+{
+ return false;
+}
+
static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
struct drm_i915_gem_object_param *args,
struct drm_file *file,
struct drm_i915_gem_object *obj)
{
- struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
u32 __user *uregions = u64_to_user_ptr(args->data);
u32 uregions_copy[INTEL_REGION_UNKNOWN];
int i, ret;
@@ -518,16 +523,28 @@ static int i915_gem_object_region_select(struct
drm_i915_private *dev_priv,
++uregions;
}
+ ret = i915_gem_object_migrate_region(obj, uregions_copy,
+args->size);
+
+ return ret;
+}
+
+int i915_gem_object_migrate_region(struct drm_i915_gem_object *obj,
+ u32 *regions, int size)
+{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
+ struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
+ int i, ret;
+
mutex_lock(_priv->drm.struct_mutex);
ret = i915_gem_object_prepare_move(obj);
if (ret) {
DRM_ERROR("Cannot set memory region, object in use\n");
- goto err;
+ goto err;
}
- for (i = 0; i < args->size; i++) {
- u32 region = uregions_copy[i];
- enum intel_region_id id = __region_id(region);
+ for (i = 0; i < size; i++) {
+ enum intel_region_id id = __region_id(regions[i]);
if (id == INTEL_REGION_UNKNOWN) {
ret = -EINVAL;
@@ -537,7 +554,7 @@ static int i915_gem_object_region_select(struct
drm_i915_private *dev_priv,
ret = i915_gem_object_migrate(obj, ce, id);
if (!ret) {
if (!i915_gem_object_has_pages(obj) &&
- MEMORY_TYPE_FROM_REGION(region) ==
+ MEMORY_TYPE_FROM_REGION(regions[i]) ==
INTEL_MEMORY_LOCAL) {
/*
* TODO: this should be part of get_pages(),
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 4d6da91beaff..eec31d9a4fa2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -47,6 +47,9 @@ int i915_gem_object_prepare_move(struct drm_i915_gem_object
*obj);
int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
struct intel_context *ce,
enum intel_region_id id);
+bool
[RFC 05/13] drm/i915/svm: Page table update support for SVM
For Shared Virtual Memory (SVM) system (SYS) allocator, there is no
backing buffer object (BO). Add support to bind a VA to PA mapping
in the device page table.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 60 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 10 +
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 44ff4074db12..d9e95229ba1d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -183,6 +183,50 @@ static void ppgtt_unbind_vma(struct i915_vma *vma)
vma->vm->clear_range(vma->vm, vma->node.start, vma->size);
}
+int svm_bind_addr_prepare(struct i915_address_space *vm, u64 start, u64 size)
+{
+ return vm->allocate_va_range(vm, start, size);
+}
+
+int svm_bind_addr_commit(struct i915_address_space *vm, u64 start, u64 size,
+u64 flags, struct sg_table *st, u32 sg_page_sizes)
+{
+ struct i915_vma vma = {0};
+ u32 pte_flags = 0;
+
+ /* use a vma wrapper */
+ vma.page_sizes.sg = sg_page_sizes;
+ vma.node.start = start;
+ vma.node.size = size;
+ vma.pages = st;
+ vma.vm = vm;
+
+ /* Applicable to VLV, and gen8+ */
+ if (flags & I915_GTT_SVM_READONLY)
+ pte_flags |= PTE_READ_ONLY;
+
+ vm->insert_entries(vm, , 0, pte_flags);
+ return 0;
+}
+
+int svm_bind_addr(struct i915_address_space *vm, u64 start, u64 size,
+ u64 flags, struct sg_table *st, u32 sg_page_sizes)
+{
+ int ret;
+
+ ret = svm_bind_addr_prepare(vm, start, size);
+ if (ret)
+ return ret;
+
+ return svm_bind_addr_commit(vm, start, size, flags, st, sg_page_sizes);
+}
+
+void svm_unbind_addr(struct i915_address_space *vm,
+u64 start, u64 size)
+{
+ vm->clear_range(vm, start, size);
+}
+
static int ppgtt_set_pages(struct i915_vma *vma)
{
GEM_BUG_ON(vma->pages);
@@ -973,11 +1017,21 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space
* const vm,
DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d
}\n",
__func__, vm, lvl + 1, start, end,
idx, len, atomic_read(px_used(pd)));
- GEM_BUG_ON(!len || len >= atomic_read(px_used(pd)));
+ /*
+* FIXME: In SVM case, during mmu invalidation, we need to clear ppgtt,
+* but we don't know if the entry exist or not. So, we can't assume
+* that it is called only when the entry exist. revisit.
+* Also need to add the ebility to properly handle partial invalidations
+* by downgrading the large mappings.
+*/
+ GEM_BUG_ON(!len);
do {
struct i915_page_table *pt = pd->entry[idx];
+ if (!pt)
+ continue;
+
if (atomic_fetch_inc(>used) >> gen8_pd_shift(1) &&
gen8_pd_contains(start, end, lvl)) {
DBG("%s(%p):{ lvl:%d, idx:%d, start:%llx, end:%llx }
removing pd\n",
@@ -1000,7 +1054,9 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
__func__, vm, lvl, start, end,
gen8_pd_index(start, 0), count,
atomic_read(>used));
- GEM_BUG_ON(!count || count >= atomic_read(>used));
+ GEM_BUG_ON(!count);
+ if (count > atomic_read(>used))
+ count = atomic_read(>used);
vaddr = kmap_atomic_px(pt);
memset64(vaddr + gen8_pd_index(start, 0),
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index d618a5787c61..6a8d55490e39 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
@@ -678,4 +679,13 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
#define PIN_OFFSET_MASK(-I915_GTT_PAGE_SIZE)
+/* SVM API */
+#define I915_GTT_SVM_READONLY BIT(0)
+
+int svm_bind_addr_prepare(struct i915_address_space *vm, u64 start, u64 size);
+int svm_bind_addr_commit(struct i915_address_space *vm, u64 start, u64 size,
+u64 flags, struct sg_table *st, u32 sg_page_sizes);
+int svm_bind_addr(struct i915_address_space *vm, u64 start, u64 size,
+ u64 flags, struct sg_table *st, u32 sg_page_sizes);
+void svm_unbind_addr(struct i915_address_space *vm, u64 start, u64 size);
#endif
--
2.21.0.rc0.32.g243a4c7e27
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 09/13] drm/i915/svm: Page copy support during migration
Copy the pages duing SVM migration using memcpy().
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_svm_devmem.c | 72 ++
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_svm_devmem.c
b/drivers/gpu/drm/i915/i915_svm_devmem.c
index 37a205d3a82f..960b04091e44 100644
--- a/drivers/gpu/drm/i915/i915_svm_devmem.c
+++ b/drivers/gpu/drm/i915/i915_svm_devmem.c
@@ -142,6 +142,69 @@ i915_devmem_page_free_locked(struct drm_i915_private
*dev_priv,
put_page(page);
}
+static int i915_migrate_cpu_copy(struct i915_devmem_migrate *migrate)
+{
+ const unsigned long *src = migrate->args->src;
+ unsigned long *dst = migrate->args->dst;
+ struct drm_i915_private *i915 = migrate->i915;
+ struct intel_memory_region *mem;
+ void *src_vaddr, *dst_vaddr;
+ u64 src_addr, dst_addr;
+ struct page *page;
+ int i, ret = 0;
+
+ /* XXX: Copy multiple pages at a time */
+ for (i = 0; !ret && i < migrate->npages; i++) {
+ if (!dst[i])
+ continue;
+
+ page = migrate_pfn_to_page(dst[i]);
+ mem = i915->mm.regions[migrate->dst_id];
+ dst_addr = page_to_pfn(page);
+ if (migrate->dst_id != INTEL_REGION_SMEM)
+ dst_addr -= mem->devmem->pfn_first;
+ dst_addr <<= PAGE_SHIFT;
+
+ if (migrate->dst_id == INTEL_REGION_SMEM)
+ dst_vaddr = phys_to_virt(dst_addr);
+ else
+ dst_vaddr = io_mapping_map_atomic_wc(>iomap,
+dst_addr);
+ if (unlikely(!dst_vaddr))
+ return -ENOMEM;
+
+ page = migrate_pfn_to_page(src[i]);
+ mem = i915->mm.regions[migrate->src_id];
+ src_addr = page_to_pfn(page);
+ if (migrate->src_id != INTEL_REGION_SMEM)
+ src_addr -= mem->devmem->pfn_first;
+ src_addr <<= PAGE_SHIFT;
+
+ if (migrate->src_id == INTEL_REGION_SMEM)
+ src_vaddr = phys_to_virt(src_addr);
+ else
+ src_vaddr = io_mapping_map_atomic_wc(>iomap,
+src_addr);
+
+ if (likely(src_vaddr))
+ memcpy(dst_vaddr, src_vaddr, PAGE_SIZE);
+ else
+ ret = -ENOMEM;
+
+ if (migrate->dst_id != INTEL_REGION_SMEM)
+ io_mapping_unmap_atomic(dst_vaddr);
+
+ if (migrate->src_id != INTEL_REGION_SMEM && src_vaddr)
+ io_mapping_unmap_atomic(src_vaddr);
+
+ DRM_DEBUG_DRIVER("src [%d] 0x%llx, dst [%d] 0x%llx\n",
+migrate->src_id, src_addr,
+migrate->dst_id, dst_addr);
+ }
+
+ return ret;
+}
+
static int
i915_devmem_migrate_alloc_and_copy(struct i915_devmem_migrate *migrate)
{
@@ -201,6 +264,8 @@ i915_devmem_migrate_alloc_and_copy(struct
i915_devmem_migrate *migrate)
/* Copy the pages */
migrate->npages = npages;
+ /* XXX: Flush the caches? */
+ ret = i915_migrate_cpu_copy(migrate);
migrate_out:
if (unlikely(ret)) {
for (i = 0; i < npages; i++) {
@@ -286,6 +351,7 @@ i915_devmem_fault_alloc_and_copy(struct i915_devmem_migrate
*migrate)
struct device *dev = migrate->i915->drm.dev;
struct migrate_vma *args = migrate->args;
struct page *dpage, *spage;
+ int err;
DRM_DEBUG_DRIVER("start 0x%lx\n", args->start);
/* Allocate host page */
@@ -302,6 +368,12 @@ i915_devmem_fault_alloc_and_copy(struct
i915_devmem_migrate *migrate)
/* Copy the pages */
migrate->npages = 1;
+ err = i915_migrate_cpu_copy(migrate);
+ if (unlikely(err)) {
+ __free_page(dpage);
+ args->dst[0] = 0;
+ return VM_FAULT_SIGBUS;
+ }
return 0;
}
--
2.21.0.rc0.32.g243a4c7e27
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 07/13] drm/i915/svm: Device memory support
Plugin device memory through HMM as DEVICE_PRIVATE.
Add support functions to allocate pages and free pages from device memory.
Implement ioctl to migrate pages from host to device memory.
For now, only support migrating pages from host memory to device memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Kconfig | 9 +
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 -
drivers/gpu/drm/i915/i915_buddy.h | 12 +
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_svm.c| 2 +
drivers/gpu/drm/i915/i915_svm.h| 15 +
drivers/gpu/drm/i915/i915_svm_devmem.c | 391 +
drivers/gpu/drm/i915/intel_memory_region.h | 14 +
drivers/gpu/drm/i915/intel_region_lmem.c | 10 +
10 files changed, 456 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_svm_devmem.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 689e57fe3973..66337f2ca2bf 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -141,9 +141,18 @@ config DRM_I915_SVM
bool "Enable Shared Virtual Memory support in i915"
depends on STAGING
depends on DRM_I915
+ depends on ARCH_ENABLE_MEMORY_HOTPLUG
+ depends on ARCH_ENABLE_MEMORY_HOTREMOVE
+ depends on MEMORY_HOTPLUG
+ depends on MEMORY_HOTREMOVE
+ depends on ARCH_HAS_PTE_DEVMAP
+ depends on SPARSEMEM_VMEMMAP
+ depends on ZONE_DEVICE
+ depends on DEVICE_PRIVATE
depends on MMU
select HMM_MIRROR
select MMU_NOTIFIER
+ select MIGRATE_VMA_HELPER
default n
help
Choose this option if you want Shared Virtual Memory (SVM)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7d4cd9eefd12..b574ec31ea2e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -155,7 +155,8 @@ i915-y += \
# SVM code
i915-$(CONFIG_DRM_I915_SVM) += gem/i915_gem_svm.o \
- i915_svm.o
+ i915_svm.o \
+ i915_svm_devmem.o
# general-purpose microcontroller (GuC) support
obj-y += gt/uc/
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index a7dee1b749cb..dd88fa87b7fe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -480,19 +480,6 @@ int __init i915_global_objects_init(void)
return 0;
}
-static enum intel_region_id
-__region_id(u32 region)
-{
- enum intel_region_id id;
-
- for (id = 0; id < INTEL_REGION_UNKNOWN; ++id) {
- if (intel_region_map[id] == region)
- return id;
- }
-
- return INTEL_REGION_UNKNOWN;
-}
-
bool
i915_gem_object_svm_mapped(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_buddy.h
b/drivers/gpu/drm/i915/i915_buddy.h
index ed41f3507cdc..afc493e6c130 100644
--- a/drivers/gpu/drm/i915/i915_buddy.h
+++ b/drivers/gpu/drm/i915/i915_buddy.h
@@ -9,6 +9,9 @@
#include
#include
+/* 512 bits (one per pages) supports 2MB blocks */
+#define I915_BUDDY_MAX_PAGES 512
+
struct i915_buddy_block {
#define I915_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
#define I915_BUDDY_HEADER_STATE GENMASK_ULL(11, 10)
@@ -32,6 +35,15 @@ struct i915_buddy_block {
*/
struct list_head link;
struct list_head tmp_link;
+
+ unsigned long pfn_first;
+ /*
+* FIXME: There are other alternatives to bitmap. Like splitting the
+* block into contiguous 4K sized blocks. But it is part of bigger
+* issues involving partially invalidating large mapping, freeing the
+* blocks etc., revisit.
+*/
+ unsigned long bitmap[BITS_TO_LONGS(I915_BUDDY_MAX_PAGES)];
};
#define I915_BUDDY_MAX_ORDER I915_BUDDY_HEADER_ORDER
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c190df614c48..740b4b9d39a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2771,6 +2771,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_BIND, i915_bind_ioctl, DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_SVM_MIGRATE, i915_svm_migrate_ioctl,
DRM_RENDER_ALLOW)
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_svm.c b/drivers/gpu/drm/i915/i915_svm.c
index 4e414f257121..fe7d53634606 100644
--- a/drivers/gpu/drm/i915/i915_svm.c
+++ b/drivers/gpu/drm/i915/i915_svm.c
@@ -206,6 +206,8 @@ int
[RFC 12/13] drm/i915/svm: Add support to en/disable SVM
Add SVM as a capability and allow user to enable/disable SVM
functionality on a per context basis.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 95 ++-
drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++
drivers/gpu/drm/i915/gem/i915_gem_object.c| 11 +++
drivers/gpu/drm/i915/i915_drv.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915/i915_getparam.c | 3 +
8 files changed, 128 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 46926478ed2e..bc6cbf3b3d97 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -76,6 +76,7 @@
#include "i915_gem_context.h"
#include "i915_globals.h"
+#include "i915_svm.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
#include "i915_gem_ioctls.h"
@@ -965,6 +966,78 @@ int i915_gem_vm_destroy_ioctl(struct drm_device *dev, void
*data,
return 0;
}
+static int i915_gem_vm_setparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct drm_i915_gem_vm_param *args = data;
+ struct i915_address_space *vm;
+ int err = 0;
+ u32 id;
+
+ id = args->vm_id;
+ if (!id)
+ return -ENOENT;
+
+ err = mutex_lock_interruptible(_priv->vm_idr_lock);
+ if (err)
+ return err;
+
+ vm = idr_find(_priv->vm_idr, id);
+
+ mutex_unlock(_priv->vm_idr_lock);
+ if (!vm)
+ return -ENOENT;
+
+ switch (lower_32_bits(args->param)) {
+ case I915_GEM_VM_PARAM_SVM:
+ /* FIXME: Ensure ppgtt is empty before switching */
+ if (!i915_has_svm(file_priv->dev_priv))
+ err = -ENOTSUPP;
+ else if (args->value)
+ err = i915_svm_bind_mm(vm);
+ else
+ i915_svm_unbind_mm(vm);
+ break;
+ default:
+ err = -EINVAL;
+ }
+ return err;
+}
+
+static int i915_gem_vm_getparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct drm_i915_gem_vm_param *args = data;
+ struct i915_address_space *vm;
+ int err = 0;
+ u32 id;
+
+ id = args->vm_id;
+ if (!id)
+ return -ENOENT;
+
+ err = mutex_lock_interruptible(_priv->vm_idr_lock);
+ if (err)
+ return err;
+
+ vm = idr_find(_priv->vm_idr, id);
+
+ mutex_unlock(_priv->vm_idr_lock);
+ if (!vm)
+ return -ENOENT;
+
+ switch (lower_32_bits(args->param)) {
+ case I915_GEM_VM_PARAM_SVM:
+ args->value = i915_vm_is_svm_enabled(vm);
+ break;
+ default:
+ err = -EINVAL;
+ }
+ return err;
+}
+
struct context_barrier_task {
struct i915_active base;
void (*task)(void *data);
@@ -2379,6 +2452,21 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
return ret;
}
+int i915_gem_getparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_gem_context_param *args = data;
+ u32 class = upper_32_bits(args->param);
+
+ switch (class) {
+ case 0:
+ return i915_gem_context_getparam_ioctl(dev, data, file);
+ case 2:
+ return i915_gem_vm_getparam_ioctl(dev, data, file);
+ }
+ return -EINVAL;
+}
+
int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -2401,14 +2489,15 @@ int i915_gem_setparam_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file)
{
struct drm_i915_gem_context_param *args = data;
- u32 object_class = upper_32_bits(args->param);
+ u32 class = upper_32_bits(args->param);
- switch (object_class) {
+ switch (class) {
case 0:
return i915_gem_context_setparam_ioctl(dev, data, file);
case 1:
return i915_gem_object_setparam_ioctl(dev, data, file);
-
+ case 2:
+ return i915_gem_vm_setparam_ioctl(dev, data, file);
}
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index
[RFC 11/13] drm/i915/svm: Use blitter copy for migration
Use blitter engine to copy pages during migration.
As blitter context virtual address space is shared with other flows,
ensure virtual address are allocated properly from that address space.
Also ensure completion of blitter copy by waiting on the fence of the
issued request.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_svm_devmem.c | 249 -
1 file changed, 245 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_svm_devmem.c
b/drivers/gpu/drm/i915/i915_svm_devmem.c
index 960b04091e44..4f772983679b 100644
--- a/drivers/gpu/drm/i915/i915_svm_devmem.c
+++ b/drivers/gpu/drm/i915/i915_svm_devmem.c
@@ -15,7 +15,15 @@ struct i915_devmem_migrate {
enum intel_region_id src_id;
enum intel_region_id dst_id;
+ dma_addr_t *host_dma;
+ bool blitter_copy;
u64 npages;
+
+ /* required for blitter copy */
+ struct drm_mm_node src_node;
+ struct drm_mm_node dst_node;
+ struct intel_context *ce;
+ struct dma_fence *fence;
};
struct i915_devmem {
@@ -142,6 +150,139 @@ i915_devmem_page_free_locked(struct drm_i915_private
*dev_priv,
put_page(page);
}
+static int i915_devmem_bind_addr(struct i915_devmem_migrate *migrate,
+bool is_src)
+{
+ struct i915_gem_context *ctx = migrate->ce->gem_context;
+ struct drm_i915_private *i915 = migrate->i915;
+ struct i915_address_space *vm = ctx->vm;
+ struct intel_memory_region *mem;
+ u64 npages = migrate->npages;
+ enum intel_region_id mem_id;
+ struct drm_mm_node *node;
+ struct scatterlist *sg;
+ u32 sg_page_sizes = 0;
+ struct sg_table st;
+ u64 flags = 0;
+ int i, ret;
+
+ if (unlikely(sg_alloc_table(, npages, GFP_KERNEL)))
+ return -ENOMEM;
+
+ if (is_src) {
+ node = >src_node;
+ mem_id = migrate->src_id;
+ flags |= I915_GTT_SVM_READONLY;
+ } else {
+ node = >dst_node;
+ mem_id = migrate->dst_id;
+ }
+
+ mutex_lock(>mutex);
+ ret = i915_gem_gtt_insert(vm, node, npages * PAGE_SIZE,
+ I915_GTT_PAGE_SIZE_2M, 0,
+ 0, vm->total, PIN_USER);
+ mutex_unlock(>mutex);
+ if (unlikely(ret))
+ return ret;
+
+ sg = NULL;
+ st.nents = 0;
+
+ /*
+* XXX: If the source page is missing, source it from a temporary
+* zero filled page. If needed, destination page missing scenarios
+* can be similarly handled by draining data into a temporary page.
+*/
+ for (i = 0; i < npages; i++) {
+ u64 addr;
+
+ if (mem_id == INTEL_REGION_SMEM) {
+ addr = migrate->host_dma[i];
+ } else {
+ struct page *page;
+ unsigned long mpfn;
+
+ mpfn = is_src ? migrate->args->src[i] :
+ migrate->args->dst[i];
+ page = migrate_pfn_to_page(mpfn);
+ mem = i915->mm.regions[mem_id];
+ addr = page_to_pfn(page) - mem->devmem->pfn_first;
+ addr <<= PAGE_SHIFT;
+ addr += mem->region.start;
+ }
+
+ if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
+ sg->length += PAGE_SIZE;
+ sg_dma_len(sg) += PAGE_SIZE;
+ continue;
+ }
+
+ if (sg)
+ sg_page_sizes |= sg->length;
+
+ sg = sg ? __sg_next(sg) : st.sgl;
+ sg_dma_address(sg) = addr;
+ sg_dma_len(sg) = PAGE_SIZE;
+ sg->length = PAGE_SIZE;
+ st.nents++;
+ }
+
+ sg_page_sizes |= sg->length;
+ sg_mark_end(sg);
+ i915_sg_trim();
+
+ ret = svm_bind_addr(vm, node->start, npages * PAGE_SIZE,
+ flags, , sg_page_sizes);
+ sg_free_table();
+
+ return ret;
+}
+
+static void i915_devmem_unbind_addr(struct i915_devmem_migrate *migrate,
+ bool is_src)
+{
+ struct i915_gem_context *ctx = migrate->ce->gem_context;
+ struct i915_address_space *vm = ctx->vm;
+ struct drm_mm_node *node;
+
+ node = is_src ? >src_node : >dst_node;
+ svm_unbind_addr(vm, node->start, migrate->npages * PAGE_SIZE);
+ mutex_lock(>mutex);
+ drm_mm_remove_node(node);
+ mutex_unlock(>mutex);
+}
+
+static int i915_migrate_blitter_copy(struct i915_devmem_migrate *migrate)
+{
+ struct drm_i915_private *i915 = migrate->i915;
+ int ret;
+
+ migrate->ce = i915->engine[BCS0]->kernel_context;
+
[RFC 00/13] drm/i915/svm: Add SVM support
Shared Virtual Memory (SVM) allows the programmer to use a single virtual address space which will be shared between threads executing on CPUs and GPUs. It abstracts away from the user the location of the backing memory, and hence simplifies the user programming model. SVM supports two types of virtual memory allocation methods. Runtime allocator requires the driver to provide memory allocation and management interface, like buffer object (BO) interface. Whereas system allocator makes use of default OS memory allocation and management support like malloc(). This patch series adds both SVM system and runtime allocator support to i915 driver. The patch series includes - SVM support for both system and runtime allocation. - Plugin in device memory with the Linux kernel. - User API advertising SVM capability and configuration by user on per vm basis. - User API to bind an address range or a BO with a device page table. - User API to migrate an address range to device memory. - Implicit migration by moving pages or BOs back from device to host memory upon CPU access. - CPU copy and blitter copy support for migrating the pages/BOs. - Large page mapping support - Page table dump support. References: https://www.kernel.org/doc/Documentation/vm/hmm.rst The HMM use cases in the Linux kernel. Niranjana Vishwanathapura (12): drm/i915/svm: Add SVM documentation drm/i915/svm: Define SVM UAPI drm/i915/svm: Runtime (RT) allocator support drm/i915/svm: Page table update support for SVM drm/i915/svm: Page table mirroring support drm/i915/svm: Device memory support drm/i915/svm: Implicitly migrate pages upon CPU fault drm/i915/svm: Page copy support during migration drm/i915/svm: Add functions to blitter copy SVM buffers drm/i915/svm: Use blitter copy for migration drm/i915/svm: Add support to en/disable SVM drm/i915/svm: Add page table dump support Venkata Sandeep Dhanalakota (1): drm/i915/svm: Implicitly migrate BOs upon CPU access Documentation/gpu/i915.rst| 29 + drivers/gpu/drm/i915/Kconfig | 23 + drivers/gpu/drm/i915/Kconfig.debug| 14 + drivers/gpu/drm/i915/Makefile | 6 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 95 ++- drivers/gpu/drm/i915/gem/i915_gem_context.h | 2 + .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 65 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 43 +- drivers/gpu/drm/i915/gem/i915_gem_object.h| 6 + drivers/gpu/drm/i915/gem/i915_gem_svm.c | 51 ++ drivers/gpu/drm/i915/gem/i915_gem_svm.h | 22 + drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +- drivers/gpu/drm/i915/i915_buddy.h | 12 + drivers/gpu/drm/i915/i915_drv.c | 30 +- drivers/gpu/drm/i915/i915_drv.h | 32 + drivers/gpu/drm/i915/i915_gem_gtt.c | 158 +++- drivers/gpu/drm/i915/i915_gem_gtt.h | 41 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_svm.c | 298 +++ drivers/gpu/drm/i915/i915_svm.h | 71 ++ drivers/gpu/drm/i915/i915_svm_copy.c | 172 drivers/gpu/drm/i915/i915_svm_devmem.c| 772 ++ drivers/gpu/drm/i915/intel_memory_region.c| 4 - drivers/gpu/drm/i915/intel_memory_region.h| 18 + drivers/gpu/drm/i915/intel_region_lmem.c | 10 + include/uapi/drm/i915_drm.h | 70 ++ 28 files changed, 2024 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.h create mode 100644 drivers/gpu/drm/i915/i915_svm.c create mode 100644 drivers/gpu/drm/i915/i915_svm.h create mode 100644 drivers/gpu/drm/i915/i915_svm_copy.c create mode 100644 drivers/gpu/drm/i915/i915_svm_devmem.c -- 2.21.0.rc0.32.g243a4c7e27 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 08/13] drm/i915/svm: Implicitly migrate pages upon CPU fault
As PCIe is non-coherent link, do not allow direct memory access across
PCIe link. Handle CPU fault by migrating pages back to host memory.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/i915_svm_devmem.c | 70 +-
1 file changed, 69 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_svm_devmem.c
b/drivers/gpu/drm/i915/i915_svm_devmem.c
index 40c2f79ff614..37a205d3a82f 100644
--- a/drivers/gpu/drm/i915/i915_svm_devmem.c
+++ b/drivers/gpu/drm/i915/i915_svm_devmem.c
@@ -280,9 +280,77 @@ int i915_devmem_migrate_vma(struct intel_memory_region
*mem,
return ret;
}
+static vm_fault_t
+i915_devmem_fault_alloc_and_copy(struct i915_devmem_migrate *migrate)
+{
+ struct device *dev = migrate->i915->drm.dev;
+ struct migrate_vma *args = migrate->args;
+ struct page *dpage, *spage;
+
+ DRM_DEBUG_DRIVER("start 0x%lx\n", args->start);
+ /* Allocate host page */
+ spage = migrate_pfn_to_page(args->src[0]);
+ if (unlikely(!spage || !(args->src[0] & MIGRATE_PFN_MIGRATE)))
+ return 0;
+
+ dpage = alloc_page_vma(GFP_HIGHUSER, args->vma, args->start);
+ if (unlikely(!dpage))
+ return VM_FAULT_SIGBUS;
+ lock_page(dpage);
+
+ args->dst[0] = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
+
+ /* Copy the pages */
+ migrate->npages = 1;
+
+ return 0;
+}
+
+void i915_devmem_fault_finalize_and_map(struct i915_devmem_migrate *migrate)
+{
+ DRM_DEBUG_DRIVER("\n");
+}
+
+static inline struct i915_devmem *page_to_devmem(struct page *page)
+{
+ return container_of(page->pgmap, struct i915_devmem, pagemap);
+}
+
static vm_fault_t i915_devmem_migrate_to_ram(struct vm_fault *vmf)
{
- return VM_FAULT_SIGBUS;
+ struct i915_devmem *devmem = page_to_devmem(vmf->page);
+ struct drm_i915_private *i915 = devmem->i915;
+ struct i915_devmem_migrate migrate = {0};
+ unsigned long src = 0, dst = 0;
+ vm_fault_t ret;
+ struct migrate_vma args = {
+ .vma= vmf->vma,
+ .start = vmf->address,
+ .end= vmf->address + PAGE_SIZE,
+ .src= ,
+ .dst= ,
+ };
+
+ /* XXX: Opportunistically migrate more pages? */
+ DRM_DEBUG_DRIVER("addr 0x%lx\n", args.start);
+ migrate.i915 = i915;
+ migrate.args =
+ migrate.src_id = INTEL_REGION_LMEM;
+ migrate.dst_id = INTEL_REGION_SMEM;
+ if (migrate_vma_setup() < 0)
+ return VM_FAULT_SIGBUS;
+ if (!args.cpages)
+ return 0;
+
+ ret = i915_devmem_fault_alloc_and_copy();
+ if (ret || dst == 0)
+ goto done;
+
+ migrate_vma_pages();
+ i915_devmem_fault_finalize_and_map();
+done:
+ migrate_vma_finalize();
+ return ret;
}
static void i915_devmem_page_free(struct page *page)
--
2.21.0.rc0.32.g243a4c7e27
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 06/13] drm/i915/svm: Page table mirroring support
Use HMM page table mirroring support to build device page table.
Implement the bind ioctl and bind the process address range in the
specified context's ppgtt.
Handle invalidation notifications by unbinding the address range.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Kconfig| 3 +
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +
drivers/gpu/drm/i915/i915_svm.c | 296
drivers/gpu/drm/i915/i915_svm.h | 50 +
7 files changed, 363 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_svm.c
create mode 100644 drivers/gpu/drm/i915/i915_svm.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index c2e48710eec8..689e57fe3973 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -141,6 +141,9 @@ config DRM_I915_SVM
bool "Enable Shared Virtual Memory support in i915"
depends on STAGING
depends on DRM_I915
+ depends on MMU
+ select HMM_MIRROR
+ select MMU_NOTIFIER
default n
help
Choose this option if you want Shared Virtual Memory (SVM)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 75fe45633779..7d4cd9eefd12 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -154,7 +154,8 @@ i915-y += \
intel_wopcm.o
# SVM code
-i915-$(CONFIG_DRM_I915_SVM) += gem/i915_gem_svm.o
+i915-$(CONFIG_DRM_I915_SVM) += gem/i915_gem_svm.o \
+ i915_svm.o
# general-purpose microcontroller (GuC) support
obj-y += gt/uc/
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9c525d3f694c..c190df614c48 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -73,6 +73,7 @@
#include "i915_perf.h"
#include "i915_query.h"
#include "i915_suspend.h"
+#include "i915_svm.h"
#include "i915_switcheroo.h"
#include "i915_sysfs.h"
#include "i915_trace.h"
@@ -2700,6 +2701,8 @@ static int i915_bind_ioctl(struct drm_device *dev, void
*data,
return -ENOENT;
switch (args->type) {
+ case I915_BIND_SVM_BUFFER:
+ return i915_svm_bind(vm, args);
case I915_BIND_SVM_GEM_OBJ:
ret = i915_gem_svm_bind(vm, args, file);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d9e95229ba1d..08cbbb4d91cb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_scatterlist.h"
+#include "i915_svm.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
@@ -550,6 +551,7 @@ static void i915_address_space_fini(struct
i915_address_space *vm)
drm_mm_takedown(>mm);
mutex_destroy(>mutex);
+ mutex_destroy(>svm_mutex);
}
void __i915_vm_close(struct i915_address_space *vm)
@@ -593,6 +595,7 @@ void i915_vm_release(struct kref *kref)
GEM_BUG_ON(i915_is_ggtt(vm));
trace_i915_ppgtt_release(vm);
+ i915_svm_unbind_mm(vm);
queue_rcu_work(vm->i915->wq, >rcu);
}
@@ -608,6 +611,7 @@ static void i915_address_space_init(struct
i915_address_space *vm, int subclass)
* attempt holding the lock is immediately reported by lockdep.
*/
mutex_init(>mutex);
+ mutex_init(>svm_mutex);
lockdep_set_subclass(>mutex, subclass);
i915_gem_shrinker_taints_mutex(vm->i915, >mutex);
@@ -619,6 +623,7 @@ static void i915_address_space_init(struct
i915_address_space *vm, int subclass)
INIT_LIST_HEAD(>bound_list);
INIT_LIST_HEAD(>svm_list);
+ RCU_INIT_POINTER(vm->svm, NULL);
}
static int __setup_page_dma(struct i915_address_space *vm,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 6a8d55490e39..722b1e7ce291 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -293,6 +293,8 @@ struct i915_svm_obj {
u64 offset;
};
+struct i915_svm;
+
struct i915_address_space {
struct kref ref;
struct rcu_work rcu;
@@ -342,6 +344,8 @@ struct i915_address_space {
*/
struct list_head svm_list;
unsigned int svm_count;
+ struct i915_svm *svm;
+ struct mutex svm_mutex; /* protects svm enabling */
struct pagestash free_pages;
diff --git a/drivers/gpu/drm/i915/i915_svm.c b/drivers/gpu/drm/i915/i915_svm.c
new file mode 100644
index ..4e414f257121
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_svm.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+
+#include "i915_svm.h"
[RFC 02/13] drm/i915/svm: Define SVM UAPI
Define UAPI for Shared Virtual Memory (SVM) fucntionality including
SVM capability and configurability.
When there is no GPU page fault support available, add ioctls
to explicitly bind and migrate virtual address ranges.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Venkata Sandeep Dhanalakota
---
include/uapi/drm/i915_drm.h | 70 +
1 file changed, 70 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index b127a99da1c1..33b3127fc3ae 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -360,6 +360,10 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_VM_CREATE 0x3a
#define DRM_I915_GEM_VM_DESTROY0x3b
#define DRM_I915_GEM_OBJECT_SETPARAM DRM_I915_GEM_CONTEXT_SETPARAM
+#define DRM_I915_GEM_VM_GETPARAMDRM_I915_GEM_CONTEXT_GETPARAM
+#define DRM_I915_GEM_VM_SETPARAMDRM_I915_GEM_CONTEXT_SETPARAM
+#define DRM_I915_BIND 0x3c
+#define DRM_I915_SVM_MIGRATE 0x3d
/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -423,6 +427,10 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
#define DRM_IOCTL_I915_GEM_OBJECT_SETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_OBJECT_SETPARAM, struct drm_i915_gem_object_param)
+#define DRM_IOCTL_I915_GEM_VM_GETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_GETPARAM, struct drm_i915_gem_vm_param)
+#define DRM_IOCTL_I915_GEM_VM_SETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_SETPARAM, struct drm_i915_gem_vm_param)
+#define DRM_IOCTL_I915_BINDDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_BIND, struct drm_i915_bind)
+#define DRM_IOCTL_I915_SVM_MIGRATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SVM_MIGRATE, struct drm_i915_svm_migrate)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -620,6 +628,9 @@ typedef struct drm_i915_irq_wait {
*/
#define I915_PARAM_PERF_REVISION 54
+/* Shared Virtual Memory (SVM) support capability */
+#define I915_PARAM_HAS_SVM 55
+
/* Must be kept compact -- no holes and well documented */
typedef struct drm_i915_getparam {
@@ -1815,6 +1826,17 @@ struct drm_i915_gem_vm_control {
__u32 vm_id;
};
+struct drm_i915_gem_vm_param {
+ __u32 vm_id;
+ __u32 rsvd;
+
+#define I915_VM_PARAM (2ull << 32)
+#define I915_GEM_VM_PARAM_SVM 0x1
+ __u64 param;
+
+ __u64 value;
+};
+
struct drm_i915_reg_read {
/*
* Register offset.
@@ -2268,6 +2290,54 @@ struct drm_i915_query_perf_config {
__u8 data[];
};
+/**
+ * struct drm_i915_bind
+ *
+ * Bind an object/buffer in a vm's page table.
+ */
+struct drm_i915_bind {
+ /** VA start to bind **/
+ __u64 start;
+
+ /**
+* VA length to [un]bind
+* length only required while binding buffers.
+*/
+ __u64 length;
+
+ /** Type of memory to [un]bind **/
+ __u32 type;
+#define I915_BIND_SVM_BUFFER 0
+#define I915_BIND_SVM_GEM_OBJ 1
+
+ /** Object handle to [un]bind for I915_BIND_SVM_GEM_OBJ type **/
+ __u32 handle;
+
+ /** vm to [un]bind **/
+ __u32 vm_id;
+
+ /** Flags **/
+ __u32 flags;
+#define I915_BIND_UNBIND (1 << 0)
+#define I915_BIND_READONLY(1 << 1)
+};
+
+/**
+ * struct drm_i915_svm_migrate
+ *
+ * Migrate an address range to a memory region.
+ */
+struct drm_i915_svm_migrate {
+ /** VA start to migrate **/
+ __u64 start;
+
+ /** VA length to migrate **/
+ __u64 length;
+
+ /** Memory region to migrate to **/
+ __u32 region;
+};
+
#if defined(__cplusplus)
}
#endif
--
2.21.0.rc0.32.g243a4c7e27
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 01/13] drm/i915/svm: Add SVM documentation
Add Shared Virtual Memory (SVM) support information. Cc: Joonas Lahtinen Cc: Jon Bloomfield Cc: Daniel Vetter Cc: Sudeep Dutt Signed-off-by: Niranjana Vishwanathapura --- Documentation/gpu/i915.rst | 29 + 1 file changed, 29 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index d0947c5c4ab8..592fc26d2ca0 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -415,6 +415,35 @@ Object Tiling IOCTLs .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_tiling.c :doc: buffer object tiling +Shared Virtual Memory (SVM) +--- + +Shared Virtual Memory (SVM) allows the programmer to use a single virtual +address space which will be shared between threads executing on CPUs and GPUs. +It abstracts away from the user the location of the backing memory, and hence +simplifies the user programming model. +SVM supports two types of virtual memory allocation methods. +Runtime allocator requires the driver to provide memory allocation and +management interface, like buffer object (BO) interface. +Whereas system allocator makes use of default OS memory allocation and +management support like malloc(). + +Linux kernel has a Heterogeneous Memory Management (HMM) framework to +Support SVM system allocator. HMM’s address space mirroring support allows +sharing of the address space by duplicating sections of CPU page tables in the +device page tables. This enables both CPU and GPU access a physical memory +location using the same virtual address. Linux kernel also provides the ability +to plugin device memory with the system (as a special ZONE_DEVICE type) and +allocates struct page for each device memory page. It also provides a mechanism +to migrate pages from host to device memory and vice versa. +More information on HMM can be found here. +https://www.kernel.org/doc/Documentation/vm/hmm.rst + +i915 supports both SVM system and runtime allocator. As PCIe is a non-coherent +bus, it plugs in device memory as DEVICE_PRIVATE and no memory access across +PCIe link is allowed. Any such access will trigger migration of the page/s +or BOs before the memory is accessed. + Microcontrollers -- 2.21.0.rc0.32.g243a4c7e27 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC 13/13] drm/i915/svm: Add page table dump support
Add support to dump page table for debug purpose.
Here is an example dump. Format is,
[] :
Page Table dump start 0x0 len 0x
[0x0fe] 0x7f000: 0x6b0003
[0x1e6] 0x7f798: 0x6c0003
[0x16d] 0x7f79ada00: 0x5f0003
[0x000] 0x7f79ada00: 0x610803
[0x16e] 0x7f79adc00: 0x6d0003
[0x000] 0x7f79adc00: 0x630803
[0x100] 0x8: 0x6f0003
[0x000] 0x8: 0x70
[0x000] 0x8: 0x710003
[0x000] 0x8: 0x5d0803
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Kconfig.debug| 14 +++
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 1 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 92 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 14 +++
4 files changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 1140525da75a..06953c1d6fd4 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -223,3 +223,17 @@ config DRM_I915_DEBUG_RUNTIME_PM
driver loading, suspend and resume operations.
If in doubt, say "N"
+
+config DRM_I915_DUMP_PPGTT
+bool "Enable PPGTT Page Table dump support"
+depends on DRM_I915
+default n
+help
+ Choose this option to enable PPGTT page table dump support.
+ The page table snapshot helps developers to debug page table
+ related issues. This will affect performance and dumps a lot of
+ information, so only recommended for developer debug.
+
+ Recommended for driver developers only.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index cbcfbf86ea61..c771659d72e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2707,6 +2707,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
intel_engine_pool_mark_active(eb.batch->private, eb.request);
trace_i915_request_queue(eb.request, eb.batch_flags);
+ ppgtt_dump(eb.context->vm, 0, eb.context->vm->total);
err = eb_submit();
err_request:
add_to_client(eb.request, file);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 08cbbb4d91cb..6a7348af5717 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1215,6 +1215,97 @@ static int gen8_ppgtt_alloc(struct i915_address_space
*vm,
return err;
}
+#ifdef CONFIG_DRM_I915_DUMP_PPGTT
+static void __gen8_ppgtt_dump(struct i915_address_space * const vm,
+ struct i915_page_directory * const pd,
+ u64 start, u64 end, int lvl)
+{
+ char *prefix[4] = { "\t\t\t\t", "\t\t\t", "\t\t", "\t"};
+ char *format = "%s [0x%03x] 0x%llx: 0x%llx\n";
+ unsigned int idx, len;
+ gen8_pte_t *vaddr;
+ unsigned int pdpe;
+ bool is_large;
+
+ GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT);
+
+ len = gen8_pd_range(start, end, lvl--, );
+ GEM_BUG_ON(!len || (idx + len - 1) >> gen8_pd_shift(1));
+
+ spin_lock(>lock);
+ GEM_BUG_ON(!atomic_read(px_used(pd))); /* Must be pinned! */
+ do {
+ struct i915_page_table *pt = pd->entry[idx];
+
+ if (!pt) {
+ start += (1 << gen8_pd_shift(lvl + 1));
+ continue;
+ }
+
+ vaddr = kmap_atomic_px(>pt);
+ pdpe = gen8_pd_index(start, lvl + 1);
+ DRM_DEBUG_DRIVER(format, prefix[lvl + 1], pdpe,
+start, vaddr[pdpe]);
+ is_large = (vaddr[pdpe] & GEN8_PDE_PS_2M);
+ kunmap_atomic(vaddr);
+ if (is_large) {
+ start += (1 << gen8_pd_shift(lvl + 1));
+ continue;
+ }
+
+ if (lvl) {
+ atomic_inc(>used);
+ spin_unlock(>lock);
+
+ __gen8_ppgtt_dump(vm, as_pd(pt),
+ start, end, lvl);
+
+ start += (1 << gen8_pd_shift(lvl + 1));
+ spin_lock(>lock);
+ atomic_dec(>used);
+ GEM_BUG_ON(!atomic_read(>used));
+ } else {
+ unsigned int count = gen8_pt_count(start, end);
+
+ pdpe = gen8_pd_index(start, lvl);
+ vaddr = kmap_atomic_px(pt);
+ while (count) {
+ if (vaddr[pdpe] !=
[RFC 10/13] drm/i915/svm: Add functions to blitter copy SVM buffers
Add support function to blitter copy SVM VAs without requiring any
gem objects. Also add function to wait for completion of the copy.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
drivers/gpu/drm/i915/i915_svm.h| 6 +
drivers/gpu/drm/i915/i915_svm_copy.c | 172 +
5 files changed, 184 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_svm_copy.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b574ec31ea2e..97d40172bf27 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -156,7 +156,8 @@ i915-y += \
# SVM code
i915-$(CONFIG_DRM_I915_SVM) += gem/i915_gem_svm.o \
i915_svm.o \
- i915_svm_devmem.o
+ i915_svm_devmem.o \
+ i915_svm_copy.o
# general-purpose microcontroller (GuC) support
obj-y += gt/uc/
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index eec31d9a4fa2..3fe697659366 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -481,6 +481,9 @@ static inline void __start_cpu_write(struct
drm_i915_gem_object *obj)
int i915_gem_object_wait(struct drm_i915_gem_object *obj,
unsigned int flags,
long timeout);
+long i915_gem_object_wait_fence(struct dma_fence *fence,
+ unsigned int flags,
+ long timeout);
int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
unsigned int flags,
const struct i915_sched_attr *attr);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 8af55cd3e690..b7905aa8f821 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -12,7 +12,7 @@
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
-static long
+long
i915_gem_object_wait_fence(struct dma_fence *fence,
unsigned int flags,
long timeout)
diff --git a/drivers/gpu/drm/i915/i915_svm.h b/drivers/gpu/drm/i915/i915_svm.h
index a1b62997e925..5d28e531f737 100644
--- a/drivers/gpu/drm/i915/i915_svm.h
+++ b/drivers/gpu/drm/i915/i915_svm.h
@@ -33,6 +33,12 @@ static inline bool i915_vm_is_svm_enabled(struct
i915_address_space *vm)
return vm->svm;
}
+int i915_svm_copy_blt(struct intel_context *ce,
+ u64 src_start, u64 dst_start, u64 size,
+ struct dma_fence **fence);
+int i915_svm_copy_blt_wait(struct drm_i915_private *i915,
+ struct dma_fence *fence);
+
void i915_dmem_convert_pfn(struct drm_i915_private *dev_priv,
struct hmm_range *range);
int i915_svm_migrate_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_svm_copy.c
b/drivers/gpu/drm/i915/i915_svm_copy.c
new file mode 100644
index ..42f7d563f6b4
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_svm_copy.c
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include "gem/i915_gem_object_blt.h"
+#include "gt/intel_engine_pm.h"
+#include "gt/intel_engine_pool.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+static struct i915_vma *
+intel_emit_svm_copy_blt(struct intel_context *ce,
+ u64 src_start, u64 dst_start, u64 buff_size)
+{
+ struct drm_i915_private *i915 = ce->vm->i915;
+ const u32 block_size = SZ_8M; /* ~1ms at 8GiB/s preemption delay */
+ struct intel_engine_pool_node *pool;
+ struct i915_vma *batch;
+ u64 count, rem;
+ u32 size, *cmd;
+ int err;
+
+ GEM_BUG_ON(intel_engine_is_virtual(ce->engine));
+ intel_engine_pm_get(ce->engine);
+
+ if (INTEL_GEN(i915) < 8)
+ return ERR_PTR(-ENOTSUPP);
+
+ count = div_u64(round_up(buff_size, block_size), block_size);
+ size = (1 + 11 * count) * sizeof(u32);
+ size = round_up(size, PAGE_SIZE);
+ pool = intel_engine_get_pool(ce->engine, size);
+ if (IS_ERR(pool)) {
+ err = PTR_ERR(pool);
+ goto out_pm;
+ }
+
+ cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC);
+ if (IS_ERR(cmd)) {
+ err = PTR_ERR(cmd);
+ goto out_put;
+ }
+
+ rem = buff_size;
+ do {
+ size = min_t(u64, rem, block_size);
+ GEM_BUG_ON(size >> PAGE_SHIFT >
[RFC 03/13] drm/i915/svm: Runtime (RT) allocator support
Shared Virtual Memory (SVM) runtime allocator support allows
binding a shared virtual address to a buffer object (BO) in the
device page table through an ioctl call.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/Kconfig | 11
drivers/gpu/drm/i915/Makefile | 3 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 58 +++
drivers/gpu/drm/i915/gem/i915_gem_svm.c | 51
drivers/gpu/drm/i915/gem/i915_gem_svm.h | 22 +++
drivers/gpu/drm/i915/i915_drv.c | 22 +++
drivers/gpu/drm/i915/i915_drv.h | 22 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 13 +
9 files changed, 192 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.c
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_svm.h
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index ba9595960bbe..c2e48710eec8 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -137,6 +137,17 @@ config DRM_I915_GVT_KVMGT
Choose this option if you want to enable KVMGT support for
Intel GVT-g.
+config DRM_I915_SVM
+ bool "Enable Shared Virtual Memory support in i915"
+ depends on STAGING
+ depends on DRM_I915
+ default n
+ help
+ Choose this option if you want Shared Virtual Memory (SVM)
+ support in i915. With SVM support, one can share the virtual
+ address space between a process and the GPU. SVM is supported
+ on both integrated and discrete Intel GPUs.
+
menu "drm/i915 Debugging"
depends on DRM_I915
depends on EXPERT
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e0fd10c0cfb8..75fe45633779 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -153,6 +153,9 @@ i915-y += \
intel_region_lmem.o \
intel_wopcm.o
+# SVM code
+i915-$(CONFIG_DRM_I915_SVM) += gem/i915_gem_svm.o
+
# general-purpose microcontroller (GuC) support
obj-y += gt/uc/
i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 7a87e8270460..9d43ae6d643a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2864,10 +2864,14 @@ int
i915_gem_execbuffer2_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
+ struct drm_i915_gem_exec_object2 *exec2_list, *exec2_list_user;
struct drm_i915_gem_execbuffer2 *args = data;
- struct drm_i915_gem_exec_object2 *exec2_list;
- struct drm_syncobj **fences = NULL;
const size_t count = args->buffer_count;
+ struct drm_syncobj **fences = NULL;
+ unsigned int i = 0, svm_count = 0;
+ struct i915_address_space *vm;
+ struct i915_gem_context *ctx;
+ struct i915_svm_obj *svm_obj;
int err;
if (!check_buffer_count(count)) {
@@ -2878,15 +2882,46 @@ i915_gem_execbuffer2_ioctl(struct drm_device *dev, void
*data,
if (!i915_gem_check_execbuffer(args))
return -EINVAL;
+ ctx = i915_gem_context_lookup(file->driver_priv, args->rsvd1);
+ if (!ctx || !rcu_access_pointer(ctx->vm))
+ return -ENOENT;
+
+ rcu_read_lock();
+ vm = i915_vm_get(ctx->vm);
+ rcu_read_unlock();
+
+alloc_again:
+ svm_count = vm->svm_count;
/* Allocate an extra slot for use by the command parser */
- exec2_list = kvmalloc_array(count + 1, eb_element_size(),
+ exec2_list = kvmalloc_array(count + svm_count + 1, eb_element_size(),
__GFP_NOWARN | GFP_KERNEL);
if (exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %zd buffers\n",
- count);
+ count + svm_count);
return -ENOMEM;
}
- if (copy_from_user(exec2_list,
+ mutex_lock(>mutex);
+ if (svm_count != vm->svm_count) {
+ mutex_unlock(>mutex);
+ kvfree(exec2_list);
+ goto alloc_again;
+ }
+
+ list_for_each_entry(svm_obj, >svm_list, link) {
+ memset(_list[i], 0, sizeof(*exec2_list));
+ exec2_list[i].handle = svm_obj->handle;
+ exec2_list[i].offset = svm_obj->offset;
+ exec2_list[i].flags = EXEC_OBJECT_PINNED |
+ EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ i++;
+ }
+ exec2_list_user = _list[i];
+ args->buffer_count += svm_count;
+ mutex_unlock(>mutex);
+ i915_vm_put(vm);
+ i915_gem_context_put(ctx);
+
+ if
[pull] radeon, amdgpu drm-next-5.5
Hi Dave, Daniel, Fixes for 5.5. The following changes since commit 17eee668b3cad423a47c090fe2275733c55db910: Merge tag 'drm-misc-next-fixes-2019-11-20' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-11-21 10:19:45 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.5-2019-11-22 for you to fetch changes up to f920d1bb9c4e77efb08c41d70b6d442f46fd8902: drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10 (2019-11-22 14:55:19 -0500) drm-next-5.5-2019-11-22: amdgpu: - Fix bad DMA on some PPC platforms - MMHUB fix for powergating - BACO fix for Navi - Misc raven fixes - Enable vbios fetch directly from rom on navi - debugfs fix for DC - SR-IOV fixes for arcturus - Misc power fixes radeon: - Fix bad DMA on some PPC platforms Alex Deucher (6): drm/amdgpu/nv: add asic func for fetching vbios from rom directly drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK (v2) drm/amdgpu: disable gfxoff when using register read interface drm/amdgpu: remove experimental flag for Navi14 drm/amdgpu: disable gfxoff on original raven Revert "drm/amd/display: enable S/G for RAVEN chip" Evan Quan (4): drm/amd/powerplay: avoid DPM reenable process on Navi1x ASICs V2 drm/amd/powerplay: issue BTC on Navi during SMU setup drm/amd/powerplay: issue no PPSMC_MSG_GetCurrPkgPwr on unsupported ASICs drm/amd/powerplay: correct fine grained dpm force level setting Jack Zhang (2): drm/amd/amdgpu/sriov temporarily skip ras,dtm,hdcp for arcturus VF drm/amd/amdgpu/sriov skip RLCG s/r list for arcturus VF. Jay Cornwall (1): drm/amdgpu: Update Arcturus golden registers Leo Liu (1): drm/amdgpu/vcn2.5: fix the enc loop with hw fini Mikita Lipski (1): drm/amd/display: Fix debugfs on MST connectors Sam Bobroff (2): drm/radeon: fix bad DMA from INTERRUPT_CNTL2 drm/amdgpu: fix bad DMA from INTERRUPT_CNTL2 Stephen Rothwell (1): merge fix for "ftrace: Rework event_create_dir()" Xiaojie Yuan (4): drm/amdgpu/gfx10: fix mqd backup/restore for gfx rings (v2) drm/amdgpu/gfx10: explicitly wait for cp idle after halt/unhalt drm/amdgpu/gfx10: fix out-of-bound mqd_backup array access drm/amdgpu/gfx10: re-init clear state buffer after gpu reset Yintian Tao (1): drm/amdgpu: put flush_delayed_work at first changzhu (2): drm/amdgpu: initialize vm_inv_eng0_sem for gfxhub and mmhub drm/amdgpu: invalidate mmhub semaphore workaround in gmc9/gmc10 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 8 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 2 - drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 41 +- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 66 ++ drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10 +++- drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 2 + drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 2 + drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 57 +++ drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 57 +++ drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 2 + drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c| 2 + drivers/gpu/drm/amd/amdgpu/mmhub_v9_4.c| 4 ++ drivers/gpu/drm/amd/amdgpu/nv.c| 24 +++- drivers/gpu/drm/amd/amdgpu/si_ih.c | 3 +- drivers/gpu/drm/amd/amdgpu/soc15.h | 4 +- drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 6 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +++- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 33 +-- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 9 +++ drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 23 ++-- drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 + drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 18 ++ drivers/gpu/drm/radeon/cik.c | 4 +- drivers/gpu/drm/radeon/r600.c | 4 +- drivers/gpu/drm/radeon/si.c| 4 +- 32 files changed, 362 insertions(+), 53 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 06/13] drm/i915/svm: Page table mirroring support
On Fri, Nov 22, 2019 at 08:14:51PM +, Jason Gunthorpe wrote:
On Fri, Nov 22, 2019 at 12:01:17PM -0800, Niranjan Vishwanathapura wrote:
On Fri, Nov 22, 2019 at 11:54:45AM -0800, Niranjana Vishwanathapura wrote:
> Use HMM page table mirroring support to build device page table.
> Implement the bind ioctl and bind the process address range in the
> specified context's ppgtt.
> Handle invalidation notifications by unbinding the address range.
>
> Cc: Joonas Lahtinen
> Cc: Jon Bloomfield
> Cc: Daniel Vetter
> Cc: Sudeep Dutt
> Signed-off-by: Niranjana Vishwanathapura
> +int i915_svm_bind_mm(struct i915_address_space *vm)
> +{
> + struct i915_svm *svm;
> + struct mm_struct *mm;
> + int ret = 0;
> +
> + mm = get_task_mm(current);
> + down_write(>mmap_sem);
> + mutex_lock(>svm_mutex);
> + if (vm->svm)
> + goto bind_out;
> +
> + svm = kzalloc(sizeof(*svm), GFP_KERNEL);
> + if (!svm) {
> + ret = -ENOMEM;
> + goto bind_out;
> + }
> + svm->mirror.ops = _mirror_ops;
> + mutex_init(>mutex);
> + kref_init(>ref);
> + svm->mm = mm;
> + svm->vm = vm;
> +
> + ret = hmm_mirror_register(>mirror, mm);
I saw that these APIs have been removed.
I will update once it gets included in kernel release.
I would like to see all the mmu notifier use in i916 updated to use
the new APIs :)
Please cc me when you post patches using the new APIs, I'd like to see
how they are being used.
Ok, sure, will do.
Thanks,
Niranjana
Regards,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 06/13] drm/i915/svm: Page table mirroring support
On Fri, Nov 22, 2019 at 11:54:45AM -0800, Niranjana Vishwanathapura wrote:
Use HMM page table mirroring support to build device page table.
Implement the bind ioctl and bind the process address range in the
specified context's ppgtt.
Handle invalidation notifications by unbinding the address range.
Cc: Joonas Lahtinen
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Sudeep Dutt
Signed-off-by: Niranjana Vishwanathapura
---
+int i915_svm_bind_mm(struct i915_address_space *vm)
+{
+ struct i915_svm *svm;
+ struct mm_struct *mm;
+ int ret = 0;
+
+ mm = get_task_mm(current);
+ down_write(>mmap_sem);
+ mutex_lock(>svm_mutex);
+ if (vm->svm)
+ goto bind_out;
+
+ svm = kzalloc(sizeof(*svm), GFP_KERNEL);
+ if (!svm) {
+ ret = -ENOMEM;
+ goto bind_out;
+ }
+ svm->mirror.ops = _mirror_ops;
+ mutex_init(>mutex);
+ kref_init(>ref);
+ svm->mm = mm;
+ svm->vm = vm;
+
+ ret = hmm_mirror_register(>mirror, mm);
I saw that these APIs have been removed.
I will update once it gets included in kernel release.
Niranjana
+ if (ret)
+ goto bind_out;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109294] [CI][SHARDS] igt@prime_vgem@basic-fence-flip - skip - Test requirement: (crtc_id = set_fb_on_crtc(i915, 0, [0], fb_id[0])), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=109294 --- Comment #11 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109294] [CI][SHARDS] igt@prime_vgem@basic-fence-flip - skip - Test requirement: (crtc_id = set_fb_on_crtc(i915, 0, [0], fb_id[0])), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=109294 swathi.dhanavant...@intel.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #10 from swathi.dhanavant...@intel.com --- Last seen drmtip_281 (6 months, 2 weeks old), not seen in the last 126 runs, so closing and archiving this -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 4/7] drm/sun4i: dsi: Handle bus clock explicitly
Hi,
On Fri, Nov 22, 2019 at 11:48 PM Maxime Ripard wrote:
>
> Hi,
>
> On Thu, Nov 21, 2019 at 05:24:47PM +0530, Jagan Teki wrote:
> > On Sun, Nov 3, 2019 at 11:02 PM Maxime Ripard wrote:
> > >
> > > On Fri, Nov 01, 2019 at 07:42:55PM +0530, Jagan Teki wrote:
> > > > Hi Maxime,
> > > >
> > > > On Tue, Oct 29, 2019 at 2:24 PM Maxime Ripard
> > > > wrote:
> > > > >
> > > > > On Tue, Oct 29, 2019 at 04:03:56AM +0530, Jagan Teki wrote:
> > > > > > > > explicit handling of common clock would require since the A64
> > > > > > > > doesn't need to mention the clock-names explicitly in dts since
> > > > > > > > it
> > > > > > > > support only one bus clock.
> > > > > > > >
> > > > > > > > Also pass clk_id NULL instead "bus" to regmap clock init
> > > > > > > > function
> > > > > > > > since the single clock variants no need to mention clock-names
> > > > > > > > explicitly.
> > > > > > >
> > > > > > > You don't need explicit clock handling. Passing NULL as the
> > > > > > > argument
> > > > > > > in regmap_init_mmio_clk will make it use the first clock, which
> > > > > > > is the
> > > > > > > bus clock.
> > > > > >
> > > > > > Indeed I tried that, since NULL clk_id wouldn't enable the bus clock
> > > > > > during regmap_mmio_gen_context code, passing NULL triggering vblank
> > > > > > timeout.
> > > > >
> > > > > There's a bunch of users of NULL in tree, so finding out why NULL
> > > > > doesn't work is the way forward.
> > > >
> > > > I'd have looked the some of the users before checking the code as
> > > > well. As I said passing NULL clk_id to devm_regmap_init_mmio_clk =>
> > > > __devm_regmap_init_mmio_clk would return before processing the clock.
> > > >
> > > > Here is the code snippet on the tree just to make sure I'm on the same
> > > > page or not.
> > > >
> > > > static struct regmap_mmio_context *regmap_mmio_gen_context(struct
> > > > device *dev,
> > > > const char *clk_id,
> > > > void __iomem *regs,
> > > > const struct regmap_config
> > > > *config)
> > > > {
> > > > ---
> > > > --
> > > > if (clk_id == NULL)
> > > > return ctx;
> > > >
> > > > ctx->clk = clk_get(dev, clk_id);
> > > > if (IS_ERR(ctx->clk)) {
> > > > ret = PTR_ERR(ctx->clk);
> > > > goto err_free;
> > > > }
> > > >
> > > > ret = clk_prepare(ctx->clk);
> > > > if (ret < 0) {
> > > > clk_put(ctx->clk);
> > > > goto err_free;
> > > > }
> > > > -
> > > > ---
> > > > }
> > > >
> > > > Yes, I did check on the driver in the tree before committing explicit
> > > > clock handle, which make similar requirements like us in [1]. this
> > > > imx2 wdt driver is handling the explicit clock as well. I'm sure this
> > > > driver is updated as I have seen few changes related to this driver in
> > > > ML.
> > >
> > > I guess we have two ways to go at this then.
> > >
> > > Either we remove the return, but it might have a few side-effects, or
> > > we call clk_get with NULL or bus depending on the case, and then call
> > > regmap_mmio_attach_clk.
> >
> > Thanks for the inputs.
> >
> > Please have a look at this snippet, I have used your second
> > suggestions. let me know if you have any comments?
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 8fa90cfc2ac8..91c95e56d870 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -1109,24 +1109,36 @@ static int sun6i_dsi_probe(struct platform_device
> > *pdev)
> > return PTR_ERR(dsi->regulator);
> > }
> >
> > -dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base,
> > - _dsi_regmap_config);
> > -if (IS_ERR(dsi->regs)) {
> > -dev_err(dev, "Couldn't create the DSI encoder regmap\n");
> > -return PTR_ERR(dsi->regs);
> > -}
> > -
> > dsi->reset = devm_reset_control_get_shared(dev, NULL);
> > if (IS_ERR(dsi->reset)) {
> > dev_err(dev, "Couldn't get our reset line\n");
> > return PTR_ERR(dsi->reset);
> > }
> >
> > +dsi->regs = regmap_init_mmio(dev, base, _dsi_regmap_config);
>
> You should use the devm variant here
Sure.
>
> > +if (IS_ERR(dsi->regs)) {
> > +dev_err(dev, "Couldn't init regmap\n");
> > +return PTR_ERR(dsi->regs);
> > +}
> > +
> > +dsi->bus_clk = devm_clk_get(dev, NULL);
>
> I guess you still need to pass 'bus' here?
But the idea here is not to specify clock name explicitly to support
A64. otherwise A64 would fail as we are not specifying the clock-names
explicitly on dsi node.
dsi: dsi@1ca {
compatible = "allwinner,sun50i-a64-mipi-dsi";
reg = <0x01ca 0x1000>;
[PATCH AUTOSEL 4.19 13/25] drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.
From: Yunhao Tian [ Upstream commit 0b8e7bbde5e7e2c419567e1ee29587dae3b78ee3 ] The datasheet of V3s (and various other chips) wrote that TCON0_DCLK_DIV can be >= 1 if only dclk is used, and must >= 6 if dclk1 or dclk2 is used. As currently neither dclk1 nor dclk2 is used (no writes to these bits), let's set minimal division to 1. If this minimal division is 6, some common dot clock frequencies can't be produced (e.g. 30MHz will not be possible and will fallback to 25MHz), which is obviously not an expected behaviour. Signed-off-by: Yunhao Tian Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/linux-arm-kernel/mn2pr08mb57905ad8a00c08da219377c989...@mn2pr08mb5790.namprd08.prod.outlook.com/ Signed-off-by: Sasha Levin --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 8c31c9ab06f8b..fda1ae12069a7 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -423,7 +423,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, WARN_ON(!tcon->quirks->has_channel_0); - tcon->dclk_min_div = 6; + tcon->dclk_min_div = 1; tcon->dclk_max_div = 127; sun4i_tcon0_mode_set_common(tcon, mode); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: opregion: set opregion chpd value to indicate the driver handles hotplug
On Fri, Nov 22, 2019 at 08:04:39PM +0100, Hans de Goede wrote:
> According to both the old acpi_igd_opregion_spec_0.pdf and the newer
> skl_opregion_rev0p5.pdf opregion specification documents, if a driver
> handles hotplug events itself, it should set the opregion CHPD field to
> 1 to indicate this and the firmware should respond to this by no longer
> sending ACPI 0x00 notification events on e.g. lid-state changes.
>
> Specifically skl_opregion_rev0p5.pdf states thid in the documentation of
> the CHPD word: "Re-enumeration trigger logic in System BIOS MUST be
> disabled for all the Operating Systems supporting Hot-Plug
> (e.g., Windows* Longhorn and above)." Note the MUST in there.
Feels like the spec was written by a politician. It's left to the
reader to interpret each statement either one way or the other.
But I can get behind your interpretation, especially if it makes the
firmware stop doing silly things.
Reviewed-by: Ville Syrjälä
BTW at some point I was looking for other ways to get the firmware
to stop messing things. I found a bunch of scratch registers which
supposedly might do something like that:
git://github.com/vsyrjala/linux.git vbios_swf
but in the end I don't think that fixed the issue I was trying
to sort out, which IIRC was the fact that some old laptops don't
survive S4 if we put the GPU into D3.
>
> We ignore these notifications, so this should not be a problem but many
> recent DSTDs seem to all have the same copy-pasted bug in the GNOT() AML
> function which is used to send these notifications. Windows likely does not
> hit this bug as it presumably correcty sets CHPD to 1.
>
> Here is an example of the broken GNOT() method:
>
> Method (GNOT, 2, NotSerialized)
> {
> ...
> CEVT = Arg0
> CSTS = 0x03
> If (((CHPD == Zero) && (Arg1 == Zero)))
> {
> If (((OSYS > 0x07D0) || (OSYS < 0x07D6)))
> {
> Notify (PCI0, Arg1)
> }
> Else
> {
> Notify (GFX0, Arg1)
> }
> }
> ...
>
> Notice that the condition for the If is always true I believe that the
> || like needs to be an &&, but there is nothing we can do about this and
> in my own DSDT archive 55 of the 93 DSDTs have this issue.
>
> When the if is true the notification gets send to the PCI root instead
> of only to the GFX0 device. This causes Linux to re-enumerate PCI devices
> whenever the LID opens / closes, leading to unexpected messages in dmesg:
>
> Suspend through lid close:
> [ 313.598199] intel_atomisp2_pm :00:03.0: Refused to change power state,
> currently in D3
> [ 313.664453] intel_atomisp2_pm :00:03.0: Refused to change power state,
> currently in D3
> [ 313.737982] pci_bus :01: Allocating resources
> [ 313.738036] pcieport :00:1c.0: bridge window [io 0x1000-0x0fff] to
> [bus 01] add_size 1000
> [ 313.738051] pcieport :00:1c.0: bridge window [mem
> 0x0010-0x000f 64bit pref] to [bus 01] add_size 20 add_align 10
> [ 313.738111] pcieport :00:1c.0: BAR 15: assigned [mem
> 0x9100-0x911f 64bit pref]
> [ 313.738128] pcieport :00:1c.0: BAR 13: assigned [io 0x1000-0x1fff]
>
> Resume:
> [ 813.623894] pci :00:03.0: [8086:22b8] type 00 class 0x048000
> [ 813.623955] pci :00:03.0: reg 0x10: [mem 0x-0x003f]
> [ 813.630477] pci :00:03.0: BAR 0: assigned [mem 0x91c0-0x91ff]
> [ 854.579101] intel_atomisp2_pm :00:03.0: Refused to change power state,
> currently in D3
>
> And more importantly this re-enumeration races with suspend/resume causing
> enumeration to not be complete when assert_isp_power_gated() from
> drivers/gpu/drm/i915/display/intel_display_power.c runs. This causes
> the !pci_dev_present(isp_ids) check in assert_isp_power_gated() to fail
> making the condition for the WARN true, leading to:
>
> [ 813.327886] [ cut here ]
> [ 813.327898] ISP not power gated
> [ 813.328028] WARNING: CPU: 2 PID: 2317 at
> drivers/gpu/drm/i915/display/intel_display_power.c:4870
> intel_display_print_error_state+0x2b98/0x3a80 [i915]
> ...
> [ 813.328599] ---[ end trace f01e81b599596774 ]---
>
> This commit fixes the unwanted ACPI notification on the PCI root device
> by setting CHPD to 1, so that the broken if condition in the AML never
> gets checked as notifications of type 0x00 are disabled altogether.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index 969ade623691..e59b4992ba1b 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
[PATCH] MAINTAINERS: Drop Rex Zhu for amdgpu powerplay
No longer works on the driver. Signed-off-by: Alex Deucher --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index b63c291ad029..d518588b9879 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -856,7 +856,6 @@ S: Maintained F: drivers/i2c/busses/i2c-amd-mp2* AMD POWERPLAY -M: Rex Zhu M: Evan Quan L: amd-...@lists.freedesktop.org S: Supported -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: opregion: set opregion chpd value to indicate the driver handles hotplug
According to both the old acpi_igd_opregion_spec_0.pdf and the newer
skl_opregion_rev0p5.pdf opregion specification documents, if a driver
handles hotplug events itself, it should set the opregion CHPD field to
1 to indicate this and the firmware should respond to this by no longer
sending ACPI 0x00 notification events on e.g. lid-state changes.
Specifically skl_opregion_rev0p5.pdf states thid in the documentation of
the CHPD word: "Re-enumeration trigger logic in System BIOS MUST be
disabled for all the Operating Systems supporting Hot-Plug
(e.g., Windows* Longhorn and above)." Note the MUST in there.
We ignore these notifications, so this should not be a problem but many
recent DSTDs seem to all have the same copy-pasted bug in the GNOT() AML
function which is used to send these notifications. Windows likely does not
hit this bug as it presumably correcty sets CHPD to 1.
Here is an example of the broken GNOT() method:
Method (GNOT, 2, NotSerialized)
{
...
CEVT = Arg0
CSTS = 0x03
If (((CHPD == Zero) && (Arg1 == Zero)))
{
If (((OSYS > 0x07D0) || (OSYS < 0x07D6)))
{
Notify (PCI0, Arg1)
}
Else
{
Notify (GFX0, Arg1)
}
}
...
Notice that the condition for the If is always true I believe that the
|| like needs to be an &&, but there is nothing we can do about this and
in my own DSDT archive 55 of the 93 DSDTs have this issue.
When the if is true the notification gets send to the PCI root instead
of only to the GFX0 device. This causes Linux to re-enumerate PCI devices
whenever the LID opens / closes, leading to unexpected messages in dmesg:
Suspend through lid close:
[ 313.598199] intel_atomisp2_pm :00:03.0: Refused to change power state,
currently in D3
[ 313.664453] intel_atomisp2_pm :00:03.0: Refused to change power state,
currently in D3
[ 313.737982] pci_bus :01: Allocating resources
[ 313.738036] pcieport :00:1c.0: bridge window [io 0x1000-0x0fff] to [bus
01] add_size 1000
[ 313.738051] pcieport :00:1c.0: bridge window [mem 0x0010-0x000f
64bit pref] to [bus 01] add_size 20 add_align 10
[ 313.738111] pcieport :00:1c.0: BAR 15: assigned [mem
0x9100-0x911f 64bit pref]
[ 313.738128] pcieport :00:1c.0: BAR 13: assigned [io 0x1000-0x1fff]
Resume:
[ 813.623894] pci :00:03.0: [8086:22b8] type 00 class 0x048000
[ 813.623955] pci :00:03.0: reg 0x10: [mem 0x-0x003f]
[ 813.630477] pci :00:03.0: BAR 0: assigned [mem 0x91c0-0x91ff]
[ 854.579101] intel_atomisp2_pm :00:03.0: Refused to change power state,
currently in D3
And more importantly this re-enumeration races with suspend/resume causing
enumeration to not be complete when assert_isp_power_gated() from
drivers/gpu/drm/i915/display/intel_display_power.c runs. This causes
the !pci_dev_present(isp_ids) check in assert_isp_power_gated() to fail
making the condition for the WARN true, leading to:
[ 813.327886] [ cut here ]
[ 813.327898] ISP not power gated
[ 813.328028] WARNING: CPU: 2 PID: 2317 at
drivers/gpu/drm/i915/display/intel_display_power.c:4870
intel_display_print_error_state+0x2b98/0x3a80 [i915]
...
[ 813.328599] ---[ end trace f01e81b599596774 ]---
This commit fixes the unwanted ACPI notification on the PCI root device
by setting CHPD to 1, so that the broken if condition in the AML never
gets checked as notifications of type 0x00 are disabled altogether.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_opregion.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
b/drivers/gpu/drm/i915/display/intel_opregion.c
index 969ade623691..e59b4992ba1b 100644
--- a/drivers/gpu/drm/i915/display/intel_opregion.c
+++ b/drivers/gpu/drm/i915/display/intel_opregion.c
@@ -941,6 +941,13 @@ int intel_opregion_setup(struct drm_i915_private *dev_priv)
if (mboxes & MBOX_ACPI) {
DRM_DEBUG_DRIVER("Public ACPI methods supported\n");
opregion->acpi = base + OPREGION_ACPI_OFFSET;
+ /*
+* Indicate we handle monitor hotplug events ourselves so we do
+* not need ACPI notifications for them. Disabling these avoids
+* triggering the AML code doing the notifation, which may be
+* broken as Windows also seems to disable these.
+*/
+ opregion->acpi->chpd = 1;
}
if (mboxes & MBOX_SWSCI) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/dsc: Return unsigned long on compute offset
From: Mikita Lipski
We shouldn't compare int with unsigned long to find the max value
and since we are not expecting negative value returned from
compute_offset we should make this function return unsigned long
so we can compare the values when computing rc parameters.
v2: Modified function parameters to unsigned type for type
consistency
Cc: Ville Syrjälä
Cc: Nikola Cornij
Cc: Harry Wentland
Signed-off-by: Mikita Lipski
---
drivers/gpu/drm/drm_dsc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
index 74f3527f567d..ccce0297da64 100644
--- a/drivers/gpu/drm/drm_dsc.c
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -245,11 +245,11 @@ void drm_dsc_pps_payload_pack(struct
drm_dsc_picture_parameter_set *pps_payload,
}
EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
-static int compute_offset(struct drm_dsc_config *vdsc_cfg, int
pixels_per_group,
- int groups_per_line, int grpcnt)
+static unsigned long compute_offset(struct drm_dsc_config *vdsc_cfg, unsigned
int pixels_per_group,
+ unsigned long groups_per_line, unsigned long
grpcnt)
{
- int offset = 0;
- int grpcnt_id = DIV_ROUND_UP(vdsc_cfg->initial_xmit_delay,
pixels_per_group);
+ unsigned long offset = 0;
+ unsigned long grpcnt_id = DIV_ROUND_UP(vdsc_cfg->initial_xmit_delay,
pixels_per_group);
if (grpcnt <= grpcnt_id)
offset = DIV_ROUND_UP(grpcnt * pixels_per_group *
vdsc_cfg->bits_per_pixel, 16);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/7] drm: Extract page_flip_{internal, atomic}()
On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote:
> On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Yank out the code for the plane->fb/old_fb/crtc handling from
> > the page flip path into page_flip_internal(), and provide a
> > simpler variant for atomic drivers.
> >
> > We'll also move the fb vs. src viewport checks into the new
> > functions as they are slightly different between the two paths.
> > If the atomic .page_flip() implementations are guaranteed
> > to call drm_atomic_plane_check() we could even drop the check
> > entirely from page_flip_atomic(). For now toss in a FIXME.
> >
> > v2: Bit more polish in page_flip_internal()
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_plane.c | 159 +++-
> > 1 file changed, 102 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 38878da5b704..6052475a20a5 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1031,13 +1031,109 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
> > return drm_mode_cursor_common(dev, req, file_priv);
> > }
> >
> > +static int page_flip_check_fbs(const struct drm_framebuffer *fb,
> > + const struct drm_framebuffer *old_fb)
> > +{
> > + /* The framebuffer is currently unbound, presumably
> > +* due to a hotplug event, that userspace has not
> > +* yet discovered.
> > +*/
> > + if (!old_fb)
> > + return -EBUSY;
> > +
> > + if (old_fb->format != fb->format) {
> > + DRM_DEBUG_KMS("Page flip is not allowed to change frame buffer
> > format.\n");
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int page_flip_internal(struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct drm_pending_vblank_event *e,
> > + u32 flags,
> > + u32 target_vblank,
> > + struct drm_modeset_acquire_ctx *ctx)
> > +{
> > + struct drm_plane *plane = crtc->primary;
> > + int ret;
> > +
> > + WARN_ON(drm_drv_uses_atomic_modeset(crtc->dev));
> > +
> > + ret = drm_crtc_check_viewport(crtc, crtc->x, crtc->y,
> > + >mode, fb);
> > + if (ret)
> > + return ret;
> > +
> > + ret = page_flip_check_fbs(fb, plane->fb);
> > + if (ret)
> > + return ret;
> > +
> > + plane->old_fb = plane->fb;
> > + if (crtc->funcs->page_flip_target)
> > + ret = crtc->funcs->page_flip_target(crtc, fb, e, flags,
> > + target_vblank, ctx);
> > + else
> > + ret = crtc->funcs->page_flip(crtc, fb, e, flags, ctx);
> > + if (ret) {
> > + plane->old_fb = NULL;
> > + return ret;
> > + }
> > +
> > + plane->fb = fb;
> > + drm_framebuffer_get(plane->fb);
> > +
> > + drm_framebuffer_put(plane->old_fb);
> > + plane->old_fb = NULL;
> > +
> > + return 0;
> > +}
> > +
> > +static int page_flip_atomic(struct drm_crtc *crtc,
> > + struct drm_framebuffer *fb,
> > + struct drm_pending_vblank_event *e,
> > + u32 flags,
> > + u32 target_vblank,
> > + struct drm_modeset_acquire_ctx *ctx)
> > +{
> > + struct drm_plane *plane = crtc->primary;
> > + struct drm_plane_state *plane_state = plane->state;
> > + int ret;
> > +
> > + WARN_ON(!drm_drv_uses_atomic_modeset(crtc->dev));
> > +
> > + /*
> > +* FIXME: Can we assume all drivers end up calling
> > +* drm_atomic_plane_check() in their page flip paths?
> > +* If so we could remove this.
> > +*/
>
> This is definitely wrong, core has to check these. Currently no driver
> checks this at all. I think you're thinking of
> drm_atomic_helper_check_plane_state().
No, I'm thinking of drm_atomic_plane_check(). That one already does the
"does the src rect fit into the fb" check. It gets called from
drm_atomic_commit()->drm_atomic_check_only() but I wasn't sure if some
drivers might take some short circuit path past that for page_flip().
>
> That aside I'm kinda not getting the point of the shuffling/cleanup in the
> first 4 patches here, so will skip them.
The point was to get that legacy plane->fb/old_fb stuff totally
out from the atomic codepath. Right now it's polluting the
supposedly higher level code shared by both atomic and legacy
drivers.
> -Daniel
>
> > + ret = drm_framebuffer_check_src_coords(plane_state->src_x,
> > + plane_state->src_y,
> > + plane_state->src_w,
> > + plane_state->src_h,
> > + fb);
> > + if (ret)
> > +
Re: [PATCH 0/2] drm/amd: Use ARRAY_SIZE
Applied the series. Thanks! Alex On Fri, Nov 22, 2019 at 4:01 AM zhengbin wrote: > > zhengbin (2): > drm/amd/powerplay: Use ARRAY_SIZE for smu7_profiling > drm/amdgpu: Use ARRAY_SIZE for sos_old_versions > > drivers/gpu/drm/amd/amdgpu/psp_v3_1.c| 2 +- > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > -- > 2.7.4 > > ___ > 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 2/2] drm: share address space for dma bufs
On Fri, Nov 22, 2019 at 4:17 AM Daniel Vetter wrote:
>
> On Fri, Nov 22, 2019 at 7:37 AM Gerd Hoffmann wrote:
> >
> > Use the shared address space of the drm device (see drm_open() in
> > drm_file.c) for dma-bufs too. That removes a difference betweem drm
> > device mmap vmas and dma-buf mmap vmas and fixes corner cases like
> > dropping ptes (using madvise(DONTNEED) for example) not working
> > properly.
> >
> > Also remove amdgpu driver's private dmabuf update. It is not needed
> > any more now that we are doing this for everybody.
> >
> > Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Daniel Vetter
>
> But I think you want at least an ack from amd guys for double checking here.
> -Daniel
Looks correct to me.
Reviewed-by: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +---
> > drivers/gpu/drm/drm_prime.c | 4 +++-
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > index d5bcdfefbad6..586db4fb46bd 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > @@ -361,10 +361,8 @@ struct dma_buf *amdgpu_gem_prime_export(struct
> > drm_gem_object *gobj,
> > return ERR_PTR(-EPERM);
> >
> > buf = drm_gem_prime_export(gobj, flags);
> > - if (!IS_ERR(buf)) {
> > - buf->file->f_mapping = gobj->dev->anon_inode->i_mapping;
> > + if (!IS_ERR(buf))
> > buf->ops = _dmabuf_ops;
> > - }
> >
> > return buf;
> > }
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index a9633bd241bb..c3fc341453c0 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -240,6 +240,7 @@ void drm_prime_destroy_file_private(struct
> > drm_prime_file_private *prime_fpriv)
> > struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
> > struct dma_buf_export_info *exp_info)
> > {
> > + struct drm_gem_object *obj = exp_info->priv;
> > struct dma_buf *dma_buf;
> >
> > dma_buf = dma_buf_export(exp_info);
> > @@ -247,7 +248,8 @@ struct dma_buf *drm_gem_dmabuf_export(struct drm_device
> > *dev,
> > return dma_buf;
> >
> > drm_dev_get(dev);
> > - drm_gem_object_get(exp_info->priv);
> > + drm_gem_object_get(obj);
> > + dma_buf->file->f_mapping = obj->dev->anon_inode->i_mapping;
> >
> > return dma_buf;
> > }
> > --
> > 2.18.1
> >
>
>
> --
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/selftests: Add drm_rect selftests
From: Ville Syrjälä
Add selftests for drm_rect. A few basic ones for clipped and unclipped
cases, and a few special ones for specific bugs we had in the code.
I'm too lazy to think of more corner cases to check at this time.
Maybe later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 4 +
.../drm/selftests/test-drm_modeset_common.h | 7 +
drivers/gpu/drm/selftests/test-drm_rect.c | 223 ++
include/drm/drm_rect.h| 2 +
5 files changed, 238 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_rect.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index d2137342b371..0856e4b12f70 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
test-drm_format.o test-drm_framebuffer.o \
- test-drm_damage_helper.o test-drm_dp_mst_helper.o
+ test-drm_damage_helper.o test-drm_dp_mst_helper.o \
+ test-drm_rect.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
test-drm_cmdline_parser.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 1898de0b4a4d..782e285ca383 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -6,6 +6,10 @@
*
* Tests are executed in order by igt/drm_selftests_helper
*/
+selftest(drm_rect_clip_scaled_div_by_zero,
igt_drm_rect_clip_scaled_div_by_zero)
+selftest(drm_rect_clip_scaled_not_clipped,
igt_drm_rect_clip_scaled_not_clipped)
+selftest(drm_rect_clip_scaled_clipped, igt_drm_rect_clip_scaled_clipped)
+selftest(drm_rect_clip_scaled_signed_vs_unsigned,
igt_drm_rect_clip_scaled_signed_vs_unsigned)
selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
diff --git a/drivers/gpu/drm/selftests/test-drm_modeset_common.h
b/drivers/gpu/drm/selftests/test-drm_modeset_common.h
index 0fcb8bbc6a1b..cfb51d8da2bc 100644
--- a/drivers/gpu/drm/selftests/test-drm_modeset_common.h
+++ b/drivers/gpu/drm/selftests/test-drm_modeset_common.h
@@ -3,6 +3,9 @@
#ifndef __TEST_DRM_MODESET_COMMON_H__
#define __TEST_DRM_MODESET_COMMON_H__
+#include
+#include
+
#define FAIL(test, msg, ...) \
do { \
if (test) { \
@@ -13,6 +16,10 @@
#define FAIL_ON(x) FAIL((x), "%s", "FAIL_ON(" __stringify(x) ")\n")
+int igt_drm_rect_clip_scaled_div_by_zero(void *ignored);
+int igt_drm_rect_clip_scaled_not_clipped(void *ignored);
+int igt_drm_rect_clip_scaled_clipped(void *ignored);
+int igt_drm_rect_clip_scaled_signed_vs_unsigned(void *ignored);
int igt_check_plane_state(void *ignored);
int igt_check_drm_format_block_width(void *ignored);
int igt_check_drm_format_block_height(void *ignored);
diff --git a/drivers/gpu/drm/selftests/test-drm_rect.c
b/drivers/gpu/drm/selftests/test-drm_rect.c
new file mode 100644
index ..3a5ff38321f4
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_rect.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_rect functions
+ */
+
+#define pr_fmt(fmt) "drm_rect: " fmt
+
+#include
+
+#include
+
+#include "test-drm_modeset_common.h"
+
+int igt_drm_rect_clip_scaled_div_by_zero(void *ignored)
+{
+ struct drm_rect src, dst, clip;
+ bool visible;
+
+ /*
+* Make sure we don't divide by zero when dst
+* width/height is zero and dst and clip do not intersect.
+*/
+ drm_rect_init(, 0, 0, 0, 0);
+ drm_rect_init(, 0, 0, 0, 0);
+ drm_rect_init(, 1, 1, 1, 1);
+ visible = drm_rect_clip_scaled(, , );
+ FAIL(visible, "Destination not be visible\n");
+ FAIL(drm_rect_visible(), "Source should not be visible\n");
+
+ drm_rect_init(, 0, 0, 0, 0);
+ drm_rect_init(, 3, 3, 0, 0);
+ drm_rect_init(, 1, 1, 1, 1);
+ visible = drm_rect_clip_scaled(, , );
+ FAIL(visible, "Destination not be visible\n");
+ FAIL(drm_rect_visible(), "Source should not be visible\n");
+
+ return 0;
+}
+
+int igt_drm_rect_clip_scaled_not_clipped(void *ignored)
+{
+ struct drm_rect src, dst, clip;
+ bool visible;
+
+ /* 1:1 scaling */
+ drm_rect_init(, 0, 0, 1 << 16, 1 << 16);
+ drm_rect_init(, 0, 0, 1, 1);
+ drm_rect_init(, 0, 0, 1, 1);
+
+ visible = drm_rect_clip_scaled(, , );
+
+ FAIL(src.x1 != 0 || src.x2 != 1 << 16 ||
+src.y1 != 0 || src.y2 != 1 << 16,
+"Source badly clipped\n");
+ FAIL(dst.x1 != 0 || dst.x2 !=
[PATCH v2 2/4] drm/rect: Keep the scaled clip bounded
From: Ville Syrjälä Limit the scaled clip to only clip at most dst_w/h pixels. This avoids the problem with clip_scaled() not being able to return negative values. Since new_src_w/h is now properly bounded we can remove the clamp()s. Cc: Benjamin Gaignard Cc: Maarten Lankhorst Cc: Daniel Vetter Testcase: igt/kms_selftest/drm_rect_clip_scaled_signed_vs_unsigned Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_rect.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c index 818738e83d06..a9c7f90836f3 100644 --- a/drivers/gpu/drm/drm_rect.c +++ b/drivers/gpu/drm/drm_rect.c @@ -59,6 +59,9 @@ static u32 clip_scaled(u32 src, u32 dst, u32 clip) if (dst == 0) return 0; + /* Only clip what we have. Keeps the result bounded. */ + clip = min(clip, dst); + tmp = mul_u32_u32(src, dst - clip); /* @@ -94,7 +97,7 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, u32 new_src_w = clip_scaled(drm_rect_width(src), drm_rect_width(dst), diff); - src->x1 = clamp_t(int64_t, src->x2 - new_src_w, INT_MIN, INT_MAX); + src->x1 = src->x2 - new_src_w; dst->x1 = clip->x1; } diff = clip->y1 - dst->y1; @@ -102,7 +105,7 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, u32 new_src_h = clip_scaled(drm_rect_height(src), drm_rect_height(dst), diff); - src->y1 = clamp_t(int64_t, src->y2 - new_src_h, INT_MIN, INT_MAX); + src->y1 = src->y2 - new_src_h; dst->y1 = clip->y1; } diff = dst->x2 - clip->x2; @@ -110,7 +113,7 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, u32 new_src_w = clip_scaled(drm_rect_width(src), drm_rect_width(dst), diff); - src->x2 = clamp_t(int64_t, src->x1 + new_src_w, INT_MIN, INT_MAX); + src->x2 = src->x1 + new_src_w; dst->x2 = clip->x2; } diff = dst->y2 - clip->y2; @@ -118,7 +121,7 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, u32 new_src_h = clip_scaled(drm_rect_height(src), drm_rect_height(dst), diff); - src->y2 = clamp_t(int64_t, src->y1 + new_src_h, INT_MIN, INT_MAX); + src->y2 = src->y1 + new_src_h; dst->y2 = clip->y2; } -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/rect: Keep the clipped dst rectangle in place
From: Ville Syrjälä
Now that we've constrained the clipped source rectangle such
that it can't have negative dimensions doing the same for the
dst rectangle seems appropriate. Should at least result in
the clipped src and dst rectangles being a bit more consistent
with each other.
Cc: Benjamin Gaignard
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index a9c7f90836f3..1e1e2101007a 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -52,7 +52,7 @@ bool drm_rect_intersect(struct drm_rect *r1, const struct
drm_rect *r2)
}
EXPORT_SYMBOL(drm_rect_intersect);
-static u32 clip_scaled(u32 src, u32 dst, u32 clip)
+static u32 clip_scaled(int src, int dst, int *clip)
{
u64 tmp;
@@ -60,9 +60,9 @@ static u32 clip_scaled(u32 src, u32 dst, u32 clip)
return 0;
/* Only clip what we have. Keeps the result bounded. */
- clip = min(clip, dst);
+ *clip = min(*clip, dst);
- tmp = mul_u32_u32(src, dst - clip);
+ tmp = mul_u32_u32(src, dst - *clip);
/*
* Round toward 1.0 when clipping so that we don't accidentally
@@ -95,34 +95,34 @@ bool drm_rect_clip_scaled(struct drm_rect *src, struct
drm_rect *dst,
diff = clip->x1 - dst->x1;
if (diff > 0) {
u32 new_src_w = clip_scaled(drm_rect_width(src),
- drm_rect_width(dst), diff);
+ drm_rect_width(dst), );
src->x1 = src->x2 - new_src_w;
- dst->x1 = clip->x1;
+ dst->x1 += diff;
}
diff = clip->y1 - dst->y1;
if (diff > 0) {
u32 new_src_h = clip_scaled(drm_rect_height(src),
- drm_rect_height(dst), diff);
+ drm_rect_height(dst), );
src->y1 = src->y2 - new_src_h;
- dst->y1 = clip->y1;
+ dst->y1 += diff;
}
diff = dst->x2 - clip->x2;
if (diff > 0) {
u32 new_src_w = clip_scaled(drm_rect_width(src),
- drm_rect_width(dst), diff);
+ drm_rect_width(dst), );
src->x2 = src->x1 + new_src_w;
- dst->x2 = clip->x2;
+ dst->x2 -= diff;
}
diff = dst->y2 - clip->y2;
if (diff > 0) {
u32 new_src_h = clip_scaled(drm_rect_height(src),
- drm_rect_height(dst), diff);
+ drm_rect_height(dst), );
src->y2 = src->y1 + new_src_h;
- dst->y2 = clip->y2;
+ dst->y2 -= diff;
}
return drm_rect_visible(dst);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/rect: Bugfixes and selftests
From: Ville Syrjälä My earlier fixes for drm_rect + div-by-zero fix + some selftests that Daniel requested. Cc: Maarten Lankhorst Cc: Benjamin Gaignard Cc: Daniel Vetter Ville Syrjälä (4): drm/rect: Avoid division by zero drm/rect: Keep the scaled clip bounded drm/rect: Keep the clipped dst rectangle in place drm/selftests: Add drm_rect selftests drivers/gpu/drm/drm_rect.c| 36 +-- drivers/gpu/drm/selftests/Makefile| 3 +- .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + .../drm/selftests/test-drm_modeset_common.h | 7 + drivers/gpu/drm/selftests/test-drm_rect.c | 220 ++ include/drm/drm_rect.h| 2 + 6 files changed, 257 insertions(+), 15 deletions(-) create mode 100644 drivers/gpu/drm/selftests/test-drm_rect.c -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/rect: Avoid division by zero
From: Ville Syrjälä
Check for zero width/height destination rectangle in
drm_rect_clip_scaled() to avoid a division by zero.
Cc: sta...@vger.kernel.org
Fixes: f96bdf564f3e ("drm/rect: Handle rounding errors in drm_rect_clip_scaled,
v3.")
Cc: Maarten Lankhorst
Cc: Benjamin Gaignard
Cc: Daniel Vetter
Testcase: igt/kms_selftest/drm_rect_clip_scaled_div_by_zero
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index b8363aaa9032..818738e83d06 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -54,7 +54,12 @@ EXPORT_SYMBOL(drm_rect_intersect);
static u32 clip_scaled(u32 src, u32 dst, u32 clip)
{
- u64 tmp = mul_u32_u32(src, dst - clip);
+ u64 tmp;
+
+ if (dst == 0)
+ return 0;
+
+ tmp = mul_u32_u32(src, dst - clip);
/*
* Round toward 1.0 when clipping so that we don't accidentally
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.4
The pull request you sent on Fri, 22 Nov 2019 10:43:28 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-11-22 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5d867ab037e58da3356b95bd1a7cb8efe3501958 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/rect: Keep the clipped dst rectangle in place
On Wed, Nov 20, 2019 at 07:11:38PM +0200, Ville Syrjälä wrote: > On Wed, Nov 20, 2019 at 05:43:40PM +0100, Daniel Vetter wrote: > > On Wed, Nov 20, 2019 at 06:25:12PM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Now that we've constrained the clipped source rectangle such > > > that it can't have negative dimensions doing the same for the > > > dst rectangle seems appropriate. Should at least result in > > > the clipped src and dst rectangles being a bit more consistent > > > with each other. > > > > > > Cc: Benjamin Gaignard > > > Cc: Maarten Lankhorst > > > Signed-off-by: Ville Syrjälä > > > > selftests for this stuff? Looks like the prime example, write testcase > > proving code is busted, fix it, everyone celebrate? > > Yeah, seems like a good idea. Though I'll have to figure out if it's > actually broken or not ;) I *think* the only problem is that the clip can result in a visible source rectangle when this happens. The dst rectangle will still be correctly invisible so hopefully not a big deal. But I guess we might as well fix it, and I can do a selftest which makes sure both src and dst come out invisible. > > Hmm. Ouch. There's seems to be a div by zero lurking in there if > dst_w/h == 0. I wonder why nothing has hit that. Definitely real. I'll fix it and toss in a selftest. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/mediatek: don't open-code drm_gem_fb_create
On Fri, Nov 22, 2019 at 03:42:39PM +0800, CK Hu wrote:
> Hi, Daniel:
>
> On Fri, 2019-11-15 at 10:21 +0100, Daniel Vetter wrote:
> > Aside: There's a few other fb_create implementations which
> > simply check for valid buffer format (or an approximation thereof),
> > and then call drm_gem_fb_create. For atomic drivers at least we could
> > walk all planes and make sure the format/modifier combo is valid,
> > and remove even more code.
> >
> > For non-atomic drivers that's not possible, since the format list for
> > the primary buffer might be garbage (and most likely it is).
> >
> > Also delete mtk_drm_fb.[hc] since it would now only contain one
> > function.
>
> Acked-by: CK Hu
Pushed to drm-misc-next, thanks for taking a look.
-Daniel
>
> >
> > Signed-off-by: Daniel Vetter
> > Cc: CK Hu
> > Cc: Philipp Zabel
> > Cc: Matthias Brugger
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-media...@lists.infradead.org
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 16 -
> > drivers/gpu/drm/mediatek/mtk_drm_fb.c| 92
> > drivers/gpu/drm/mediatek/mtk_drm_fb.h| 13
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 -
> > 4 files changed, 15 insertions(+), 107 deletions(-)
> > delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c
> > delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 84d14213d992..2b1c122066ea 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -16,8 +16,10 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -27,7 +29,6 @@
> > #include "mtk_drm_ddp.h"
> > #include "mtk_drm_ddp_comp.h"
> > #include "mtk_drm_drv.h"
> > -#include "mtk_drm_fb.h"
> > #include "mtk_drm_gem.h"
> >
> > #define DRIVER_NAME "mediatek"
> > @@ -115,6 +116,19 @@ static int mtk_atomic_commit(struct drm_device *drm,
> > return 0;
> > }
> >
> > +static struct drm_framebuffer *
> > +mtk_drm_mode_fb_create(struct drm_device *dev,
> > + struct drm_file *file,
> > + const struct drm_mode_fb_cmd2 *cmd)
> > +{
> > + const struct drm_format_info *info = drm_get_format_info(dev, cmd);
> > +
> > + if (info->num_planes != 1)
> > + return ERR_PTR(-EINVAL);
> > +
> > + return drm_gem_fb_create(dev, file, cmd);
> > +}
> > +
> > static const struct drm_mode_config_funcs mtk_drm_mode_config_funcs = {
> > .fb_create = mtk_drm_mode_fb_create,
> > .atomic_check = drm_atomic_helper_check,
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> > deleted file mode 100644
> > index 3f230a28a2dc..
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> > +++ /dev/null
> > @@ -1,92 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0-only
> > -/*
> > - * Copyright (c) 2015 MediaTek Inc.
> > - */
> > -
> > -#include
> > -#include
> > -
> > -#include
> > -#include
> > -#include
> > -#include
> > -#include
> > -
> > -#include "mtk_drm_drv.h"
> > -#include "mtk_drm_fb.h"
> > -#include "mtk_drm_gem.h"
> > -
> > -static const struct drm_framebuffer_funcs mtk_drm_fb_funcs = {
> > - .create_handle = drm_gem_fb_create_handle,
> > - .destroy = drm_gem_fb_destroy,
> > -};
> > -
> > -static struct drm_framebuffer *mtk_drm_framebuffer_init(struct drm_device
> > *dev,
> > - const struct drm_mode_fb_cmd2 *mode,
> > - struct drm_gem_object *obj)
> > -{
> > - const struct drm_format_info *info = drm_get_format_info(dev, mode);
> > - struct drm_framebuffer *fb;
> > - int ret;
> > -
> > - if (info->num_planes != 1)
> > - return ERR_PTR(-EINVAL);
> > -
> > - fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> > - if (!fb)
> > - return ERR_PTR(-ENOMEM);
> > -
> > - drm_helper_mode_fill_fb_struct(dev, fb, mode);
> > -
> > - fb->obj[0] = obj;
> > -
> > - ret = drm_framebuffer_init(dev, fb, _drm_fb_funcs);
> > - if (ret) {
> > - DRM_ERROR("failed to initialize framebuffer\n");
> > - kfree(fb);
> > - return ERR_PTR(ret);
> > - }
> > -
> > - return fb;
> > -}
> > -
> > -struct drm_framebuffer *mtk_drm_mode_fb_create(struct drm_device *dev,
> > - struct drm_file *file,
> > - const struct drm_mode_fb_cmd2
> > *cmd)
> > -{
> > - const struct drm_format_info *info = drm_get_format_info(dev, cmd);
> > - struct drm_framebuffer *fb;
> > - struct drm_gem_object *gem;
> > - unsigned int width = cmd->width;
> > - unsigned int height = cmd->height;
> > - unsigned int size, bpp;
> > - int ret;
> > -
> > - if (info->num_planes != 1)
> > - return ERR_PTR(-EINVAL);
Re: [PATCH v2 1/2] drm: call drm_gem_object_funcs.mmap with fake offset
On Fri, Nov 22, 2019 at 12:37 AM Gerd Hoffmann wrote:
>
> The fake offset is going to stay, so change the calling convention for
> drm_gem_object_funcs.mmap to include the fake offset. Update all users
> accordingly.
>
> Note that this reverts 83b8a6f242ea ("drm/gem: Fix mmap fake offset
> handling for drm_gem_object_funcs.mmap") and on top then adds the fake
> offset to drm_gem_prime_mmap to make sure all paths leading to
> obj->funcs->mmap are consistent.
IOW, v1 of my original fix. :) Though you did it a little differently:
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 0814211b0f3f..a9633bd241bb 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -714,6 +714,9 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
> vm_area_struct *vma)
> int ret;
>
> if (obj->funcs && obj->funcs->mmap) {
> + /* Add the fake offset */
> + vma->vm_pgoff += drm_vma_node_start(>vma_node);
> +
Can't this be moved out of the if and then the same thing later down
removed? Unless there's some requirement that drm_vma_node_allow() be
called before drm_vma_node_start() in that case. Doesn't look like it
to me, but I'm not really sure.
> ret = obj->funcs->mmap(obj, vma);
> if (ret)
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave & Daniel, A quick fixup amendment to the previous PR. gem_exec_reloc/basic-range got broken in CI, so we've issued a patch revert the offending commit for now. Once the results for CI_DINF_163 appear here, and the timeouts seen in last three CI_DINF_ are green, feel free to pull this: https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html?testfilter=gem_exec_reloc It is rather a corner-case, so no impact beyond CI currently known. Regards, Joonas *** drm-intel-next-fixes-2019-11-22: - Reverts a patch to avoid spinning forever when context's timeline is active but has no requests The following changes since commit 0122baaa93cc681faace064ec25d16bb5c9825ab: Merge tag 'gvt-next-fixes-2019-11-12' of https://github.com/intel/gvt-linux into drm-intel-next-fixes (2019-11-20 13:21:38 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-11-22 for you to fetch changes up to 15b9cbb2c5e1cf22c13fe38bf513bab821b47630: Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()" (2019-11-22 17:24:22 +0200) - Reverts a patch to avoid spinning forever when context's timeline is active but has no requests Chris Wilson (1): Revert "drm/i915/gt: Wait for new requests in intel_gt_retire_requests()" drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: vic: Export module device table
From: Thierry Reding
Export the module device table to ensure the VIC compatible strings are
listed in the module's aliases table. This in turn causes the driver to
be automatically loaded on boot if VIC is the only enabled subdevice of
the logical host1x DRM device.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/vic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index 9444ba183990..c4d82b8b3065 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -386,13 +386,14 @@ static const struct vic_config vic_t194_config = {
.supports_sid = true,
};
-static const struct of_device_id vic_match[] = {
+static const struct of_device_id tegra_vic_of_match[] = {
{ .compatible = "nvidia,tegra124-vic", .data = _t124_config },
{ .compatible = "nvidia,tegra210-vic", .data = _t210_config },
{ .compatible = "nvidia,tegra186-vic", .data = _t186_config },
{ .compatible = "nvidia,tegra194-vic", .data = _t194_config },
{ },
};
+MODULE_DEVICE_TABLE(of, tegra_vic_of_match);
static int vic_probe(struct platform_device *pdev)
{
@@ -516,7 +517,7 @@ static const struct dev_pm_ops vic_pm_ops = {
struct platform_driver tegra_vic_driver = {
.driver = {
.name = "tegra-vic",
- .of_match_table = vic_match,
+ .of_match_table = tegra_vic_of_match,
.pm = _pm_ops
},
.probe = vic_probe,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:topic/core-for-CI 20/20] drivers/pci/Kconfig:16:error: recursive dependency detected!
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 33c006e813c3896741927f86bf30c8b647c9b366 commit: 33c006e813c3896741927f86bf30c8b647c9b366 [20/20] Revert "drm/i915: Don't select BROKEN" config: alpha-defconfig compiler: alpha-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 33c006e813c3896741927f86bf30c8b647c9b366 GCC_VERSION=7.4.0 make.cross ARCH=alpha defconfig GCC_VERSION=7.4.0 make.cross ARCH=alpha If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> drivers/pci/Kconfig:16:error: recursive dependency detected! drivers/pci/Kconfig:16: symbol PCI depends on HAVE_PCI drivers/pci/Kconfig:7: symbol HAVE_PCI is selected by FORCE_PCI >> drivers/pci/Kconfig:11: symbol FORCE_PCI is selected by ALPHA_JENSEN >> arch/alpha/Kconfig:204: symbol ALPHA_JENSEN is part of choice >> arch/alpha/Kconfig:83: choice contains symbol ALPHA_JENSEN >> arch/alpha/Kconfig:204: symbol ALPHA_JENSEN is part of choice BROKEN init/Kconfig:76: symbol BROKEN is selected by DRM_I915_DEBUG drivers/gpu/drm/i915/Kconfig.debug:20: symbol DRM_I915_DEBUG depends on DRM_I915 drivers/gpu/drm/i915/Kconfig:2: symbol DRM_I915 depends on DRM drivers/gpu/drm/Kconfig:8: symbol DRM depends on AGP drivers/char/agp/Kconfig:2: symbol AGP depends on PCI For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" vim +16 drivers/pci/Kconfig 5f8fc43217a01c Bogicevic Sasa2016-02-03 5 eb01d42a77785f Christoph Hellwig 2018-11-15 6 # select this to offer the PCI prompt eb01d42a77785f Christoph Hellwig 2018-11-15 7 config HAVE_PCI eb01d42a77785f Christoph Hellwig 2018-11-15 8 bool eb01d42a77785f Christoph Hellwig 2018-11-15 9 eb01d42a77785f Christoph Hellwig 2018-11-15 10 # select this to unconditionally force on PCI support eb01d42a77785f Christoph Hellwig 2018-11-15 @11 config FORCE_PCI eb01d42a77785f Christoph Hellwig 2018-11-15 12 bool eb01d42a77785f Christoph Hellwig 2018-11-15 13 select HAVE_PCI eb01d42a77785f Christoph Hellwig 2018-11-15 14 select PCI eb01d42a77785f Christoph Hellwig 2018-11-15 15 eb01d42a77785f Christoph Hellwig 2018-11-15 @16 menuconfig PCI eb01d42a77785f Christoph Hellwig 2018-11-15 17 bool "PCI support" eb01d42a77785f Christoph Hellwig 2018-11-15 18 depends on HAVE_PCI eb01d42a77785f Christoph Hellwig 2018-11-15 19 help eb01d42a77785f Christoph Hellwig 2018-11-15 20 This option enables support for the PCI local bus, including eb01d42a77785f Christoph Hellwig 2018-11-15 21 support for PCI-X and the foundations for PCI Express support. eb01d42a77785f Christoph Hellwig 2018-11-15 22 Say 'Y' here unless you know what you are doing. eb01d42a77785f Christoph Hellwig 2018-11-15 23 :: The code at line 16 was first introduced by commit :: eb01d42a77785ff96b6e66a2a2e7027fc6d78e4a PCI: consolidate PCI config entry in drivers/pci :: TO: Christoph Hellwig :: CC: Masahiro Yamada --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 12:52 PM Mika Westerberg
wrote:
>
[cut]
[I'm really running out of time for today, unfortunately.]
> > > > The current design is mostly based on the PCI PM Spec 1.2, so it would
> > > > be consequent to follow system-wide suspend in PM-runtime and avoid
> > > > putting PCIe ports holding devices in D0 into any low-power states.
> > > > but that would make the approach in the $subject patch ineffective.
> > > >
> > > > Moreover, the fact that there are separate branches for "Windows 7"
> > > > and "Windows 8+" kind of suggest a change in the expected behavior
> > > > between Windows 7 and Windows 8, from the AML perspective. I would
> > > > guess that Windows 7 followed PCI PM 1.2 and Windows 8 (and later)
> > > > does something else.
> > >
> > > My understanding (which may not be correct) is that up to Windows 7 it
> > > never put the devices into D3cold runtime. Only when the system entered
> > > Sx states it evaluated the _OFF methods.
> >
> > I see.
I think I have misunderstood what you said.
I also think that Windows 7 and before didin't do RTD3, but it did PCI
PM nevertheless and platform firmware could expect it to behave in a
specific way in that respect. That expected behavior seems to have
changed in the next generations of Windows, as reflected by the OS
version and _REV checks in ASL.
> > > Starting from Windows 8 it started doing this runtime so devices can
> > > enter D3cold even when system is in S0.
> >
> > Hmm. So by setting _REV to 5 we effectively change the _OFF into a NOP?
>
> No, there are two paths in the _OFF() and them some common code such as
> removing power etc.
>
> What the _REV 5 did is that it went into path where the AML seemed to
> directly disable the link.
>
> The other path that is taken with Windows 8+ does not disable the link
> but instead it puts it to low power L2 or L3 state (I suppose L3 since
> it removes the power and the GPU probably does not support wake).
OK, so the very existence of the two paths means that the OS behavior
expected by the firmware in the two cases represented by them is
different. Presumably, the expected hardware configuration in which
the AML runs also is different in these two cases.
> The ASL code is below. PGOF() gets called from the power resource
> _OFF():
I'll look at it in detail when I have some more time later.
> Method (PGOF, 1, Serialized)
> {
> PIOF = Arg0
> If ((PIOF == Zero))
> {
> If ((SGGP == Zero))
> {
> Return (Zero)
> }
> }
> ElseIf ((PIOF == One))
> {
> If ((P1GP == Zero))
> {
> Return (Zero)
> }
> }
> ElseIf ((PIOF == 0x02))
> {
> If ((P2GP == Zero))
> {
> Return (Zero)
> }
> }
>
> PEBA = \XBAS /* External reference */
> PDEV = GDEV (PIOF)
> PFUN = GFUN (PIOF)
> Name (SCLK, Package (0x03)
> {
> One,
> 0x80,
> Zero
> })
> If ((CCHK (PIOF, Zero) == Zero))
> {
> Return (Zero)
> }
>
> \_SB.PCI0.PEG0.PEGP.LTRE = \_SB.PCI0.PEG0.LREN
> If ((Arg0 == Zero))
> {
> ELC0 = LCT0 /* \_SB_.PCI0.LCT0 */
> H0VI = S0VI /* \_SB_.PCI0.S0VI */
> H0DI = S0DI /* \_SB_.PCI0.S0DI */
> ECP0 = LCP0 /* \_SB_.PCI0.LCP0 */
> }
> ElseIf ((Arg0 == One))
> {
> ELC1 = LCT1 /* \_SB_.PCI0.LCT1 */
> H1VI = S1VI /* \_SB_.PCI0.S1VI */
> H1DI = S1DI /* \_SB_.PCI0.S1DI */
> ECP1 = LCP1 /* \_SB_.PCI0.LCP1 */
> }
> ElseIf ((Arg0 == 0x02))
> {
> ELC2 = LCT2 /* \_SB_.PCI0.LCT2 */
> H2VI = S2VI /* \_SB_.PCI0.S2VI */
> H2DI = S2DI /* \_SB_.PCI0.S2DI */
> ECP2 = LCP2 /* \_SB_.PCI0.LCP2 */
> }
>
> If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV ==
> 0x05
> {
> If ((PIOF == Zero))
> {
> P0LD = One
> TCNT = Zero
> While ((TCNT < LDLY))
> {
> If ((P0LT == 0x08))
> {
> Break
> }
>
> Sleep (0x10)
> TCNT += 0x10
> }
>
> P0RM = One
> P0AP = 0x03
> }
> ElseIf ((PIOF == One))
> {
> P1LD = One
>
Re: [PULL] drm-intel-next-fixes
Quoting Joonas Lahtinen (2019-11-20 22:40:35) > Hi Dave & Daniel, > > NOTE: CI shard results are delayed, bu I'm sending this > already because I'll travel tomorrow. I'll let you know > if the results look OK or not. Or you can look up > CI_DINF_162 results check at: > > https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html The results were not good. I'll send a new PR. Regards, Joonas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/mcde: Do not needlessly logically and with 3
On Fri, Nov 22, 2019 at 08:25:08AM +0100, Linus Walleij wrote:
> The i index i always 0..3 in these statements so there
> is no need to tag "& 3" to clamp it to 3 here. Make
> the operator precedence explicit even if it's correct
> as it is, the paranthesis creates less cognitive stress
> for humans.
>
> Cc: Stephan Gerhold
> Signed-off-by: Linus Walleij
Reviewed-by: Stephan Gerhold
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index dc07b534f01f..21cee4d9d2fd 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -237,25 +237,25 @@ static ssize_t mcde_dsi_host_transfer(struct
> mipi_dsi_host *host,
> if (txlen > 0) {
> val = 0;
> for (i = 0; i < 4 && i < txlen; i++)
> - val |= tx[i] << (i & 3) * 8;
> + val |= tx[i] << (i * 8);
> }
> writel(val, d->regs + DSI_DIRECT_CMD_WRDAT0);
> if (txlen > 4) {
> val = 0;
> for (i = 0; i < 4 && (i + 4) < txlen; i++)
> - val |= tx[i + 4] << (i & 3) * 8;
> + val |= tx[i + 4] << (i * 8);
> writel(val, d->regs + DSI_DIRECT_CMD_WRDAT1);
> }
> if (txlen > 8) {
> val = 0;
> for (i = 0; i < 4 && (i + 8) < txlen; i++)
> - val |= tx[i + 8] << (i & 3) * 8;
> + val |= tx[i + 8] << (i * 8);
> writel(val, d->regs + DSI_DIRECT_CMD_WRDAT2);
> }
> if (txlen > 12) {
> val = 0;
> for (i = 0; i < 4 && (i + 12) < txlen; i++)
> - val |= tx[i + 12] << (i & 3) * 8;
> + val |= tx[i + 12] << (i * 8);
> writel(val, d->regs + DSI_DIRECT_CMD_WRDAT3);
> }
>
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Next round of associating ddc adapters with connectors
Dear Maintainers, Can you please express your opinion on these patches: [tegra] https://patchwork.freedesktop.org/patch/327099/?series=65831=1 [vc4] https://patchwork.freedesktop.org/patch/327102/?series=65831=1 [zte] https://patchwork.freedesktop.org/patch/327106/?series=65831=1 [zte] https://patchwork.freedesktop.org/patch/327112/?series=65831=1 [i915] https://patchwork.freedesktop.org/patch/327120/?series=65831=1 ? Of the originally posted patches: https://patchwork.freedesktop.org/series/62764/ only the above are still outstanding, the others have been applied to at least drm-misc-next or are already upstream. Regards, Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110605] "*ERROR* Waiting for fences timed out." happens every time when I select "Story" in the main game menu RE2.
https://bugs.freedesktop.org/show_bug.cgi?id=110605 Andre Klapper changed: What|Removed |Added URL|https://theshopolics.com/ | Alias|NAGENDRA| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 12:34 PM Karol Herbst wrote: > > On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote: > > [cut] > > > > the issue is not AML related at all as I am able to reproduce this > issue without having to invoke any of that at all, I just need to poke > into the PCI register directly to cut the power. Since the register is not documented, you don't actually know what exactly happens when it is written to. You basically are saying something like "if I write a specific value to an undocumented register, that makes things fail". And yes, writing things to undocumented registers is likely to cause failure to happen, in general. The point is that the kernel will never write into this register by itself. > The register is not documented, but effectively what the AML code is writing > to as well. So that AML code is problematic. It expects the write to do something useful, but that's not the case. Without the AML, the register would not have been written to at all. > Of course it might also be that the code I was testing it was doing > things in a non conformant way and I just hit a different issue as > well, but in the end I don't think that the AML code is the root cause > of all of that. If AML is not involved at all, things work. You've just said so in another message in this thread, quoting verbatim: "yes. In my previous testing I was poking into the PCI registers of the bridge controller and the GPU directly and that never caused any issues as long as I limited it to putting the devices into D3hot." You cannot claim a hardware bug just because a write to an undocumented register from AML causes things to break. First, that may be a bug in the AML (which is not unheard of). Second, and that is more likely, the expectations of the AML code may not be met at the time it is run. Assuming the latter, the root cause is really that the kernel executes the AML in a hardware configuration in which the expectations of that AML are not met. We are now trying to understand what those expectations may be and so how to cause them to be met. Your observation that the issue can be avoided if the GPU is not put into D3hot by a PMCSR write is a step in that direction and it is a good finding. The information from Mika based on the ASL analysis is helpful too. Let's not jump to premature conclusions too quickly, though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 12:30:20PM +0100, Rafael J. Wysocki wrote: > On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg > wrote: > > > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > > wrote: > > > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > > > wrote: > > > > > > > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > > > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki > > > > > > > > > wrote: > > > > > > > > > > > last week or so I found systems where the GPU was under > > > > > > > > > > > the "PCI > > > > > > > > > > > Express Root Port" (name from lspci) and on those systems > > > > > > > > > > > all of that > > > > > > > > > > > seems to work. So I am wondering if it's indeed just the > > > > > > > > > > > 0x1901 one, > > > > > > > > > > > which also explains Mikas case that Thunderbolt stuff > > > > > > > > > > > works as devices > > > > > > > > > > > never get populated under this particular bridge > > > > > > > > > > > controller, but under > > > > > > > > > > > those "Root Port"s > > > > > > > > > > > > > > > > > > > > It always is a PCIe port, but its location within the SoC > > > > > > > > > > may matter. > > > > > > > > > > > > > > > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are > > > > > > > > > called > > > > > > > > > PEG, PCI Express Graphics, ports), and the PCH side. I think > > > > > > > > > the IP is > > > > > > > > > still the same. > > > > > > > > > > > > > > > > > > > Also some custom AML-based power management is involved and > > > > > > > > > > that may > > > > > > > > > > be making specific assumptions on the configuration of the > > > > > > > > > > SoC and the > > > > > > > > > > GPU at the time of its invocation which unfortunately are > > > > > > > > > > not known to > > > > > > > > > > us. > > > > > > > > > > > > > > > > > > > > However, it looks like the AML invoked to power down the > > > > > > > > > > GPU from > > > > > > > > > > acpi_pci_set_power_state() gets confused if it is not in > > > > > > > > > > PCI D0 at > > > > > > > > > > that point, so it looks like that AML tries to access > > > > > > > > > > device memory on > > > > > > > > > > the GPU (beyond the PCI config space) or similar which is > > > > > > > > > > not > > > > > > > > > > accessible in PCI power states below D0. > > > > > > > > > > > > > > > > > > Or the PCI config space of the GPU when the parent root port > > > > > > > > > is in D3hot > > > > > > > > > (as it is the case here). Also then the GPU config space is > > > > > > > > > not > > > > > > > > > accessible. > > > > > > > > > > > > > > > > Why would the parent port be in D3hot at that point? Wouldn't > > > > > > > > that be > > > > > > > > a suspend ordering violation? > > > > > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > > > > > OK > > > > > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > > > itself is not described in ACPI tables at all. > > > > > > OK > > > > > > > > > > then the root port and then turn > > > > > > > off the power resource (which is attached to the root port) > > > > > > > resulting > > > > > > > the topology entering D3cold. > > > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > > port's _PR3 power resource or something else? > > > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > > > OK, so without the $subject patch we (1) program the downstream > > > component (GPU) into D3hot, then we (2) program the port holding it > > > into D3hot and then we (3) let the AML (_OFF for the power resource > > > listed by _PR3 under the port object) run. > > > > > > Something strange happens at this point (and I guess that _OFF doesn't > > > even reach the point where it removes power from the port which is why > > > we see a lock-up). > > > > It does not necessary lead to lock-up. Here is dmesg from Karol's > > system: > > > > > > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt > > > > what seems to happen is that the GPU never "comes back" from D3cold so > > the driver starts breaking apart as the hardware is gone now. > > I meant a lock-up in hardware to be precise, that causes it to stop to > respond (which causes it to appear to be permanently in D3cold). > > I wonder if the port accepts PCI config space
Re: [PATCH 1/2] drm/mcde: Reuse global DSI command defs
On Fri, Nov 22, 2019 at 08:24:57AM +0100, Linus Walleij wrote: > The MCDE DSI include file redefines some commands that > already exist in the common header. > > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij Reviewed-by: Stephan Gerhold > --- > drivers/gpu/drm/mcde/mcde_dsi.c | 2 +- > drivers/gpu/drm/mcde/mcde_dsi_regs.h | 11 --- > 2 files changed, 1 insertion(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c > index d4a12fe7ff01..dc07b534f01f 100644 > --- a/drivers/gpu/drm/mcde/mcde_dsi.c > +++ b/drivers/gpu/drm/mcde/mcde_dsi.c > @@ -350,7 +350,7 @@ void mcde_dsi_te_request(struct mipi_dsi_device *mdsi) > val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT; > val |= 2 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT; > val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN; > - val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_DCS_SHORT_WRITE_1 << > + val |= MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM << > DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT; > writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS); > > diff --git a/drivers/gpu/drm/mcde/mcde_dsi_regs.h > b/drivers/gpu/drm/mcde/mcde_dsi_regs.h > index b03a336c235f..8089db805c57 100644 > --- a/drivers/gpu/drm/mcde/mcde_dsi_regs.h > +++ b/drivers/gpu/drm/mcde/mcde_dsi_regs.h > @@ -123,17 +123,6 @@ > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT BIT(3) > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT 8 > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_MASK 0x3F00 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_TURN_ON_PERIPHERAL 50 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHUT_DOWN_PERIPHERAL 34 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_GENERIC_SHORT_WRITE_0 3 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_GENERIC_SHORT_WRITE_1 19 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_GENERIC_SHORT_WRITE_2 35 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_GENERIC_LONG_WRITE 41 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_DCS_SHORT_WRITE_0 5 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_DCS_SHORT_WRITE_1 21 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_DCS_LONG_WRITE 57 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_DCS_READ 6 > -#define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SET_MAX_PKT_SIZE 55 > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT 14 > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT 16 > #define DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN BIT(21) > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 12:30 PM Rafael J. Wysocki wrote: > > On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg > wrote: > > > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > > wrote: > > > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > > > wrote: > > > > > > > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > > > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki > > > > > > > > > wrote: > > > > > > > > > > > last week or so I found systems where the GPU was under > > > > > > > > > > > the "PCI > > > > > > > > > > > Express Root Port" (name from lspci) and on those systems > > > > > > > > > > > all of that > > > > > > > > > > > seems to work. So I am wondering if it's indeed just the > > > > > > > > > > > 0x1901 one, > > > > > > > > > > > which also explains Mikas case that Thunderbolt stuff > > > > > > > > > > > works as devices > > > > > > > > > > > never get populated under this particular bridge > > > > > > > > > > > controller, but under > > > > > > > > > > > those "Root Port"s > > > > > > > > > > > > > > > > > > > > It always is a PCIe port, but its location within the SoC > > > > > > > > > > may matter. > > > > > > > > > > > > > > > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are > > > > > > > > > called > > > > > > > > > PEG, PCI Express Graphics, ports), and the PCH side. I think > > > > > > > > > the IP is > > > > > > > > > still the same. > > > > > > > > > > > > > > > > > > > Also some custom AML-based power management is involved and > > > > > > > > > > that may > > > > > > > > > > be making specific assumptions on the configuration of the > > > > > > > > > > SoC and the > > > > > > > > > > GPU at the time of its invocation which unfortunately are > > > > > > > > > > not known to > > > > > > > > > > us. > > > > > > > > > > > > > > > > > > > > However, it looks like the AML invoked to power down the > > > > > > > > > > GPU from > > > > > > > > > > acpi_pci_set_power_state() gets confused if it is not in > > > > > > > > > > PCI D0 at > > > > > > > > > > that point, so it looks like that AML tries to access > > > > > > > > > > device memory on > > > > > > > > > > the GPU (beyond the PCI config space) or similar which is > > > > > > > > > > not > > > > > > > > > > accessible in PCI power states below D0. > > > > > > > > > > > > > > > > > > Or the PCI config space of the GPU when the parent root port > > > > > > > > > is in D3hot > > > > > > > > > (as it is the case here). Also then the GPU config space is > > > > > > > > > not > > > > > > > > > accessible. > > > > > > > > > > > > > > > > Why would the parent port be in D3hot at that point? Wouldn't > > > > > > > > that be > > > > > > > > a suspend ordering violation? > > > > > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > > > > > OK > > > > > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > > > itself is not described in ACPI tables at all. > > > > > > OK > > > > > > > > > > then the root port and then turn > > > > > > > off the power resource (which is attached to the root port) > > > > > > > resulting > > > > > > > the topology entering D3cold. > > > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > > port's _PR3 power resource or something else? > > > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > > > OK, so without the $subject patch we (1) program the downstream > > > component (GPU) into D3hot, then we (2) program the port holding it > > > into D3hot and then we (3) let the AML (_OFF for the power resource > > > listed by _PR3 under the port object) run. > > > > > > Something strange happens at this point (and I guess that _OFF doesn't > > > even reach the point where it removes power from the port which is why > > > we see a lock-up). > > > > It does not necessary lead to lock-up. Here is dmesg from Karol's > > system: > > > > > > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt > > > > what seems to happen is that the GPU never "comes back" from D3cold so > > the driver starts breaking apart as the hardware is gone now. > > I meant a lock-up in hardware to be precise, that causes it to stop to > respond (which causes it to appear to be permanently in D3cold). > > I wonder if the port accepts PCI config space writes then.
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 10:07 AM Rafael J. Wysocki wrote: > > On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote: > > > > so while trying to test with d3cold disabled, I noticed that I run > > into the exact same error. > > Does this mean that you disabled d3cold on the GPU via sysfs (the > "d3cold_allowed" attribute was 0) and the original problem still > occurred in that configuration? > yes. In my previous testing I was poking into the PCI registers of the bridge controller and the GPU directly and that never caused any issues as long as I limited it to putting the devices into D3hot. > > And I verified that the > > \_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be > > turned on. > > I don't really understand this comment, so can you explain it a bit to > me, please? > that's the ACPI method to fetch the "status" of the power resource, it should return 0 when the device was powered off (the GPU) and 1 otherwise. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 11:36 AM Mika Westerberg wrote: > > On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > > wrote: > > > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > > wrote: > > > > > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki > > > > > > > > wrote: > > > > > > > > > > last week or so I found systems where the GPU was under the > > > > > > > > > > "PCI > > > > > > > > > > Express Root Port" (name from lspci) and on those systems > > > > > > > > > > all of that > > > > > > > > > > seems to work. So I am wondering if it's indeed just the > > > > > > > > > > 0x1901 one, > > > > > > > > > > which also explains Mikas case that Thunderbolt stuff works > > > > > > > > > > as devices > > > > > > > > > > never get populated under this particular bridge > > > > > > > > > > controller, but under > > > > > > > > > > those "Root Port"s > > > > > > > > > > > > > > > > > > It always is a PCIe port, but its location within the SoC may > > > > > > > > > matter. > > > > > > > > > > > > > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are > > > > > > > > called > > > > > > > > PEG, PCI Express Graphics, ports), and the PCH side. I think > > > > > > > > the IP is > > > > > > > > still the same. > > > > > > > > > > > > > > > > > Also some custom AML-based power management is involved and > > > > > > > > > that may > > > > > > > > > be making specific assumptions on the configuration of the > > > > > > > > > SoC and the > > > > > > > > > GPU at the time of its invocation which unfortunately are not > > > > > > > > > known to > > > > > > > > > us. > > > > > > > > > > > > > > > > > > However, it looks like the AML invoked to power down the GPU > > > > > > > > > from > > > > > > > > > acpi_pci_set_power_state() gets confused if it is not in PCI > > > > > > > > > D0 at > > > > > > > > > that point, so it looks like that AML tries to access device > > > > > > > > > memory on > > > > > > > > > the GPU (beyond the PCI config space) or similar which is not > > > > > > > > > accessible in PCI power states below D0. > > > > > > > > > > > > > > > > Or the PCI config space of the GPU when the parent root port is > > > > > > > > in D3hot > > > > > > > > (as it is the case here). Also then the GPU config space is not > > > > > > > > accessible. > > > > > > > > > > > > > > Why would the parent port be in D3hot at that point? Wouldn't > > > > > > > that be > > > > > > > a suspend ordering violation? > > > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > > > OK > > > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > > itself is not described in ACPI tables at all. > > > > OK > > > > > > > > then the root port and then turn > > > > > > off the power resource (which is attached to the root port) > > > > > > resulting > > > > > > the topology entering D3cold. > > > > > > > > > > I don't see that happening in the AML though. > > > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > > port's _PR3 power resource or something else? > > > > > > The root port's _OFF method for the power resource returned by its _PR3. > > > > OK, so without the $subject patch we (1) program the downstream > > component (GPU) into D3hot, then we (2) program the port holding it > > into D3hot and then we (3) let the AML (_OFF for the power resource > > listed by _PR3 under the port object) run. > > > > Something strange happens at this point (and I guess that _OFF doesn't > > even reach the point where it removes power from the port which is why > > we see a lock-up). > > It does not necessary lead to lock-up. Here is dmesg from Karol's > system: > > > https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt > > what seems to happen is that the GPU never "comes back" from D3cold so > the driver starts breaking apart as the hardware is gone now. I meant a lock-up in hardware to be precise, that causes it to stop to respond (which causes it to appear to be permanently in D3cold). I wonder if the port accepts PCI config space writes then. > > We know that skipping (1) makes things work and we kind of suspect > > that skipping (3) would make things work either, but what about doing > > (1) and (3) without (2)? > > You mean in this particular case or in general? In this case in particular to start with. Just do an experiment to see what happens if we
Re: [PATCH v7 02/24] mm/gup: factor out duplicate code from four routines
On Thu 21-11-19 18:54:02, John Hubbard wrote: > On 11/21/19 1:54 AM, Jan Kara wrote: > > On Thu 21-11-19 00:29:59, John Hubbard wrote: > > > > > > > > Otherwise this looks fine and might be a worthwhile cleanup to feed > > > > Andrew for 5.5 independent of the gut of the changes. > > > > > > > > Reviewed-by: Christoph Hellwig > > > > > > > > > > Thanks for the reviews! Say, it sounds like your view here is that this > > > series should be targeted at 5.6 (not 5.5), is that what you have in mind? > > > And get the preparatory patches (1-9, and maybe even 10-16) into 5.5? > > > > One more note :) If you are going to push pin_user_pages() interfaces > > (which I'm fine with), it would probably make sense to push also the > > put_user_pages() -> unpin_user_pages() renaming so that that inconsistency > > in naming does not exist in the released upstream kernel. > > > > Honza > > Yes, that's what this patch series does. But I'm not sure if "push" here > means, "push out: defer to 5.6", "push (now) into 5.5", or "advocate for"? I meant to include the patch in the "for 5.5" batch. > I will note that it's not going to be easy to rename in one step, now > that this is being split up. Because various put_user_pages()-based items > are going into 5.5 via different maintainer trees now. Probably I'd need > to introduce unpin_user_page() alongside put_user_page()...thoughts? Yes, I understand that moving that patch from the end of the series would cause fair amount of conflicts. I was hoping that you could generate the patch with sed/Coccinelle and then rebasing what remains for 5.6 on top of that patch should not be that painful so overall it should not be that much work. But I may be wrong so if it proves to be too tedious, let's just postpone the renaming to 5.6. I don't find having both unpin_user_page() and put_user_page() a better alternative to current state. Thanks! Honza -- Jan Kara SUSE Labs, CR ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > wrote: > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > wrote: > > > > > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > > > > > > > last week or so I found systems where the GPU was under the > > > > > > > > > "PCI > > > > > > > > > Express Root Port" (name from lspci) and on those systems all > > > > > > > > > of that > > > > > > > > > seems to work. So I am wondering if it's indeed just the > > > > > > > > > 0x1901 one, > > > > > > > > > which also explains Mikas case that Thunderbolt stuff works > > > > > > > > > as devices > > > > > > > > > never get populated under this particular bridge controller, > > > > > > > > > but under > > > > > > > > > those "Root Port"s > > > > > > > > > > > > > > > > It always is a PCIe port, but its location within the SoC may > > > > > > > > matter. > > > > > > > > > > > > > > Exactly. Intel hardware has PCIe ports on CPU side (these are > > > > > > > called > > > > > > > PEG, PCI Express Graphics, ports), and the PCH side. I think the > > > > > > > IP is > > > > > > > still the same. > > > > > > > > > > > > > > > Also some custom AML-based power management is involved and > > > > > > > > that may > > > > > > > > be making specific assumptions on the configuration of the SoC > > > > > > > > and the > > > > > > > > GPU at the time of its invocation which unfortunately are not > > > > > > > > known to > > > > > > > > us. > > > > > > > > > > > > > > > > However, it looks like the AML invoked to power down the GPU > > > > > > > > from > > > > > > > > acpi_pci_set_power_state() gets confused if it is not in PCI D0 > > > > > > > > at > > > > > > > > that point, so it looks like that AML tries to access device > > > > > > > > memory on > > > > > > > > the GPU (beyond the PCI config space) or similar which is not > > > > > > > > accessible in PCI power states below D0. > > > > > > > > > > > > > > Or the PCI config space of the GPU when the parent root port is > > > > > > > in D3hot > > > > > > > (as it is the case here). Also then the GPU config space is not > > > > > > > accessible. > > > > > > > > > > > > Why would the parent port be in D3hot at that point? Wouldn't that > > > > > > be > > > > > > a suspend ordering violation? > > > > > > > > > > No. We put the GPU into D3hot first, > > > > > > OK > > > > > > Does this involve any AML, like a _PS3 under the GPU object? > > > > I don't see _PS3 (nor _PS0) for that object. If I read it right the GPU > > itself is not described in ACPI tables at all. > > OK > > > > > > then the root port and then turn > > > > > off the power resource (which is attached to the root port) resulting > > > > > the topology entering D3cold. > > > > > > > > I don't see that happening in the AML though. > > > > > > Which AML do you mean, specifically? The _OFF method for the root > > > port's _PR3 power resource or something else? > > > > The root port's _OFF method for the power resource returned by its _PR3. > > OK, so without the $subject patch we (1) program the downstream > component (GPU) into D3hot, then we (2) program the port holding it > into D3hot and then we (3) let the AML (_OFF for the power resource > listed by _PR3 under the port object) run. > > Something strange happens at this point (and I guess that _OFF doesn't > even reach the point where it removes power from the port which is why > we see a lock-up). It does not necessary lead to lock-up. Here is dmesg from Karol's system: https://gist.githubusercontent.com/karolherbst/40eb091c7b7b33ef993525de660f1a3b/raw/2380e31f566e93e5ba7c87ef545420965d4c492c/gistfile1.txt what seems to happen is that the GPU never "comes back" from D3cold so the driver starts breaking apart as the hardware is gone now. > We know that skipping (1) makes things work and we kind of suspect > that skipping (3) would make things work either, but what about doing > (1) and (3) without (2)? You mean in this particular case or in general? Because if the port has _PSx methods we need to put it into D3hot AFAIK. > > > > Basically the difference is that when Windows 7 or Linux (the _REV==5 > > > > check) then we directly do link disable whereas in Windows 8+ we invoke > > > > LKDS() method that puts the link into L2/L3. None of the fields they > > > > access seem to touch the GPU itself. > > > > > > So that may be where the problem is. > > > > > > Putting the downstream component into PCI D[1-3] is expected to put > > > the link into L1, so I'm not sure how that plays with the later > > > attempt to put it
[PATCH 5/6] drm/gma500: Store framebuffer in struct drm_fb_helper
The gma500 driver stores the console framebuffer in struct psb_fbdev.
Moving it into struct drm_fb_helper will allow for removal of struct
psb_fbdev.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 5 +++--
drivers/gpu/drm/gma500/framebuffer.c | 16 ++--
drivers/gpu/drm/gma500/framebuffer.h | 1 -
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
index 3d1ad2f85628..2a60add10dbd 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -227,8 +227,8 @@ static void psbfb_copyarea_accel(struct fb_info *info,
const struct fb_copyarea *a)
{
struct psb_fbdev *fbdev = info->par;
- struct drm_device *dev = fbdev->fb.dev;
struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_device *dev = fb->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
uint32_t offset;
uint32_t stride;
@@ -309,7 +309,8 @@ void psbfb_copyarea(struct fb_info *info,
int psbfb_sync(struct fb_info *info)
{
struct psb_fbdev *fbdev = info->par;
- struct drm_device *dev = fbdev->fb.dev;
+ struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_device *dev = fb->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long _end = jiffies + HZ;
int busy = 0;
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 766182da97f6..0c44ba8c3a79 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -78,7 +78,7 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = >fb;
+ struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
struct drm_device *dev = fb->dev;
struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
@@ -146,7 +146,7 @@ static const struct vm_operations_struct psbfb_vm_ops = {
static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = >fb;
+ struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
if (vma->vm_pgoff != 0)
return -EINVAL;
@@ -304,7 +304,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
struct drm_device *dev = fbdev->psb_fb_helper.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
struct fb_info *info;
- struct drm_framebuffer *fb = >fb;
+ struct drm_framebuffer *fb;
struct drm_mode_fb_cmd2 mode_cmd;
int size;
int ret;
@@ -377,9 +377,11 @@ static int psbfb_create(struct psb_fbdev *fbdev,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
- ret = psb_framebuffer_init(dev, fb, _cmd, >gem);
- if (ret)
+ fb = psb_framebuffer_create(dev, _cmd, >gem);
+ if (IS_ERR(fb)) {
+ ret = PTR_ERR(fb);
goto out;
+ }
fbdev->psb_fb_helper.fb = fb;
@@ -477,7 +479,7 @@ static const struct drm_fb_helper_funcs psb_fb_helper_funcs
= {
static int psb_fbdev_destroy(struct drm_device *dev, struct psb_fbdev *fbdev)
{
- struct drm_framebuffer *fb = >fb;
+ struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
drm_fb_helper_unregister_fbi(>psb_fb_helper);
@@ -487,6 +489,8 @@ static int psb_fbdev_destroy(struct drm_device *dev, struct
psb_fbdev *fbdev)
if (fb->obj[0])
drm_gem_object_put_unlocked(fb->obj[0]);
+ kfree(fb);
+
return 0;
}
diff --git a/drivers/gpu/drm/gma500/framebuffer.h
b/drivers/gpu/drm/gma500/framebuffer.h
index ae12801829b2..c75f48c44921 100644
--- a/drivers/gpu/drm/gma500/framebuffer.h
+++ b/drivers/gpu/drm/gma500/framebuffer.h
@@ -15,7 +15,6 @@
struct psb_fbdev {
struct drm_fb_helper psb_fb_helper; /* must be first */
- struct drm_framebuffer fb;
};
extern int gma_connector_clones(struct drm_device *dev, int type_mask);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/gma500: Pass struct drm_gem_object to framebuffer functions
Several framebuffer functions take a pointer to an object of type
struct gtt_range when they actually need the GEM base object. Passing
the GEM object removes some type casting and clutter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index b0f4b6194bda..766182da97f6 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -209,7 +209,7 @@ static struct fb_ops psbfb_unaccel_ops = {
static int psb_framebuffer_init(struct drm_device *dev,
struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd,
- struct gtt_range *gt)
+ struct drm_gem_object *obj)
{
const struct drm_format_info *info;
int ret;
@@ -226,7 +226,7 @@ static int psb_framebuffer_init(struct drm_device *dev,
return -EINVAL;
drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
- fb->obj[0] = >gem;
+ fb->obj[0] = obj;
ret = drm_framebuffer_init(dev, fb, _fb_funcs);
if (ret) {
dev_err(dev->dev, "framebuffer init failed: %d\n", ret);
@@ -250,7 +250,7 @@ static int psb_framebuffer_init(struct drm_device *dev,
static struct drm_framebuffer *psb_framebuffer_create
(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
-struct gtt_range *gt)
+struct drm_gem_object *obj)
{
struct drm_framebuffer *fb;
int ret;
@@ -259,7 +259,7 @@ static struct drm_framebuffer *psb_framebuffer_create
if (!fb)
return ERR_PTR(-ENOMEM);
- ret = psb_framebuffer_init(dev, fb, mode_cmd, gt);
+ ret = psb_framebuffer_init(dev, fb, mode_cmd, obj);
if (ret) {
kfree(fb);
return ERR_PTR(ret);
@@ -377,7 +377,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);
- ret = psb_framebuffer_init(dev, fb, _cmd, backing);
+ ret = psb_framebuffer_init(dev, fb, _cmd, >gem);
if (ret)
goto out;
@@ -432,7 +432,6 @@ static struct drm_framebuffer *psb_user_framebuffer_create
(struct drm_device *dev, struct drm_file *filp,
const struct drm_mode_fb_cmd2 *cmd)
{
- struct gtt_range *r;
struct drm_gem_object *obj;
/*
@@ -444,8 +443,7 @@ static struct drm_framebuffer *psb_user_framebuffer_create
return ERR_PTR(-ENOENT);
/* Let the core code do all the work */
- r = container_of(obj, struct gtt_range, gem);
- return psb_framebuffer_create(dev, cmd, r);
+ return psb_framebuffer_create(dev, cmd, obj);
}
static int psbfb_probe(struct drm_fb_helper *helper,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/gma500: Replace struct psb_framebuffer with struct drm_framebuffer
After removing all unnecessary fields, struct psb_framebuffer is just a
wrapper around struct drm_framebuffer. So we can replace the former with
the latter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 6 ++--
drivers/gpu/drm/gma500/framebuffer.c | 48 +---
drivers/gpu/drm/gma500/framebuffer.h | 8 +
3 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
index 45ad5ffedc93..3d1ad2f85628 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -227,8 +227,7 @@ static void psbfb_copyarea_accel(struct fb_info *info,
const struct fb_copyarea *a)
{
struct psb_fbdev *fbdev = info->par;
- struct psb_framebuffer *psbfb = >pfb;
- struct drm_device *dev = psbfb->base.dev;
+ struct drm_device *dev = fbdev->fb.dev;
struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
struct drm_psb_private *dev_priv = dev->dev_private;
uint32_t offset;
@@ -310,8 +309,7 @@ void psbfb_copyarea(struct fb_info *info,
int psbfb_sync(struct fb_info *info)
{
struct psb_fbdev *fbdev = info->par;
- struct psb_framebuffer *psbfb = >pfb;
- struct drm_device *dev = psbfb->base.dev;
+ struct drm_device *dev = fbdev->fb.dev;
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long _end = jiffies + HZ;
int busy = 0;
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index f56a1fcf58ab..b0f4b6194bda 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -78,9 +78,9 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct psb_fbdev *fbdev = info->par;
- struct psb_framebuffer *psbfb = >pfb;
- struct drm_device *dev = psbfb->base.dev;
- struct gtt_range *gtt = to_gtt_range(psbfb->base.obj[0]);
+ struct drm_framebuffer *fb = >fb;
+ struct drm_device *dev = fb->dev;
+ struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
/*
* We have to poke our nose in here. The core fb code assumes
@@ -99,10 +99,10 @@ static int psbfb_pan(struct fb_var_screeninfo *var, struct
fb_info *info)
static vm_fault_t psbfb_vm_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
- struct psb_framebuffer *psbfb = vma->vm_private_data;
- struct drm_device *dev = psbfb->base.dev;
+ struct drm_framebuffer *fb = vma->vm_private_data;
+ struct drm_device *dev = fb->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
- struct gtt_range *gtt = to_gtt_range(psbfb->base.obj[0]);
+ struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
int page_num;
int i;
unsigned long address;
@@ -146,7 +146,7 @@ static const struct vm_operations_struct psbfb_vm_ops = {
static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
struct psb_fbdev *fbdev = info->par;
- struct psb_framebuffer *psbfb = >pfb;
+ struct drm_framebuffer *fb = >fb;
if (vma->vm_pgoff != 0)
return -EINVAL;
@@ -159,7 +159,7 @@ static int psbfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
* suitable for our mmap work
*/
vma->vm_ops = _vm_ops;
- vma->vm_private_data = (void *)psbfb;
+ vma->vm_private_data = (void *)fb;
vma->vm_flags |= VM_IO | VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
}
@@ -207,7 +207,7 @@ static struct fb_ops psbfb_unaccel_ops = {
* 0 on success or an error code if we fail.
*/
static int psb_framebuffer_init(struct drm_device *dev,
- struct psb_framebuffer *fb,
+ struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct gtt_range *gt)
{
@@ -225,9 +225,9 @@ static int psb_framebuffer_init(struct drm_device *dev,
if (mode_cmd->pitches[0] & 63)
return -EINVAL;
- drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
- fb->base.obj[0] = >gem;
- ret = drm_framebuffer_init(dev, >base, _fb_funcs);
+ drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
+ fb->obj[0] = >gem;
+ ret = drm_framebuffer_init(dev, fb, _fb_funcs);
if (ret) {
dev_err(dev->dev, "framebuffer init failed: %d\n", ret);
return ret;
@@ -252,7 +252,7 @@ static struct drm_framebuffer *psb_framebuffer_create
const struct drm_mode_fb_cmd2 *mode_cmd,
struct gtt_range *gt)
{
- struct psb_framebuffer *fb;
+ struct drm_framebuffer
[PATCH 6/6] drm/gma500: Remove struct psb_fbdev
Gma500's struct psb_fbdev is an, otherwise empty, wrapper around
struct drm_fb_helper. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/accel_2d.c| 10 ++--
drivers/gpu/drm/gma500/framebuffer.c | 70 ++--
drivers/gpu/drm/gma500/framebuffer.h | 6 ---
drivers/gpu/drm/gma500/psb_drv.c | 1 +
drivers/gpu/drm/gma500/psb_drv.h | 8 ++--
5 files changed, 45 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/gma500/accel_2d.c
b/drivers/gpu/drm/gma500/accel_2d.c
index 2a60add10dbd..b9e5a38632f7 100644
--- a/drivers/gpu/drm/gma500/accel_2d.c
+++ b/drivers/gpu/drm/gma500/accel_2d.c
@@ -21,9 +21,9 @@
#include
#include
+#include
#include
-#include "framebuffer.h"
#include "psb_drv.h"
#include "psb_reg.h"
@@ -226,8 +226,8 @@ static int psb_accel_2d_copy(struct drm_psb_private
*dev_priv,
static void psbfb_copyarea_accel(struct fb_info *info,
const struct fb_copyarea *a)
{
- struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_framebuffer *fb = fb_helper->fb;
struct drm_device *dev = fb->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
uint32_t offset;
@@ -308,8 +308,8 @@ void psbfb_copyarea(struct fb_info *info,
*/
int psbfb_sync(struct fb_info *info)
{
- struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_framebuffer *fb = fb_helper->fb;
struct drm_device *dev = fb->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
unsigned long _end = jiffies + HZ;
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 0c44ba8c3a79..6745e3f6a2f0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -40,8 +40,8 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
unsigned blue, unsigned transp,
struct fb_info *info)
{
- struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_framebuffer *fb = fb_helper->fb;
uint32_t v;
if (!fb)
@@ -77,8 +77,8 @@ static int psbfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
static int psbfb_pan(struct fb_var_screeninfo *var, struct fb_info *info)
{
- struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_framebuffer *fb = fb_helper->fb;
struct drm_device *dev = fb->dev;
struct gtt_range *gtt = to_gtt_range(fb->obj[0]);
@@ -145,8 +145,8 @@ static const struct vm_operations_struct psbfb_vm_ops = {
static int psbfb_mmap(struct fb_info *info, struct vm_area_struct *vma)
{
- struct psb_fbdev *fbdev = info->par;
- struct drm_framebuffer *fb = fbdev->psb_fb_helper.fb;
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_framebuffer *fb = fb_helper->fb;
if (vma->vm_pgoff != 0)
return -EINVAL;
@@ -298,10 +298,10 @@ static struct gtt_range *psbfb_alloc(struct drm_device
*dev, int aligned_size)
*
* Create a framebuffer to the specifications provided
*/
-static int psbfb_create(struct psb_fbdev *fbdev,
+static int psbfb_create(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_surface_size *sizes)
{
- struct drm_device *dev = fbdev->psb_fb_helper.dev;
+ struct drm_device *dev = fb_helper->dev;
struct drm_psb_private *dev_priv = dev->dev_private;
struct fb_info *info;
struct drm_framebuffer *fb;
@@ -369,7 +369,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
memset(dev_priv->vram_addr + backing->offset, 0, size);
- info = drm_fb_helper_alloc_fbi(>psb_fb_helper);
+ info = drm_fb_helper_alloc_fbi(fb_helper);
if (IS_ERR(info)) {
ret = PTR_ERR(info);
goto out;
@@ -383,7 +383,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
goto out;
}
- fbdev->psb_fb_helper.fb = fb;
+ fb_helper->fb = fb;
if (dev_priv->ops->accel_2d && pitch_lines > 8) /* 2D engine */
info->fbops = _ops;
@@ -407,7 +407,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
info->apertures->ranges[0].size = dev_priv->gtt.stolen_size;
}
- drm_fb_helper_fill_info(info, >psb_fb_helper, sizes);
+ drm_fb_helper_fill_info(info, fb_helper, sizes);
info->fix.mmio_start = pci_resource_start(dev->pdev, 0);
info->fix.mmio_len =
[PATCH 1/6] drm/gma500: Remove addr_space field from psb_framebuffer
The field 'addr_space' in struct psb_framebuffer serves no
purpose. Remove it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 2 --
drivers/gpu/drm/gma500/framebuffer.h | 1 -
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 218f3bb15276..598dc51d9e24 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -153,8 +153,6 @@ static int psbfb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
return -EINVAL;
- if (!psbfb->addr_space)
- psbfb->addr_space = vma->vm_file->f_mapping;
/*
* If this is a GEM object then info->screen_base is the virtual
* kernel remapping of the object. FIXME: Review if this is
diff --git a/drivers/gpu/drm/gma500/framebuffer.h
b/drivers/gpu/drm/gma500/framebuffer.h
index ae8a02639fd9..a2d68dd74c12 100644
--- a/drivers/gpu/drm/gma500/framebuffer.h
+++ b/drivers/gpu/drm/gma500/framebuffer.h
@@ -15,7 +15,6 @@
struct psb_framebuffer {
struct drm_framebuffer base;
- struct address_space *addr_space;
struct fb_info *fbdev;
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/gma500: Remove field 'fbdev' from struct psb_framebuffer
The field 'fbdev' in struct psb_framebuffer serves no purpose. Remove
it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/framebuffer.c | 1 -
drivers/gpu/drm/gma500/framebuffer.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 598dc51d9e24..f56a1fcf58ab 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -383,7 +383,6 @@ static int psbfb_create(struct psb_fbdev *fbdev,
goto out;
fb = >base;
- psbfb->fbdev = info;
fbdev->psb_fb_helper.fb = fb;
diff --git a/drivers/gpu/drm/gma500/framebuffer.h
b/drivers/gpu/drm/gma500/framebuffer.h
index a2d68dd74c12..95d4485dc860 100644
--- a/drivers/gpu/drm/gma500/framebuffer.h
+++ b/drivers/gpu/drm/gma500/framebuffer.h
@@ -15,7 +15,6 @@
struct psb_framebuffer {
struct drm_framebuffer base;
- struct fb_info *fbdev;
};
struct psb_fbdev {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/gma500: Cleanup framebuffer and fbdev
These patches remove struct psb_framebuffer and struct psb_fbdev from gma500. Both are replaced by their equivalents from the DRM helpers. The patchset has been tested by running the fbdev console, X11 and Weston on an Atom Z520 with Poulsbo graphics chip. Thomas Zimmermann (6): drm/gma500: Remove addr_space field from psb_framebuffer drm/gma500: Remove field 'fbdev' from struct psb_framebuffer drm/gma500: Replace struct psb_framebuffer with struct drm_framebuffer drm/gma500: Pass struct drm_gem_object to framebuffer functions drm/gma500: Store framebuffer in struct drm_fb_helper drm/gma500: Remove struct psb_fbdev drivers/gpu/drm/gma500/accel_2d.c| 15 ++-- drivers/gpu/drm/gma500/framebuffer.c | 129 +-- drivers/gpu/drm/gma500/framebuffer.h | 15 drivers/gpu/drm/gma500/psb_drv.c | 1 + drivers/gpu/drm/gma500/psb_drv.h | 8 +- 5 files changed, 74 insertions(+), 94 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 1:22 AM Karol Herbst wrote: > > Fixes state transitions of Nvidia Pascal GPUs from D3cold into higher device > states. > > 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 > > 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 > --- > drivers/pci/pci.c| 7 ++ > drivers/pci/quirks.c | 51 > include/linux/pci.h | 1 + > 3 files changed, 59 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 57f15a7e6f0b..e08db2daa924 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -850,6 +850,13 @@ static int pci_raw_set_power_state(struct pci_dev *dev, > pci_power_t state) >|| (state == PCI_D2 && !dev->d2_support)) > return -EIO; > > + /* > +* Check if we have a bad combination of bridge controller and nvidia > +* GPU, see quirk_broken_nv_runpm for more info > +*/ > + if (state != PCI_D0 && dev->broken_nv_runpm) > + return 0; The result of this change in the suspend-to-idle path will be leaving the device and its PCIe port in D0 while suspended, unless the device itself has power management methods in the ACPI tables (according to Mika that is not the case). I don't think that this is desirable. > + > pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, ); > > /* > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 44c4ae1abd00..24e3f247d291 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -5268,3 +5268,54 @@ static void > quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev) > DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1, > PCI_CLASS_DISPLAY_VGA, 8, > quirk_reset_lenovo_thinkpad_p50_nvgpu); > + > +/* > + * Some Intel PCIe bridge controllers cause devices to not reappear doing a > + * D0 -> D3hot -> D3cold -> D0 sequence. This is inaccurate and not entirely fair AFAICS. First off, what is a "PCIe bridge controller"? A PCIe root complex? Second, I don't think that you really can blame hardware here, because the problem is related to AML (forcing a different code path in AML makes it go away, so the same hardware with different AML would work). More precisely, the behavior of the kernel is not what is expected by AML associated with the PCIe port holding the device. > Skipping the intermediate D3hot step > + * seems to make it work again. Yes, but the change would need to cover both the PM-runtime and suspend-to-idle code paths. Also it may be driver-induced rather than quirk-based. > + * > + * This leads to various manifestations of this issue: > + * - AIML code execution hits an infinite loop (as the coe waits on device Typo: coe -> code > + *memory to change). Which AML code is this, the power-off part or power-on part? Is this AML code associated with the GPU or with the PCIe port holding it (I guess the latter from what Mika said)? Also IIRC ACPICA has a mechanism to break infinite loops in AML by aborting the looping method after a timeout. > + * - kernel crashes, as all PCI reads return -1, which most code isn't able > + *to handle well enough. > + * - sudden shutdowns, as the kernel identified an unrecoverable error after > + *userspace tries to access the GPU. IMO it would be enough to say that the GPU is not accessible after an attempt to remove power from it. > + * > + * 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. > + * > + * ACPI code Which ACPI code? > writes bit 0x80 to the not documented PCI register 0x248 of the 0x248 relative to what? A PCI bar (if so then which one) or the PCI config space (and which part of it if so)? > + * Intel PCIe bridge controller (0x1901) in order to power down the GPU. This doesn't seem accurate. It rather writes to this register to change the state of the PCIe link between the GPU and the PCIe port holding it, which is not the same as powering off. > + * Nonetheless, there are other code paths inside the ACPI firmware which use > + * other registers, which seem to work fine: The meaning of the above is unclear. Does "other" mean "alternative"? > + * - 0xbc bit 0x20
[drm-intel:topic/core-for-CI 20/20] init/Kconfig:76: symbol BROKEN is selected by DRM_I915_DEBUG
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI head: 33c006e813c3896741927f86bf30c8b647c9b366 commit: 33c006e813c3896741927f86bf30c8b647c9b366 [20/20] Revert "drm/i915: Don't select BROKEN" config: powerpc-taishan_defconfig compiler: powerpc-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 33c006e813c3896741927f86bf30c8b647c9b366 GCC_VERSION=7.4.0 make.cross ARCH=powerpc 44x/taishan_defconfig GCC_VERSION=7.4.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> arch/powerpc/platforms/embedded6xx/Kconfig:2:error: recursive dependency >> detected! >> arch/powerpc/platforms/embedded6xx/Kconfig:2: symbol EMBEDDED6xx depends on >> BROKEN_ON_SMP >> init/Kconfig:79: symbol BROKEN_ON_SMP depends on BROKEN >> init/Kconfig:76: symbol BROKEN is selected by DRM_I915_DEBUG >> drivers/gpu/drm/i915/Kconfig.debug:20: symbol DRM_I915_DEBUG depends on >> DRM_I915 >> drivers/gpu/drm/i915/Kconfig:2: symbol DRM_I915 depends on DRM >> drivers/gpu/drm/Kconfig:8: symbol DRM depends on AGP >> drivers/char/agp/Kconfig:2: symbol AGP depends on PCI >> drivers/pci/Kconfig:16: symbol PCI depends on HAVE_PCI >> drivers/pci/Kconfig:7: symbol HAVE_PCI is selected by FORCE_PCI >> drivers/pci/Kconfig:11: symbol FORCE_PCI is selected by MVME5100 >> arch/powerpc/platforms/embedded6xx/Kconfig:51: symbol MVME5100 depends on >> EMBEDDED6xx For a resolution refer to Documentation/kbuild/kconfig-language.rst subsection "Kconfig recursive dependency limitations" vim +76 init/Kconfig ^1da177e4c3f41 Linus Torvalds 2005-04-16 75 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @76 config BROKEN ^1da177e4c3f41 Linus Torvalds 2005-04-16 77bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 78 ^1da177e4c3f41 Linus Torvalds 2005-04-16 @79 config BROKEN_ON_SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 80bool ^1da177e4c3f41 Linus Torvalds 2005-04-16 81depends on BROKEN || !SMP ^1da177e4c3f41 Linus Torvalds 2005-04-16 82default y ^1da177e4c3f41 Linus Torvalds 2005-04-16 83 :: The code at line 76 was first introduced by commit :: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :: TO: Linus Torvalds :: CC: Linus Torvalds --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo
https://bugs.freedesktop.org/show_bug.cgi?id=97055 --- Comment #27 from jennyaly --- I'm not going to try and have a go at suspending until I can at any rate dependably boot. Suspending consistently brings its very own arrangement of issues, and has never worked 100% dependably for me. Also, Visit us here https://www.adwebstudio.com/seo-dubai best SEO company in Dubai providing with best techniques results! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: share address space for dma bufs
On Fri, Nov 22, 2019 at 7:37 AM Gerd Hoffmann wrote:
>
> Use the shared address space of the drm device (see drm_open() in
> drm_file.c) for dma-bufs too. That removes a difference betweem drm
> device mmap vmas and dma-buf mmap vmas and fixes corner cases like
> dropping ptes (using madvise(DONTNEED) for example) not working
> properly.
>
> Also remove amdgpu driver's private dmabuf update. It is not needed
> any more now that we are doing this for everybody.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
But I think you want at least an ack from amd guys for double checking here.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +---
> drivers/gpu/drm/drm_prime.c | 4 +++-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index d5bcdfefbad6..586db4fb46bd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -361,10 +361,8 @@ struct dma_buf *amdgpu_gem_prime_export(struct
> drm_gem_object *gobj,
> return ERR_PTR(-EPERM);
>
> buf = drm_gem_prime_export(gobj, flags);
> - if (!IS_ERR(buf)) {
> - buf->file->f_mapping = gobj->dev->anon_inode->i_mapping;
> + if (!IS_ERR(buf))
> buf->ops = _dmabuf_ops;
> - }
>
> return buf;
> }
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index a9633bd241bb..c3fc341453c0 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -240,6 +240,7 @@ void drm_prime_destroy_file_private(struct
> drm_prime_file_private *prime_fpriv)
> struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
> struct dma_buf_export_info *exp_info)
> {
> + struct drm_gem_object *obj = exp_info->priv;
> struct dma_buf *dma_buf;
>
> dma_buf = dma_buf_export(exp_info);
> @@ -247,7 +248,8 @@ struct dma_buf *drm_gem_dmabuf_export(struct drm_device
> *dev,
> return dma_buf;
>
> drm_dev_get(dev);
> - drm_gem_object_get(exp_info->priv);
> + drm_gem_object_get(obj);
> + dma_buf->file->f_mapping = obj->dev->anon_inode->i_mapping;
>
> return dma_buf;
> }
> --
> 2.18.1
>
--
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
Re: [PATCH 7/8] drm/hibmc: Use drm_gem_fb_create
On Fri, Nov 22, 2019 at 9:16 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 15.11.19 um 10:21 schrieb Daniel Vetter:
> > Again we could delete a lot more if we'd switch over to the generic
> > fbdev stuff.
> >
> > Signed-off-by: Daniel Vetter
>
> There's one comment below. Except for that,
>
> Acked-by: Thomas Zimmermann
>
> > ---
> > .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 4 +-
> > .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 11 +---
> > .../gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 5 +-
> > drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 62 +--
> > 4 files changed, 19 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > index 6527a97f68a3..2d0920ec4554 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > @@ -99,14 +99,12 @@ static void hibmc_plane_atomic_update(struct drm_plane
> > *plane,
> > s64 gpu_addr = 0;
> > unsigned int line_l;
> > struct hibmc_drm_private *priv = plane->dev->dev_private;
> > - struct hibmc_framebuffer *hibmc_fb;
> > struct drm_gem_vram_object *gbo;
> >
> > if (!state->fb)
> > return;
> >
> > - hibmc_fb = to_hibmc_framebuffer(state->fb);
> > - gbo = drm_gem_vram_of_gem(hibmc_fb->obj);
> > + gbo = drm_gem_vram_of_gem(fb->obj[0]);
>
> There's no fb in this function. You have to use state->fb,
Uh, hibmc is the one driver that doesn't compile on arm32 :-/ I'll
drop my patch here and take a look at your series and try to review
it. Then imo wait 2 weeks or so for somet testing from maintainers,
and push either way. If it works great, if it breaks you have your
tester then :-)
-Daniel
>
> >
> > gpu_addr = drm_gem_vram_offset(gbo);
> > if (WARN_ON_ONCE(gpu_addr < 0))
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > index e58ecd7edcf8..ab5b4a4a2095 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> > @@ -20,14 +20,9 @@
> > struct drm_device;
> > struct drm_gem_object;
> >
> > -struct hibmc_framebuffer {
> > - struct drm_framebuffer fb;
> > - struct drm_gem_object *obj;
> > -};
> > -
> > struct hibmc_fbdev {
> > struct drm_fb_helper helper; /* must be first */
> > - struct hibmc_framebuffer *fb;
> > + struct drm_framebuffer *fb;
> > int size;
> > };
> >
> > @@ -47,8 +42,6 @@ struct hibmc_drm_private {
> > struct hibmc_fbdev *fbdev;
> > };
> >
> > -#define to_hibmc_framebuffer(x) container_of(x, struct hibmc_framebuffer,
> > fb)
> > -
> > void hibmc_set_power_mode(struct hibmc_drm_private *priv,
> > unsigned int power_mode);
> > void hibmc_set_current_gate(struct hibmc_drm_private *priv,
> > @@ -61,7 +54,7 @@ void hibmc_fbdev_fini(struct hibmc_drm_private *priv);
> >
> > int hibmc_gem_create(struct drm_device *dev, u32 size, bool iskernel,
> >struct drm_gem_object **obj);
> > -struct hibmc_framebuffer *
> > +struct drm_framebuffer *
> > hibmc_framebuffer_init(struct drm_device *dev,
> > const struct drm_mode_fb_cmd2 *mode_cmd,
> > struct drm_gem_object *obj);
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> > index b4c1cea051e8..446aeedc9e29 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
> > @@ -141,15 +141,14 @@ static int hibmc_drm_fb_create(struct drm_fb_helper
> > *helper,
> >
> > static void hibmc_fbdev_destroy(struct hibmc_fbdev *fbdev)
> > {
> > - struct hibmc_framebuffer *gfb = fbdev->fb;
> > struct drm_fb_helper *fbh = >helper;
> >
> > drm_fb_helper_unregister_fbi(fbh);
> >
> > drm_fb_helper_fini(fbh);
> >
> > - if (gfb)
> > - drm_framebuffer_put(>fb);
> > + if (fbdev->fb)
> > + drm_framebuffer_put(fbdev->fb);
> > }
> >
> > static const struct drm_fb_helper_funcs hibmc_fbdev_helper_funcs = {
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> > index 21b684eab5c9..386033b0d3a2 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "hibmc_drm_drv.h"
> > @@ -97,74 +98,39 @@ int hibmc_dumb_create(struct drm_file *file, struct
> > drm_device *dev,
> > return 0;
> > }
> >
> > -static void hibmc_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > -{
> > - struct hibmc_framebuffer *hibmc_fb = to_hibmc_framebuffer(fb);
> > -
> > -
Re: [PATCH v4] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Fri, Nov 22, 2019 at 1:13 AM Karol Herbst wrote: > > so while trying to test with d3cold disabled, I noticed that I run > into the exact same error. Does this mean that you disabled d3cold on the GPU via sysfs (the "d3cold_allowed" attribute was 0) and the original problem still occurred in that configuration? > And I verified that the > \_SB.PCI0.PEG0.PG00._STA returns 1, which indicates it should still be > turned on. I don't really understand this comment, so can you explain it a bit to me, please? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: Use ARRAY_SIZE for sos_old_versions
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c:182:40-41: WARNING: Use ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
index b4d6427..735c43c 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
@@ -179,7 +179,7 @@ static bool psp_v3_1_match_version(struct amdgpu_device
*adev, uint32_t ver)
* Double check if the latest four legacy versions.
* If yes, it is still the right version.
*/
- for (i = 0; i < sizeof(sos_old_versions) / sizeof(uint32_t); i++) {
+ for (i = 0; i < ARRAY_SIZE(sos_old_versions); i++) {
if (sos_old_versions[i] == adev->psp.sos_fw_version)
return true;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/amd/powerplay: Use ARRAY_SIZE for smu7_profiling
Fixes coccicheck warning:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:4946:28-29: WARNING: Use
ARRAY_SIZE
Reported-by: Hulk Robot
Signed-off-by: zhengbin
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index f754fbd..c3f5866 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -4943,7 +4943,7 @@ static int smu7_get_power_profile_mode(struct pp_hwmgr
*hwmgr, char *buf)
title[0], title[1], title[2], title[3],
title[4], title[5], title[6], title[7]);
- len = sizeof(smu7_profiling) / sizeof(struct profile_mode_setting);
+ len = ARRAY_SIZE(smu7_profiling);
for (i = 0; i < len; i++) {
if (i == hwmgr->power_profile_mode) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device specific compatible strings
Hi Laurent,
Thank you for your feedback!
> From: devicetree-ow...@vger.kernel.org On
> Behalf Of Laurent Pinchart
> Sent: 19 November 2019 21:52
> Subject: Re: [PATCH v4 12/13] [HACK] drm/bridge: lvds-codec: Enforce device
> specific compatible strings
>
> Hi Fabrizio,
>
> On Tue, Nov 19, 2019 at 11:17:34AM +, Fabrizio Castro wrote:
> > On 19 November 2019 00:16 Laurent Pinchart wrote:
> > > On Wed, Nov 13, 2019 at 03:51:31PM +, Fabrizio Castro wrote:
> > > > The lvds-codec driver is a generic stub for transparent LVDS
> > > > encoders and decoders.
> > > > It's good practice to list a device specific compatible string
> > >
> > > s/good practice/mandatory/
> >
> > Will fix
> >
> > > > before the generic fallback (if any) in the DT node for the relevant
> > > > LVDS encoder/decoder, and it's also required by the dt-bindings.
> > > > A notable exception to the generic fallback mechanism is the case
> > > > of "thine,thc63lvdm83d", as documented in:
> > > > Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
> > > > This patch enforces the adoption of a device specific compatible
> > > > string (as fist string in the list), by using markers for the
> > >
> > > s/fist/first/
> >
> > Well spotted
> >
> > >
> > > > compatible string we match against and the index of the matching
> > > > compatible string in the list.
> > > >
> > > > Signed-off-by: Fabrizio Castro
> > > >
> > > > ---
> > > > Hi Laurent,
> > > >
> > > > I don't think we need to do anything in the driver to address your
> > > > comment, as we can "enforce" this with the bindings (please see the
> > > > next patch, as it would help with the "enforcing" of the compatible
> > > > string for the thine device).
> > > > I am sending this patch only so that you can see what a possible
> > > > solution in the driver could look like.
> > > >
> > > > v3->v4:
> > > > * New patch addressing the below comment from Laurent:
> > > > "I think the lvds-decoder driver should error out at probe time if only
> > > > one compatible string is listed."
> > > > ---
> > > > drivers/gpu/drm/bridge/lvds-codec.c | 55
> > > > +
> > > > 1 file changed, 49 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > index 784bbd3..145c25d 100644
> > > > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > > > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > > > @@ -14,11 +14,16 @@
> > > > #include
> > > > #include
> > > >
> > > > +struct lvds_codec_data {
> > > > + u32 connector_type;
> > > > + bool device_specific;
> > > > +};
> > > > +
> > > > struct lvds_codec {
> > > > struct drm_bridge bridge;
> > > > struct drm_bridge *panel_bridge;
> > > > struct gpio_desc *powerdown_gpio;
> > > > - u32 connector_type;
> > > > + const struct lvds_codec_data *data;
> > > > };
> > > >
> > > > static int lvds_codec_attach(struct drm_bridge *bridge)
> > > > @@ -65,7 +70,30 @@ static int lvds_codec_probe(struct platform_device
> > > > *pdev)
> > > > if (!lvds_codec)
> > > > return -ENOMEM;
> > > >
> > > > - lvds_codec->connector_type =
> > > > (u32)of_device_get_match_data(>dev);
> > > > + lvds_codec->data = of_device_get_match_data(>dev);
> > > > + if (!lvds_codec->data)
> > > > + return -EINVAL;
> > > > +
> > > > + /*
> > > > +* If we haven't matched a device specific compatible string,
> > > > we need
> > > > +* to work out if the generic compatible string we matched
> > > > against was
> > > > +* listed first in the compatible property.
> > > > +*/
> > >
> > > Can't we do this unconditionally, and thus drop the lvds_codec_data
> > > structure ?
> >
> > I don't think so, and the reason for this is that we have a corner case for
> > thine,thc63lvdm83d. Here is what's allowed (according to the documentation)
> > from what's supported upstream (+ this series):
> > "ti,ds90c185", "lvds-encoder"
> > "ti,ds90c187", "lvds-encoder"
> > "ti,sn75lvds83", "lvds-encoder"
> > "ti,ds90cf384a", "lvds-decoder"
> > "thine,thc63lvdm83d"
> >
> > As you can see from the examples above, in most cases it's enough to say
> > it's
> > all good when we match a compatible string with index > 0, but for the thine
> > device you _have_ to match the string with index 0 as that's what's
> > currently
> > documented (please see thine,thc63lvdm83d.txt) and that's what's supported
> > by device trees already (please see arch/arm/boot/dts/r8a7779-marzen.dts).
>
> How about the following logic ?
>
> if (match_index("lvds-encoder") == 0 ||
> match_index("lvds-decoder") == 0)
> return -EINVAL;
>
>
Now I see what you mean
>
> > This patch "classifies" compatible strings, and it considers a good match
> > device specific compatible strings, or generic compatible strings as long
> > as
Re: [PATCH v10 6/6] backlight: add led-backlight driver
Hi, * Jean-Jacques Hiblot [700101 00:00]: > From: Tomi Valkeinen > > This patch adds a led-backlight driver (led_bl), which is similar to > pwm_bl except the driver uses a LED class driver to adjust the > brightness in the HW. Multiple LEDs can be used for a single backlight. ... > + ret = of_property_read_u32(node, "default-brightness", ); > + if (!ret && value <= priv->max_brightness) > + priv->default_brightness = value; > + else if (!ret && value > priv->max_brightness) > + dev_warn(dev, "Invalid default brightness. Ignoring it\n"); Hmm so just wondering.. Are we using "default-brightness" instead of the usual "default-brightness-level" here? Please Cc me on the next patchset too :) Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/imx: fix memory leak in imx_pd_bind
On Fri, Oct 4, 2019 at 2:09 PM Navid Emamdoost
wrote:
>
> In imx_pd_bind, the duplicated memory for imxpd->edid via kmemdup should
> be released in drm_of_find_panel_or_bridge or imx_pd_register fail.
>
> Fixes: ebc944613567 ("drm: convert drivers to use
> drm_of_find_panel_or_bridge")
> Fixes: 19022aaae677 ("staging: drm/imx: Add parallel display support")
> Signed-off-by: Navid Emamdoost
> ---
Would you please review this patch?
Thanks,
> drivers/gpu/drm/imx/parallel-display.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/parallel-display.c
> b/drivers/gpu/drm/imx/parallel-display.c
> index e7ce17503ae1..9522d2cb0ad5 100644
> --- a/drivers/gpu/drm/imx/parallel-display.c
> +++ b/drivers/gpu/drm/imx/parallel-display.c
> @@ -227,14 +227,18 @@ static int imx_pd_bind(struct device *dev, struct
> device *master, void *data)
>
> /* port@1 is the output port */
> ret = drm_of_find_panel_or_bridge(np, 1, 0, >panel,
> >bridge);
> - if (ret && ret != -ENODEV)
> + if (ret && ret != -ENODEV) {
> + kfree(imxpd->edid);
> return ret;
> + }
>
> imxpd->dev = dev;
>
> ret = imx_pd_register(drm, imxpd);
> - if (ret)
> + if (ret) {
> + kfree(imxpd->edid);
> return ret;
> + }
>
> dev_set_drvdata(dev, imxpd);
>
> --
> 2.17.1
>
--
Navid.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when the framebuffer size is greater than 4MB. For size under
4MB, we use alloc_pages to achieve this.
To enable framebuffer memory allocation from CMA, supply a kernel
parameter to give enough space to CMA allocator at boot time. For
example:
cma=130m
This gives 130MB memory to CAM allocator that can be allocated to
framebuffer. If this fails, we fall back to the old way of using
mmio for framebuffer.
Signed-off-by: Wei Hu
---
v2: Incorporated review comments form h...@lst.de, Michael Kelley and
Dexuan Cui
- Use dma_alloc_coherent to allocate large contiguous memory
- Use phys_addr_t for physical addresses
- Corrected a few spelling errors and minor cleanups
- Also tested on 32 bit Ubuntu guest
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/hyperv_fb.c | 196 +---
2 files changed, 158 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index aa9541bf964b..87b82de4598d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2215,6 +2215,7 @@ config FB_HYPERV
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_DEFERRED_IO
+ select DMA_CMA if HAVE_DMA_CONTIGUOUS
help
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 3f60b7bc8589..8ba96764c749 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -31,6 +31,16 @@
* "set-vmvideo" command. For example
* set-vmvideo -vmname name -horizontalresolution:1920 \
* -verticalresolution:1200 -resolutiontype single
+ *
+ * Gen 1 VMs also support direct using VM's physical memory for framebuffer.
+ * It could improve the efficiency and performance for framebuffer and VM.
+ * This requires to allocate contiguous physical memory from Linux kernel's
+ * CMA memory allocator. To enable this, supply a kernel parameter to give
+ * enough memory space to CMA allocator for framebuffer. For example:
+ *cma=130m
+ * This gives 130MB memory to CMA allocator that can be allocated to
+ * framebuffer. For reference, 8K resolution (7680x4320) takes about
+ * 127MB memory.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -227,7 +237,6 @@ struct synthvid_msg {
} __packed;
-
/* FB driver definitions and structures */
#define HVFB_WIDTH 1152 /* default screen width */
#define HVFB_HEIGHT 864 /* default screen height */
@@ -256,12 +265,15 @@ struct hvfb_par {
/* If true, the VSC notifies the VSP on every framebuffer change */
bool synchronous_fb;
+ /* If true, need to copy from deferred IO mem to framebuffer mem */
+ bool need_docopy;
+
struct notifier_block hvfb_panic_nb;
/* Memory for deferred IO and frame buffer itself */
unsigned char *dio_vp;
unsigned char *mmio_vp;
- unsigned long mmio_pp;
+ phys_addr_t mmio_pp;
/* Dirty rectangle, protected by delayed_refresh_lock */
int x1, y1, x2, y2;
@@ -432,7 +444,7 @@ static void synthvid_deferred_io(struct fb_info *p,
maxy = max_t(int, maxy, y2);
/* Copy from dio space to mmio address */
- if (par->fb_ready)
+ if (par->fb_ready && par->need_docopy)
hvfb_docopy(par, start, PAGE_SIZE);
}
@@ -749,12 +761,12 @@ static void hvfb_update_work(struct work_struct *w)
return;
/* Copy the dirty rectangle to frame buffer memory */
- for (j = y1; j < y2; j++) {
- hvfb_docopy(par,
- j * info->fix.line_length +
- (x1 * screen_depth / 8),
- (x2 - x1) * screen_depth / 8);
- }
+ if (par->need_docopy)
+ for (j = y1; j < y2; j++)
+ hvfb_docopy(par,
+ j * info->fix.line_length +
+ (x1 * screen_depth / 8),
+ (x2 - x1) * screen_depth / 8);
/* Refresh */
if (par->fb_ready && par->update)
@@ -799,7 +811,8 @@ static int hvfb_on_panic(struct notifier_block *nb,
par = container_of(nb, struct hvfb_par, hvfb_panic_nb);
par->synchronous_fb = true;
info = par->info;
- hvfb_docopy(par, 0, dio_fb_size);
+ if (par->need_docopy)
+ hvfb_docopy(par, 0, dio_fb_size);
synthvid_update(info, 0, 0, INT_MAX, INT_MAX);
return NOTIFY_DONE;
@@ -938,6 +951,74 @@ static void hvfb_get_option(struct fb_info
[PATCH v2 1/4] dt-bindings: drm/msm/gpu: document second interconnect
Some A3xx and all A4xx Adreno GPUs do not have GMEM inside the GPU core and must use the On Chip MEMory (OCMEM) in order to be functional. There's a separate interconnect path that needs to be setup to OCMEM. Let's document this second interconnect path that's available. Since there's now two available interconnects, let's add the interconnect-names property. Signed-off-by: Brian Masney --- Documentation/devicetree/bindings/display/msm/gpu.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 2b8fd26c43b0..3e6cd3f64a78 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -23,7 +23,10 @@ Required properties: - iommus: optional phandle to an adreno iommu instance - operating-points-v2: optional phandle to the OPP operating points - interconnects: optional phandle to an interconnect provider. See - ../interconnect/interconnect.txt for details. + ../interconnect/interconnect.txt for details. Some A3xx and all A4xx platforms + will have two paths; all others will have one path. +- interconnect-names: The names of the interconnect paths that correspond to the + interconnects property. Values must be gfx-mem and ocmem. - qcom,gmu: For GMU attached devices a phandle to the GMU device that will control the power for the GPU. Applicable targets: - qcom,adreno-630.2 @@ -76,6 +79,7 @@ Example a6xx (with GMU): operating-points-v2 = <_opp_table>; interconnects = <_hlos MASTER_GFX3D _hlos SLAVE_EBI1>; + interconnect-names = "gfx-mem"; qcom,gmu = <>; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/msm/a3xx: set interconnect bandwidth vote
Set the two interconnect paths for the GPU to maximum speed for now to work towards getting the GPU working upstream. We can revisit a later time to optimize this for battery life. Signed-off-by: Brian Masney --- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c index 07ddcc529573..eff0ecd4e81a 100644 --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c @@ -504,6 +504,14 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev) DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n"); } + /* +* Set the ICC path to maximum speed for now by multiplying the fastest +* frequency by the bus width (8). We'll want to scale this later on to +* improve battery life. +*/ + icc_set_bw(gpu->icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8); + icc_set_bw(gpu->ocmem_icc_path, 0, Bps_to_icc(gpu->fast_rate) * 8); + return gpu; fail: -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 08/29] dt-bindings: interconnect: tegra: Add initial IDs
19.11.2019 19:56, Dmitry Osipenko пишет: > 19.11.2019 09:25, Thierry Reding пишет: >> On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote: >>> Define interconnect IDs for memory controller (MC), external memory >>> controller (EMC), external memory (EMEM) and memory clients of display >>> controllers (DC). >>> >>> Signed-off-by: Dmitry Osipenko >>> --- >>> include/dt-bindings/interconnect/tegra-icc.h | 11 +++ >>> 1 file changed, 11 insertions(+) >>> create mode 100644 include/dt-bindings/interconnect/tegra-icc.h > > > Hello Thierry, > >> There was a bit of discussion regarding this for a recent patch that I >> was working on, see: >> >> http://patchwork.ozlabs.org/project/linux-tegra/list/?series=140318 > > Thank you very much for the link. > >> I'd rather not use an additional set of definitions for this. The memory >> controller already has a set of native IDs for memory clients that I >> think we can reuse for this. > > I missed that it's fine to have multiple ICC connections defined > per-path, at quick glance looks like indeed it should be fine to re-use > MC IDs. Well, it is not quite correct to have multiple connections per-path. Please take look at interconnect's binding and core.c: 1. there should be one src->dst connection per-path 2. each connection should comprise of one source and one destination nodes >> I've only added these client IDs for Tegra194 because that's where we >> need it to actually describe a specific hardware quirk, but I can come >> up with the equivalent for older chips as well. > > Older Tegra SoCs have hardware units connected to MC through AHB bus, > like USB for example. These units do not have MC client IDs and there is > no MC ID defined for the AHB bus either, but probably it won't be a > problem to define IDs for them if will be necessary. > Since interconnect binding requires to define both source and destination nodes for the path, then MC IDs are not enough in order to define interconnect path because these IDs represent only the source nodes. Destination node should be either EMC or EMEM. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add
On Tue, Sep 24, 2019 at 11:38 PM Navid Emamdoost
wrote:
>
> In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
> for cres should be released.
>
> Signed-off-by: Navid Emamdoost
Would you please review this patch?
Thanks,
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> index 4ac55fc2bf97..44d858ce4ce7 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
> @@ -209,8 +209,10 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager
> *man,
>
> cres->hash.key = user_key | (res_type << 24);
> ret = drm_ht_insert_item(>resources, >hash);
> - if (unlikely(ret != 0))
> + if (unlikely(ret != 0)) {
> + kfree(cres);
> goto out_invalid_key;
> + }
>
> cres->state = VMW_CMDBUF_RES_ADD;
> cres->res = vmw_resource_reference(res);
> --
> 2.17.1
>
--
Navid.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/amd: Use ARRAY_SIZE
zhengbin (2): drm/amd/powerplay: Use ARRAY_SIZE for smu7_profiling drm/amdgpu: Use ARRAY_SIZE for sos_old_versions drivers/gpu/drm/amd/amdgpu/psp_v3_1.c| 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
