Re: [PATCH 4/4] PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse
Am 07.01.21 um 22:32 schrieb Bjorn Helgaas: On Thu, Jan 07, 2021 at 06:50:17PM +0100, Nirmoy Das wrote: RX 5600 XT Pulse advertises support for BAR0 being 256MB, 512MB, or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar size quirk so that CPU can fully access the BAR0. This isn't quite accurate. The CPU can fully access BAR 0 no matter what. I think the problem you're solving is that without this quirk, BAR 0 isn't big enough to cover the VRAM. Signed-off-by: Christian König Reported-by: kernel test robot Reported-by: Dan Carpenter IIRC, these Reported-by lines are from the "cap == 0x3f0" problem. It would make sense to include these if this patch fixed that problem in something that had already been merged. But this *hasn't* been merged, so these lines only make sense to someone who trawls through the mailing list to find the previous version. I don't really think it's worthwhile to include them. It's the same as giving credit to reviewers, which we typically don't do except via a Reviewed-by tag (which I think is too strong for this case) or a "v2" changes note after the "---" line. That doesn't get included in the git history, but is easily findable via the Link: tags as below. If you merge these via a non-PCI tree, please include the "Link:" lines in the PCI patches, e.g., Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20210107175017.15893-5-nirmoy.das%40amd.com&data=04%7C01%7Cchristian.koenig%40amd.com%7C33c14f5361e84d9d0e4908d8b353c412%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637456519678601616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wY9qaz3DTZA069qznMC9Wvoq9SZIzyJHE0XkaVXoqAc%3D&reserved=0 for this one. Obviously the link is different for each patch and will change if you repost the series. I'm not sure why you put the amd patch in the middle of the series. Seems like it would be slightly prettier and just as safe to put it at the end. Signed-off-by: Nirmoy Das Acked-by: Bjorn Helgaas Let me know if you want me to take the series. I will make the suggested changes and take this through the drm subsystem. That makes more sense since it only affects our hardware anyway. --- drivers/pci/pci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 16216186b51c..b061bbd4afb1 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) return 0; pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); - return (cap & PCI_REBAR_CAP_SIZES) >> 4; + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; + + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && + bar == 0 && cap == 0x700) + cap = 0x3f00; I think this is structured wrong. It should be like this so it's easier to match with the spec: cap &= PCI_REBAR_CAP_SIZES; if (... && cap == 0x7000) cap = 0x3f000; return cap >> 4; Good point. Thanks, Christian. + + return cap; } EXPORT_SYMBOL(pci_rebar_get_possible_sizes); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] PCI: Add pci_rebar_bytes_to_size()
I demand that Bjorn Helgaas may or may not have written...
>> +static inline int pci_rebar_bytes_to_size(u64 bytes)
>> +{
>> +bytes = roundup_pow_of_two(bytes);
>> +return max(ilog2(bytes), 20) - 20;
> This isn't returning a "size", is it? It looks like it's returning the
> log2 of the number of MB the BAR will be, i.e., the encoding used by the
> Resizable BAR Control register "BAR Size" field. Needs a brief comment to
> that effect and/or a different function name.
Given that, it seems to me that pci_rebar_size_to_bytes should be similarly
commented and/or renamed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 3/3] Revert "drm/amd/display: Expose new CRC window property"
[AMD Public Use]
Thanks Siqueira.
Comments below.
> -Original Message-
> From: Siqueira, Rodrigo
> Sent: Friday, January 8, 2021 4:53 AM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Deucher, Alexander
> ; Wentland, Harry
> ; Li, Roman ; R, Bindu
> ; Daniel Vetter
> Subject: [PATCH 3/3] Revert "drm/amd/display: Expose new CRC window property"
>
> This reverts commit 110d586ba77ed573eb7464ca69b6490ec0b70c5f.
>
> Cc: Wayne Lin
> Cc: Alexander Deucher
> Cc: Harry Wentland
> Cc: Roman Li
> Cc: Bindu R
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Siqueira
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |
> 19 --- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +--
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 3 -
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +
> 5 files changed, 12 insertions(+), 210 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a06554745238..0515ed0d125c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -938,41 +938,6 @@ static void mmhub_read_system_context(struct
> amdgpu_device *adev, struct dc_phy_ } #endif
>
> -#ifdef CONFIG_DEBUG_FS
> -static int create_crtc_crc_properties(struct amdgpu_display_manager *dm) -{
> -dm->crc_win_x_start_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> - DRM_MODE_PROP_ATOMIC,
> - "AMD_CRC_WIN_X_START", 0, U16_MAX);
> -if (!dm->crc_win_x_start_property)
> -return -ENOMEM;
> -
> -dm->crc_win_y_start_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> - DRM_MODE_PROP_ATOMIC,
> - "AMD_CRC_WIN_Y_START", 0, U16_MAX);
> -if (!dm->crc_win_y_start_property)
> -return -ENOMEM;
> -
> -dm->crc_win_x_end_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> - DRM_MODE_PROP_ATOMIC,
> - "AMD_CRC_WIN_X_END", 0, U16_MAX);
> -if (!dm->crc_win_x_end_property)
> -return -ENOMEM;
> -
> -dm->crc_win_y_end_property =
> -drm_property_create_range(adev_to_drm(dm->adev),
> - DRM_MODE_PROP_ATOMIC,
> - "AMD_CRC_WIN_Y_END", 0, U16_MAX);
> -if (!dm->crc_win_y_end_property)
> -return -ENOMEM;
> -
> -return 0;
> -}
> -#endif
> -
> static int amdgpu_dm_init(struct amdgpu_device *adev) {
> struct dc_init_data init_data;
> @@ -1119,10 +1084,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
>
> dc_init_callbacks(adev->dm.dc, &init_params);
> }
> -#endif
> -#ifdef CONFIG_DEBUG_FS
> -if (create_crtc_crc_properties(&adev->dm))
> -DRM_ERROR("amdgpu: failed to create crc property.\n");
> #endif
> if (amdgpu_dm_initialize_drm_device(adev)) {
> DRM_ERROR(
> @@ -5456,64 +5417,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
> state->crc_src = cur->crc_src;
> state->cm_has_degamma = cur->cm_has_degamma;
> state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb; -#ifdef CONFIG_DEBUG_FS
> -state->crc_window = cur->crc_window;
> -#endif
> +
> /* TODO Duplicate dc_stream after objects are stream object is flattened */
>
> return &state->base;
> }
>
> -#ifdef CONFIG_DEBUG_FS
> -static int amdgpu_dm_crtc_atomic_set_property(struct drm_crtc *crtc,
> -struct drm_crtc_state *crtc_state,
> -struct drm_property *property,
> -uint64_t val)
> -{
> -struct drm_device *dev = crtc->dev;
> -struct amdgpu_device *adev = drm_to_adev(dev);
> -struct dm_crtc_state *dm_new_state =
> -to_dm_crtc_state(crtc_state);
> -
> -if (property == adev->dm.crc_win_x_start_property)
> -dm_new_state->crc_window.x_start = val;
> -else if (property == adev->dm.crc_win_y_start_property)
> -dm_new_state->crc_window.y_start = val;
> -else if (property == adev->dm.crc_win_x_end_property)
> -dm_new_state->crc_window.x_end = val;
> -else if (property == adev->dm.crc_win_y_end_property)
> -dm_new_state->crc_window.y_end = val;
> -else
> -return -EINVAL;
> -
> -return 0;
> -}
> -
> -static int amdgpu_dm_crtc_atomic_get_property(struct drm_crtc *crtc,
> -const struct drm_crtc_state *state,
> -struct drm_property *property,
> -uint64_t *val)
> -{
> -struct drm_device *dev = crtc->dev;
> -struct amdgpu_device *adev = drm_to_adev(dev);
> -struct dm_crtc_state *dm_state =
> -to_dm_crtc_state(state);
> -
> -if (property == adev->dm.crc_win_x_start_property)
> -*val = dm_state->crc_window.x_start;
> -else if (property == adev->dm.crc_win_y_start_property)
> -*val = dm_state->crc_window.y_start;
> -else if (property == adev->dm.crc_win_x_end_property)
> -*val = dm_state->crc_window.x_end;
> -else if (property == adev->dm.crc_win_y_end_property)
> -*val = dm_state->crc_window.y_end;
> -else
> -return -EINVAL;
> -
> -return 0;
> -}
> -#endif
> -
> static inline int dm_set_vupdate_irq(struct drm_crtc *crtc, bool enable) {
> enum dc_irq_source irq_source;
> @@ -5599,10 +5508,6 @@ static const struct drm_crtc_funcs
> amdg
Re: [PATCH v5 10/11] dt-bindings: usb: convert mediatek, mtu3.txt to YAML schema
On Fri, 25 Dec 2020 15:52:57 +0800, Chunfeng Yun wrote: > Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob > 1. remove unnecessary maxItems > 2. define all phys supported > > v4: > 1. refer to usb-drd.yaml insstead of usb/generic.txt > the following ones suggested by Rob: > 2. add the number of phys supported > 3. fix indentation of wakeup > 4. add examples for port and connector > > v3: > 1. fix yamllint warning > 2. remove pinctrl* properties > 3. remove unnecessary '|' > 4. drop unused labels in example > > v2: new patch > --- > .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 --- > .../bindings/usb/mediatek,mtu3.yaml | 287 ++ > 2 files changed, 287 insertions(+), 108 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt > create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 09/11] dt-bindings: usb: convert mediatek, mtk-xhci.txt to YAML schema
On Fri, 25 Dec 2020 15:52:56 +0800, Chunfeng Yun wrote: > Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob > 1. refer to usb-xhci.yaml instead of usb-hcd.yaml > 2. remove unnecessary maxItems > 3. add items for all phys may be supported > 4. change pattern, and limit pattern length of patternProperties > > v4: update it according to Rob's suggestion > 1. modify dictionary of phys > 2. fix endentation in "mediatek,syscon-wakeup" items > 3. remove reference to usb-hcd.yaml > > v3: > 1. fix yamllint warning > 2. remove pinctrl* properties supported by default suggested by Rob > 3. drop unused labels > 4. modify description of mediatek,syscon-wakeup > 5. remove type of imod-interval-ns > > v2: new patch > --- > .../bindings/usb/mediatek,mtk-xhci.txt| 121 > .../bindings/usb/mediatek,mtk-xhci.yaml | 178 ++ > 2 files changed, 178 insertions(+), 121 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt > create mode 100644 > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/11] dt-bindings: usb: convert usb-device.txt to YAML schema
On Fri, 25 Dec 2020 15:52:48 +0800, Chunfeng Yun wrote: > Convert usb-device.txt to YAML schema usb-device.yaml > > Signed-off-by: Chunfeng Yun > --- > v5: changes suggested by Rob: > 1. limit the pattern length > 2. remove properties description for hard wired USB devices in usb-hcd.yaml > > depends on series: > https://patchwork.kernel.org/project/linux-usb/list/?series=399561 > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v4: no changes, update dependent series: > https://patchwork.kernel.org/project/linux-usb/list/?series=399561 > [v6,00/19] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v3: > 1. remove $nodenmae and items key word for compatilbe; > 2. add additionalProperties; > > The followings are suggested by Rob: > 3. merge the following patch > [v2,1/4] dt-bindings: usb: convert usb-device.txt to YAML schema > [v2,2/4] dt-bindings: usb: add properties for hard wired devices > 4. define the unit-address for hard-wired device in usb-hcd.yaml, > also define its 'reg' and 'compatible'; > 5. This series is base on Serge's series: > > https://patchwork.kernel.org/project/linux-usb/cover/2020090853.14112-1-sergey.se...@baikalelectronics.ru/ > [v4,00/18] dt-bindings: usb: Add generic USB HCD, xHCI, DWC USB3 DT schema > > v2 changes suggested by Rob: > 1. modify pattern to support any USB class > 2. convert usb-device.txt into usb-device.yaml > --- > .../devicetree/bindings/usb/usb-device.txt| 102 -- > .../devicetree/bindings/usb/usb-device.yaml | 124 ++ > .../devicetree/bindings/usb/usb-hcd.yaml | 19 +++ > 3 files changed, 143 insertions(+), 102 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt > create mode 100644 Documentation/devicetree/bindings/usb/usb-device.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 1/3] dt-binding: gce: add gce header file for mt8192
On Thu, 24 Dec 2020 08:48:07 +0800, Yongqiang Niu wrote: > Add documentation for the mt8192 gce. > > Add gce header file defined the gce hardware event, > subsys number and constant for mt8192. > > Signed-off-by: Yongqiang Niu > --- > .../devicetree/bindings/mailbox/mtk-gce.txt| 7 +- > include/dt-bindings/gce/mt8192-gce.h | 419 > + > 2 files changed, 423 insertions(+), 3 deletions(-) > create mode 100644 include/dt-bindings/gce/mt8192-gce.h > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: bcm2835-vec: Add power-domains property
On Wed, 23 Dec 2020 20:24:33 +0100, Stefan Wahren wrote: > Adding the missing property power-domains to the bcm2835-vec schema to fix > the following dtbs_check issue: > > vec@7e806000: 'power-domains' does not match any of the regexes: ... > > Signed-off-by: Stefan Wahren > --- > Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: fix prime export for vram objects
On Thu, Jan 7, 2021 at 1:07 PM Chia-I Wu wrote:
> commit 16845c5d5409 ("drm/virtio: implement blob resources: implement
> vram object") and commit c6069a02fa55 ("drm/virtgpu: Set PRIME export
> function in struct drm_gem_object_funcs") landed from different trees,
> resulting in prime export never working for vram objects.
>
> Cc: Gurchetan Singh
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_vram.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_vram.c
> b/drivers/gpu/drm/virtio/virtgpu_vram.c
> index d6f215c4ff8d..5cc34e7330fa 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_vram.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_vram.c
> @@ -69,6 +69,7 @@ static const struct drm_gem_object_funcs
> virtio_gpu_vram_funcs = {
> .close = virtio_gpu_gem_object_close,
> .free = virtio_gpu_vram_free,
> .mmap = virtio_gpu_vram_mmap,
> + .export = virtgpu_gem_prime_export,
> };
>
> bool virtio_gpu_is_vram(struct virtio_gpu_object *bo)
> --
> 2.29.2.729.g45daf8777d-goog
>
>
Reviewed-by: Gurchetan Singh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: make sure context is created in gem open
On Thu, Jan 7, 2021 at 1:07 PM Chia-I Wu wrote:
> The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is
> the first ioctl on the drm_file.
>
> Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after
> the first 3D ioctl")
> Cc: Gurchetan Singh
> Cc: Gerd Hoffmann
> Signed-off-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index c30c75ee83fc..8502400b2f9c 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -39,9 +39,6 @@ static int virtio_gpu_gem_create(struct drm_file *file,
> int ret;
> u32 handle;
>
> - if (vgdev->has_virgl_3d)
> - virtio_gpu_create_context(dev, file);
> -
> ret = virtio_gpu_object_create(vgdev, params, &obj, NULL);
> if (ret < 0)
> return ret;
> @@ -119,6 +116,11 @@ int virtio_gpu_gem_object_open(struct drm_gem_object
> *obj,
> if (!vgdev->has_virgl_3d)
> goto out_notify;
>
> + /* the context might still be missing when the first ioctl is
> +* DRM_IOCTL_MODE_CREATE_DUMB or DRM_IOCTL_PRIME_FD_TO_HANDLE
> +*/
> + virtio_gpu_create_context(obj->dev, file);
> +
> objs = virtio_gpu_array_alloc(1);
> if (!objs)
> return -ENOMEM;
> --
> 2.29.2.729.g45daf8777d-goog
>
> Reviewed-by: Gurchetan Singh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
Hi Thomas, Thanks for the feedback, do you mean the patch was applied to a wrong base? Best Regards, Rong Chen On 1/7/21 6:45 PM, Thomas Zimmermann wrote: AFAICT these are false positives. The instances have been fixed already. Am 07.01.21 um 10:45 schrieb kernel test robot: Hi Thomas, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: x86_64-randconfig-s021-20210107 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/oaktrail_device.c: In function 'oaktrail_chip_setup': drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 509 | if (pci_enable_msi(dev->pdev)) | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 'oaktrail_lvds_set_power': drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 63 | pm_request_idle(&dev->pdev->dev); | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 69 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 83 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'oaktrail_lvds_i2c_init': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 148 | chan->adapter.dev.parent = &dev->pdev->dev; | ^~~~ | dev -- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load': drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 661 | pci_set_master(dev->pdev); | ^~~~ | dev In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31: drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 690 | dev_priv->io_start = pci_resource_start(dev->pdev, 0); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) | ^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 691 | dev_priv->vram_start = pci_resource_start(dev->pdev, 1); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) | ^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct d
Re: linux-next: build failure after merge of the drm tree
Hi all,
On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> error: the following would cause module name conflict:
> drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> drivers/gpu/drm/panel/panel-dsi-cm.ko
>
> Maybe caused by commit
>
> cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
>
> I have used the drm tree from next-20210107 for today.
This has affected the drm-misc tree as well (since it merged in the drm
tree).
I have used the drm-misc tree from next-20210107 for today.
--
Cheers,
Stephen Rothwell
pgpBEDBFN2RtU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 4/4] drm/panfrost: Add mt8183-mali compatible string
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
---
(no changes since v7)
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conflicts, reflow the code.
- Use ARRAY_SIZE for power domains too.
Changes in v5:
- Change power domain name from 2d to core2.
Changes in v4:
- Add power domain names.
Changes in v3:
- Match mt8183-mali instead of bifrost, as we require special
handling for the 2 regulators and 3 power domains.
drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461bdeea8..ca07098a6141 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -665,6 +665,15 @@ static const struct panfrost_compatible amlogic_data = {
.vendor_quirk = panfrost_gpu_amlogic_quirk,
};
+const char * const mediatek_mt8183_supplies[] = { "mali", "sram" };
+const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2"
};
+static const struct panfrost_compatible mediatek_mt8183_data = {
+ .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies),
+ .supply_names = mediatek_mt8183_supplies,
+ .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains),
+ .pm_domain_names = mediatek_mt8183_pm_domains,
+};
+
static const struct of_device_id dt_match[] = {
/* Set first to probe before the generic compatibles */
{ .compatible = "amlogic,meson-gxm-mali",
@@ -681,6 +690,7 @@ static const struct of_device_id dt_match[] = {
{ .compatible = "arm,mali-t860", .data = &default_data, },
{ .compatible = "arm,mali-t880", .data = &default_data, },
{ .compatible = "arm,mali-bifrost", .data = &default_data, },
+ { .compatible = "mediatek,mt8183-mali", .data = &mediatek_mt8183_data },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.29.2.729.g45daf8777d-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
does not support multiple regulators, so we'll need custom
handlers.
2. Generally, platforms with 2 regulators have platform-specific
constraints on how the voltages should be set (e.g.
minimum/maximum voltage difference between them), so we
should not just create generic handlers that simply
change the voltages without taking care of those constraints.
Disable devfreq for now on those GPUs.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
---
Changes in v9:
- Explain why devfreq needs to be disabled for GPUs with >1
regulators.
Changes in v8:
- Use DRM_DEV_INFO instead of ERROR
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- New change
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index f44d28fad085..812cfecdee3b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
+ if (pfdev->comp->num_supplies > 1) {
+ /*
+* GPUs with more than 1 supply require platform-specific
handling:
+* continue without devfreq
+*/
+ DRM_DEV_INFO(dev, "More than 1 supply is not supported yet\n");
+ return 0;
+ }
+
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {
--
2.29.2.729.g45daf8777d-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/4] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183
Define a compatible string for the Mali Bifrost GPU found in Mediatek's MT8183 SoCs. Signed-off-by: Nicolas Boichat Reviewed-by: Alyssa Rosenzweig --- (no changes since v6) Changes in v6: - Rebased, actually tested with recent mesa driver. - No change Changes in v5: - Rename "2d" power domain to "core2" Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) Changes in v3: - No change .../bindings/gpu/arm,mali-bifrost.yaml| 25 +++ 1 file changed, 25 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 184492162e7e..71b613ee5bd7 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -87,6 +88,30 @@ allOf: then: required: - resets + - if: + properties: +compatible: + contains: +const: mediatek,mt8183-mali +then: + properties: +sram-supply: true +power-domains: + description: +List of phandle and PM domain specifier as documented in +Documentation/devicetree/bindings/power/power_domain.txt + minItems: 3 + maxItems: 3 +power-domain-names: + items: +- const: core0 +- const: core1 +- const: core2 + + required: +- sram-supply +- power-domains +- power-domains-names examples: - | -- 2.29.2.729.g45daf8777d-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 0/4] drm/panfrost: Add support for mt8183 GPU
Hi! Follow-up on the v5 [1], things have gotten significantly better in the last 9 months, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.259332-1-drink...@chromium.org/ [2] https://crrev.com/c/2608070 Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml| 25 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 6 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 6 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 6 files changed, 161 insertions(+) -- 2.29.2.729.g45daf8777d-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] PCI: Add pci_rebar_bytes_to_size()
On Thu, Jan 07, 2021 at 11:31:36PM +, Darren Salt wrote:
> I demand that Bjorn Helgaas may or may not have written...
?
> >> +static inline int pci_rebar_bytes_to_size(u64 bytes)
> >> +{
> >> + bytes = roundup_pow_of_two(bytes);
> >> + return max(ilog2(bytes), 20) - 20;
>
> > This isn't returning a "size", is it? It looks like it's returning the
> > log2 of the number of MB the BAR will be, i.e., the encoding used by the
> > Resizable BAR Control register "BAR Size" field. Needs a brief comment to
> > that effect and/or a different function name.
>
> Given that, it seems to me that pci_rebar_size_to_bytes should be similarly
> commented and/or renamed.
Makes sense. Something like this is sufficient:
return 1ULL << (size + 20); /* Convert PCI_REBAR_CTRL "BAR Size" */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm tree
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
error: the following would cause module name conflict:
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
drivers/gpu/drm/panel/panel-dsi-cm.ko
Maybe caused by commit
cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
I have used the drm tree from next-20210107 for today.
--
Cheers,
Stephen Rothwell
pgp8llxUX_bBW.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
On Thu, Jan 7, 2021 at 11:59 PM Steven Price wrote:
>
> On 05/01/2021 00:11, Nicolas Boichat wrote:
> > GPUs with more than a single regulator (e.g. G-57 on MT8183) will
> > require platform-specific handling, disable devfreq for now.
>
> Can you explain what actually goes wrong here? AFAICT the existing code
> does support controlling multiple regulators - but clearly this is the
> first platform that exercises that code with num_supplies>1.
Sure, I should have expanded in the commit message, will do in v9.
We have support for >1 supplies, and we need to enable them to get the
GPU running _at all_ (and the default voltages should be safe by
design).
For devfreq though:
1. There are constraints on the voltage difference between the core
and SRAM, we have this caterpillar logic downstream [1], so somebody
will need to port it (TBH I don't think it's overly critical at this
point, as Bifrost support is still not very mature from what I can
see, and devfreq is purely a performance thing).
2. The core [2] does not support multiple regulators, so we'll need
custom code anyway. Even if we didn't have constraints.
[1]
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-4.19/drivers/gpu/arm/bifrost/platform/mediatek/mali_kbase_runtime_pm.c#367
[2] https://elixir.bootlin.com/linux/latest/source/drivers/opp/core.c#L679
>
> Steve
>
> >
> > Signed-off-by: Nicolas Boichat
> > ---
> >
> > Changes in v6:
> > - New change
> >
> > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > index f44d28fad085..1f49043aae73 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> > @@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> > struct thermal_cooling_device *cooling;
> > struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
> >
> > + if (pfdev->comp->num_supplies > 1) {
> > + /*
> > + * GPUs with more than 1 supply require platform-specific
> > handling:
> > + * continue without devfreq
> > + */
> > + DRM_DEV_ERROR(dev, "More than 1 supply is not supported
> > yet\n");
> > + return 0;
> > + }
> > +
> > opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
> > pfdev->comp->num_supplies);
> > if (IS_ERR(opp_table)) {
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: dsi: Fix EoTp flag
Hi, Jitao: Jitao Shi 於 2021年1月7日 週四 下午10:34寫道： > > SoC will transmit the EoTp (End of Transmission packet) when > MIPI_DSI_MODE_EOT_PACKET flag is set. > > Enabling EoTp will make the line time larger, so the hfp and > hbp should be reduced to keep line time. > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 65fd99c528af..8c70ec39bfe1 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -401,8 +401,11 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) > break; > } > > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; > + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) > + tmp_reg |= HSTX_CKLP_EN; > + > + if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET)) > + tmp_reg |= DIS_EOT; This part is not related to line time, so separate this part to another patch. Regards, Chun-Kuang. > > writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); > } > @@ -478,6 +481,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) > timing->da_hs_zero + timing->da_hs_exit + 3; > > delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12; > + delta += dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET ? 2 : 0; > > horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp; > horizontal_front_back_byte = horizontal_frontporch_byte + > horizontal_backporch_byte; > -- > 2.25.1 > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
drivers/gpu/drm/drm_dp_helper.c | 83 +--
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
.../drm/i915/display/intel_display_types.h| 1 -
drivers/gpu/drm/i915/display/intel_dp.c | 9 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 21 +
7 files changed, 9 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
- !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+ !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
}
EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident,
bool is_branch)
#undef DEVICE_ID_ANY
#undef DEVICE_ID
-struct edid_quirk {
- u8 mfg_id[2];
- u8 prod_id[2];
- u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
- /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
- { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
- { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can
[PATCH v5 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul
Reviewed-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
drivers/gpu/drm/i915/i915_params.c| 2 +-
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5e761fb49a14..4b2cb20b1f94 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -613,15 +613,54 @@ static const struct intel_panel_bl_funcs
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
};
+enum intel_dp_aux_backlight_modparam {
+ INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+ INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+ INTEL_DP_AUX_BACKLIGHT_ON = 1,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
{
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool try_intel_interface = false, try_vesa_interface = false;
- if (i915->params.enable_dpcd_backlight == 0)
+ /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+ switch (i915->params.enable_dpcd_backlight) {
+ case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+ case INTEL_DP_AUX_BACKLIGHT_AUTO:
+ switch (i915->vbt.backlight.type) {
+ case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+ try_vesa_interface = true;
+ break;
+ case INTEL_BACKLIGHT_DISPLAY_DDI:
+ try_intel_interface = true;
+ try_vesa_interface = true;
+ break;
+ default:
+ return -ENODEV;
+ }
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_ON:
+ if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+ try_intel_interface = true;
+
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+ try_intel_interface = true;
+ break;
+ }
/*
* A lot of eDP panels in the wild will report supporting both the
@@ -630,13 +669,13 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
* and will only work with the Intel interface. So, always probe for
* that first.
*/
- if (intel_dp_aux_supports_hdr_backlight(connector)) {
+ if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
controls\n");
panel->backlight.funcs = &intel_dp_hdr_bl_funcs;
return 0;
}
- if (intel_dp_aux_supports_vesa_backlight(connector)) {
+ if (try_vesa_interface &&
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = &intel_dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
- "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enabled)");
+ "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enable, 2=force VESA interface, 3=force Intel interface)");
#if IS_ENABLED(CONFIG_DRM_
[PATCH v5 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v4:
* Fix checkpatch issues
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 9 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 248 --
drivers/gpu/drm/i915/display/intel_panel.c| 42 ++-
drivers/gpu/drm/i915/display/intel_panel.h| 4 +
4 files changed, 271 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee5c2d50b81a..b24d80ffd18b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
/* DPCD backlight */
- u8 pwmgen_bit_count;
+ union {
+ struct {
+ u8 pwmgen_bit_count;
+ } vesa;
+ struct {
+ bool sdr_uses_aux;
+ } intel;
+ } edp;
struct backlight_device *device;
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 9775f33d1aac..5e761fb49a14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
*
*/
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
/*
* DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,179 @@
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *co
[PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v5:
* Fix indenting warnings from checkpatch
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
2 files changed, 187 insertions(+), 150 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..ee5c2d50b81a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment; /* lpt+ */
/* PWM chip */
+ u32 pwm_level_min;
+ u32 pwm_level_max;
+ bool pwm_enabled;
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
const struct intel_panel_bl_funcs *funcs;
+ const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
};
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..8c99bf404a32 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector
*connector,
0, user_max);
}
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector,
u32
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Thu, Jan 7, 2021 at 7:16 PM Mario Kleiner wrote:
>
> On Thu, Jan 7, 2021 at 7:04 PM Daniel Vetter wrote:
>>
>> On Thu, Jan 7, 2021 at 7:00 PM Mario Kleiner
>> wrote:
>> >
>> > On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
>> >>
>> >> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
>> >> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
>> >> > wrote:
>> >> > >
>> >> > > With modifiers one can actually have different format_info structs
>> >> > > for the same format, which now matters for AMDGPU since we convert
>> >> > > implicit modifiers to explicit modifiers with multiple planes.
>> >> > >
>> >> > > I checked other drivers and it doesn't look like they end up
>> >> > > triggering
>> >> > > this case so I think this is safe to relax.
>> >> > >
>> >> > > Signed-off-by: Bas Nieuwenhuizen
>> >> > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
>> >> > > converted metadata.")
>> >> > > ---
>> >> > > drivers/gpu/drm/drm_plane.c | 2 +-
>> >> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> > >
>> >> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> >> > > index e6231947f987..f5085990cfac 100644
>> >> > > --- a/drivers/gpu/drm/drm_plane.c
>> >> > > +++ b/drivers/gpu/drm/drm_plane.c
>> >> > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device
>> >> > > *dev,
>> >> > > if (ret)
>> >> > > goto out;
>> >> > >
>> >> > > - if (old_fb->format != fb->format) {
>> >> > > + if (old_fb->format->format != fb->format->format) {
>> >> >
>> >> > This was btw. the original way before Ville made it more strict about
>> >> > 4 years ago, to catch issues related to tiling, and more complex
>> >> > layouts, like the dcc tiling/retiling introduced by your modifier
>> >> > patches. That's why I hope my alternative patch is a good solution for
>> >> > atomic drivers while keeping the strictness for potential legacy
>> >> > drivers.
>> >>
>> >> Yeah this doesn't work in full generality, because hw might need to do a
>> >> full modeset to do a full modeset to reallocate resources (like scanout
>> >> fifo space) if the format changes.
>> >>
>> >> But for atomic drivers that should be caught in ->atomic_check, which
>> >> should result in -EINVAL, so should do the right thing. So it should be
>> >> all good, but imo needs a comment to explain what's going on:
>> >>
>> >> /*
>> >> * Only check the FOURCC format code, excluding modifiers. This is
>> >> * enough for all legacy drivers. Atomic drivers have their own
>> >> * checks in their ->atomic_check implementation, which will
>> >> * return -EINVAL if any hw or driver constraint is violated due
>> >> * to modifier changes.
>> >> */
>> >>
>> >> Also can you pls cc: intel-gfx to get this vetted by the intel-gfx ci?
>> >>
>> >> With that:
>> >>
>> >> Reviewed-by: Daniel Vetter
>> >>
>> >
>> > Ah, my "atomic expert", posting simultaneously with myself :). Happy new
>> > year. Opinions on my variant, just replied a minute ago?
>>
>> Full disclosure, Ville wanted to do something similar since forever
>> I'm not a huge fan of removing limitations of legacy ioctls. Worst
>> case we break something, best case no gain in features since why don't
>> you just use atomic. Since this (amdgpu modifiers) broke something we
>> have to fix it, hence I'd go with the more minimal version from Bas
>> here.
>>
>
> Fair point. Means though that somebody will have to convert many user-space
> clients, e.g., all OSS Vulkan drivers. And XOrg could not do that, as the
> kernel uabi even blocks use of atomic drmSetClientCap(...ATOMIC...) for any
> process whose taskname starts with 'X', as a workaround for a modesetting-ddx
> with broken atomic implementation. So at least for (pun ahead) "X"
> applications, atomic modesetting is not an option.
If you ask for atomic v2 in the setclientcap ioctl you'll get atomic
even if you're X. The issue is no one's caring enough to fix it up
Xorg atomic support to make that happen.
And yes the vulkan drivers should attempt at least some atomic, the
reason for that was that amdgpu didn't have atomic back when the
original code was typed. Maybe it'll happen with more modifier use,
now that both amdgpu and i915 support them.
-Daniel
> For my use cases, X11/XOrg native is still the only display server capable
> enough to fulfill the needs, although I'm mixing in a bit of
> Vulkan/WSI/DirectDisplay for direct DRM/KMS access to work around some
> limitations, e.g., to get HDR or fp16 support.
>
>> But in general your patch should be correct too.
>> -Daniel
>>
>
> Thanks for the feedback. I rest my case.
> -mario
>
>>
>> >
>> > thanks,
>> > -mario
>> >
>> >> >
>> >> > -mario
>> >> >
>> >> > > DRM_DEBUG_KMS("Page flip is not allowed to change
>> >> > > frame buffer format.\n");
>> >> > > ret = -EINVAL;
>> >> > > goto out;
>>
Re: [PATCH] drm/msm: Fix MSM_INFO_GET_IOVA with carveout
On Thu, Jan 7, 2021 at 9:20 AM Rob Clark wrote:
>
> On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev
> wrote:
> >
> > The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
> > != NULL, because aspace is NULL when using vram carveout.
> >
> > Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
> > instances")
> >
> > Signed-off-by: Iskren Chernev
> > ---
> > drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index c5e61cb3356df..c1953fb079133 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device
> > *dev,
> > struct drm_file *file, struct drm_gem_object *obj,
> > uint64_t *iova)
> > {
> > + struct msm_drm_private *priv = dev->dev_private;
> > struct msm_file_private *ctx = file->driver_priv;
> >
> > - if (!ctx->aspace)
> > + if (!priv->gpu)
> > return -EINVAL;
>
> Does this actually work? It seems like you would hit a null ptr deref
> in msm_gem_init_vma().. and in general I think a lot of code paths
> would be surprised by a null address space, so this seems like a risky
> idea.
oh, actually, I suppose it is ok, since in the vram carveout case we
create the vma up front when the gem obj is created..
(still, it does seem a bit fragile.. and easy for folks testing on
devices not using vram carvout to break.. hmm..)
BR,
-R
> Maybe instead we should be creating an address space for the vram carveout?
>
> BR,
> -R
>
>
> > /*
> > --
> > 2.29.2
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Revert "drm/amd/display: Expose new CRC window property" and changes associated with this commit
On Thu, Jan 7, 2021 at 3:53 PM Rodrigo Siqueira wrote: > > Hi, > > A couple of weeks ago, Daniel highlighted [1] some issue related to a > patch entitle "drm/amd/display: Expose new CRC window property". After > discussion, we realize that we can revert that patch because we will > need to create a debugfs or full UAPI for CRC soon, which will make this > code obsolete. We got two other patches related to this same code; for > this reason, this patchset reverts all changes associated with that > specific commit. > > Cc: Wayne Lin > Cc: Alexander Deucher > Cc: Harry Wentland > Cc: Roman Li > Cc: Bindu R > Cc: Daniel Vetter Series is: Acked-by: Alex Deucher > > 1. https://www.spinics.net/lists/dri-devel/msg283767.html > > Thanks > > Rodrigo Siqueira (3): > Revert "drm/amd/display: Fix unused variable warning" > Revert "drm/amdgpu/disply: fix documentation warnings in display > manager" > Revert "drm/amd/display: Expose new CRC window property" > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 ++ > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 38 - > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +-- > .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 5 +- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 + > 5 files changed, 14 insertions(+), 229 deletions(-) > > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm/msm: drm-msm-fixes-2021-01-07
Hi Dave, A few misc fixes The following changes since commit e319a1b956f785f618611857cd946dca2bb68542: drm/msm: add IOMMU_SUPPORT dependency (2020-12-05 08:25:52 -0800) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-fixes-2021-01-07 for you to fetch changes up to 00fd44a1a4700718d5d962432b55c09820f7e709: drm/msm: Only enable A6xx LLCC code on A6xx (2021-01-07 09:23:05 -0800) Craig Tatlor (1): drm/msm: Call msm_init_vram before binding the gpu Iskren Chernev (3): drm/msm: Fix null dereference in _msm_gem_new drm/msm: Ensure get_pages is called when locked drm/msm: Add modparam to allow vram carveout Konrad Dybcio (1): drm/msm: Only enable A6xx LLCC code on A6xx Kuogee Hsieh (1): drm/msm/dp: postpone irq_hpd event during connection pending state Rob Clark (1): drm/msm: Fix WARN_ON() splat in _free_object() drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 6 -- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 6 -- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 6 -- drivers/gpu/drm/msm/adreno/adreno_device.c | 4 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 21 - drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 ++ drivers/gpu/drm/msm/dp/dp_display.c| 7 +++ drivers/gpu/drm/msm/dp/dp_panel.c | 12 +--- drivers/gpu/drm/msm/msm_drv.c | 8 drivers/gpu/drm/msm/msm_gem.c | 13 + 10 files changed, 63 insertions(+), 26 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse
On Thu, Jan 07, 2021 at 06:50:17PM +0100, Nirmoy Das wrote: > RX 5600 XT Pulse advertises support for BAR0 being 256MB, 512MB, > or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar > size quirk so that CPU can fully access the BAR0. This isn't quite accurate. The CPU can fully access BAR 0 no matter what. I think the problem you're solving is that without this quirk, BAR 0 isn't big enough to cover the VRAM. > Signed-off-by: Christian König > Reported-by: kernel test robot > Reported-by: Dan Carpenter IIRC, these Reported-by lines are from the "cap == 0x3f0" problem. It would make sense to include these if this patch fixed that problem in something that had already been merged. But this *hasn't* been merged, so these lines only make sense to someone who trawls through the mailing list to find the previous version. I don't really think it's worthwhile to include them. It's the same as giving credit to reviewers, which we typically don't do except via a Reviewed-by tag (which I think is too strong for this case) or a "v2" changes note after the "---" line. That doesn't get included in the git history, but is easily findable via the Link: tags as below. If you merge these via a non-PCI tree, please include the "Link:" lines in the PCI patches, e.g., Link: https://lore.kernel.org/r/20210107175017.15893-5-nirmoy@amd.com for this one. Obviously the link is different for each patch and will change if you repost the series. I'm not sure why you put the amd patch in the middle of the series. Seems like it would be slightly prettier and just as safe to put it at the end. > Signed-off-by: Nirmoy Das Acked-by: Bjorn Helgaas Let me know if you want me to take the series. > --- > drivers/pci/pci.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 16216186b51c..b061bbd4afb1 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, > int bar) > return 0; > > pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); > - return (cap & PCI_REBAR_CAP_SIZES) >> 4; > + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; > + > + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ > + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && > + bar == 0 && cap == 0x700) > + cap = 0x3f00; I think this is structured wrong. It should be like this so it's easier to match with the spec: cap &= PCI_REBAR_CAP_SIZES; if (... && cap == 0x7000) cap = 0x3f000; return cap >> 4; > + > + return cap; > } > EXPORT_SYMBOL(pci_rebar_get_possible_sizes); > > -- > 2.29.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] PCI: Export pci_rebar_get_possible_sizes()
On Thu, Jan 07, 2021 at 06:50:14PM +0100, Nirmoy Das wrote: > From: Darren Salt > > Export pci_rebar_get_possible_sizes() for use by modular drivers. > > Signed-off-by: Darren Salt > Signed-off-by: Nirmoy Das Acked-by: Bjorn Helgaas > --- > drivers/pci/pci.c | 1 + > drivers/pci/pci.h | 1 - > include/linux/pci.h | 1 + > 3 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index e578d34095e9..ef80ed451415 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -3579,6 +3579,7 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, > int bar) > pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); > return (cap & PCI_REBAR_CAP_SIZES) >> 4; > } > +EXPORT_SYMBOL(pci_rebar_get_possible_sizes); > > /** > * pci_rebar_get_current_size - get the current size of a BAR > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h > index f86cae9aa1f4..640ae7d74fc3 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -608,7 +608,6 @@ int acpi_get_rc_resources(struct device *dev, const char > *hid, u16 segment, > struct resource *res); > #endif > > -u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); > int pci_rebar_get_current_size(struct pci_dev *pdev, int bar); > int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size); > static inline u64 pci_rebar_size_to_bytes(int size) > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 22207a79762c..040cfad9 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1226,6 +1226,7 @@ void pci_update_resource(struct pci_dev *dev, int > resno); > int __must_check pci_assign_resource(struct pci_dev *dev, int i); > int __must_check pci_reassign_resource(struct pci_dev *dev, int i, > resource_size_t add_size, resource_size_t align); > void pci_release_resource(struct pci_dev *dev, int resno); > +u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); > int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size); > int pci_select_bars(struct pci_dev *dev, unsigned long flags); > bool pci_device_is_present(struct pci_dev *pdev); > -- > 2.29.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] PCI: Add pci_rebar_bytes_to_size()
On Thu, Jan 07, 2021 at 06:50:15PM +0100, Nirmoy Das wrote:
> Users of pci_resize_resource() need a way to calculate bar size
> from desired bytes. Add a helper function and export it so that
> modular drivers can use it.
s/bar/BAR/
> Signed-off-by: Darren Salt
> Signed-off-by: Christian König
> Signed-off-by: Nirmoy Das
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pci.c | 2 +-
> include/linux/pci.h | 6 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index ef80ed451415..16216186b51c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1648,7 +1648,7 @@ static void pci_restore_rebar_state(struct pci_dev
> *pdev)
> pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
> bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
> res = pdev->resource + bar_idx;
> - size = ilog2(resource_size(res)) - 20;
> + size = pci_rebar_bytes_to_size(resource_size(res));
> ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
> ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
> pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 040cfad9..77fed01523e0 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1226,6 +1226,12 @@ void pci_update_resource(struct pci_dev *dev, int
> resno);
> int __must_check pci_assign_resource(struct pci_dev *dev, int i);
> int __must_check pci_reassign_resource(struct pci_dev *dev, int i,
> resource_size_t add_size, resource_size_t align);
> void pci_release_resource(struct pci_dev *dev, int resno);
> +static inline int pci_rebar_bytes_to_size(u64 bytes)
> +{
> + bytes = roundup_pow_of_two(bytes);
> + return max(ilog2(bytes), 20) - 20;
This isn't returning a "size", is it? It looks like it's returning
the log2 of the number of MB the BAR will be, i.e., the encoding used
by the Resizable BAR Control register "BAR Size" field. Needs a brief
comment to that effect and/or a different function name.
> +}
> +
> u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
> int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
> int pci_select_bars(struct pci_dev *dev, unsigned long flags);
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] dma-buf: heaps: Rework heep allocation hooks to return struct dma_buf instead of fd
Every heap needs to create a dmabuf and then export it to a fd
via dma_buf_fd(), so to consolidate things a bit, have the heaps
just return a struct dmabuf * and let the top level
dma_heap_buffer_alloc() call handle creating the fd via
dma_buf_fd().
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 14 +-
drivers/dma-buf/heaps/cma_heap.c| 22 +++---
drivers/dma-buf/heaps/system_heap.c | 21 +++--
include/linux/dma-heap.h| 12 ++--
4 files changed, 33 insertions(+), 36 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..6b5db954569f 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -52,6 +52,9 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
size_t len,
unsigned int fd_flags,
unsigned int heap_flags)
{
+ struct dma_buf *dmabuf;
+ int fd;
+
/*
* Allocations from all heaps have to begin
* and end on page boundaries.
@@ -60,7 +63,16 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
size_t len,
if (!len)
return -EINVAL;
- return heap->ops->allocate(heap, len, fd_flags, heap_flags);
+ dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
+ if (IS_ERR(dmabuf))
+ return PTR_ERR(dmabuf);
+
+ fd = dma_buf_fd(dmabuf, fd_flags);
+ if (fd < 0) {
+ dma_buf_put(dmabuf);
+ /* just return, as put will call release and that will free */
+ }
+ return fd;
}
static int dma_heap_open(struct inode *inode, struct file *file)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 0c76cbc3fb11..985c41ffd85b 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -272,10 +272,10 @@ static const struct dma_buf_ops cma_heap_buf_ops = {
.release = cma_heap_dma_buf_release,
};
-static int cma_heap_allocate(struct dma_heap *heap,
- unsigned long len,
- unsigned long fd_flags,
- unsigned long heap_flags)
+static struct dma_buf *cma_heap_allocate(struct dma_heap *heap,
+unsigned long len,
+unsigned long fd_flags,
+unsigned long heap_flags)
{
struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
struct cma_heap_buffer *buffer;
@@ -290,7 +290,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
@@ -349,15 +349,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
ret = PTR_ERR(dmabuf);
goto free_pages;
}
-
- ret = dma_buf_fd(dmabuf, fd_flags);
- if (ret < 0) {
- dma_buf_put(dmabuf);
- /* just return, as put will call release and that will free */
- return ret;
- }
-
- return ret;
+ return dmabuf;
free_pages:
kfree(buffer->pages);
@@ -366,7 +358,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
free_buffer:
kfree(buffer);
- return ret;
+ return ERR_PTR(ret);
}
static const struct dma_heap_ops cma_heap_ops = {
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 2321c91891f6..7b154424aeb3 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -332,10 +332,10 @@ static struct page *alloc_largest_available(unsigned long
size,
return NULL;
}
-static int system_heap_allocate(struct dma_heap *heap,
- unsigned long len,
- unsigned long fd_flags,
- unsigned long heap_flags)
+static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
+ unsigned long len,
+ unsigned long fd_flags,
+ unsigned long heap_flags)
{
struct system_heap_buffer *buffer;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
@@ -350,7 +350,7 @@ static int system_heap_allocate(struct dma_heap *heap,
buffer = kzalloc(sizeof(*buffer),
[PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative
We shouldn't vunmap more then we vmap, but if we do, make
sure we complain loudly.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c| 1 +
drivers/dma-buf/heaps/system_heap.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 364fc2f3e499..0c76cbc3fb11 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -232,6 +232,7 @@ static void cma_heap_vunmap(struct dma_buf *dmabuf, struct
dma_buf_map *map)
struct cma_heap_buffer *buffer = dmabuf->priv;
mutex_lock(&buffer->lock);
+ WARN_ON(buffer->vmap_cnt == 0);
if (!--buffer->vmap_cnt) {
vunmap(buffer->vaddr);
buffer->vaddr = NULL;
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 405351aad2a8..2321c91891f6 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -273,6 +273,7 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
struct dma_buf_map *map)
struct system_heap_buffer *buffer = dmabuf->priv;
mutex_lock(&buffer->lock);
+ WARN_ON(buffer->vmap_cnt == 0);
if (!--buffer->vmap_cnt) {
vunmap(buffer->vaddr);
buffer->vaddr = NULL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dma-buf: system_heap: Make sure to return an error if we abort
If we abort from the allocation due to a fatal_signal_pending(),
be sure we report an error so any return code paths don't trip
over the fact that the allocation didn't succeed.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Suggested-by: Suren Baghdasaryan
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/system_heap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 17e0e9a68baf..405351aad2a8 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++ b/drivers/dma-buf/heaps/system_heap.c
@@ -363,8 +363,10 @@ static int system_heap_allocate(struct dma_heap *heap,
* Avoid trying to allocate memory if the process
* has been killed by SIGKILL
*/
- if (fatal_signal_pending(current))
+ if (fatal_signal_pending(current)) {
+ ret = -EINTR;
goto free_buffer;
+ }
page = alloc_largest_available(size_remaining, max_order);
if (!page)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: fix prime export for vram objects
commit 16845c5d5409 ("drm/virtio: implement blob resources: implement
vram object") and commit c6069a02fa55 ("drm/virtgpu: Set PRIME export
function in struct drm_gem_object_funcs") landed from different trees,
resulting in prime export never working for vram objects.
Cc: Gurchetan Singh
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_vram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vram.c
b/drivers/gpu/drm/virtio/virtgpu_vram.c
index d6f215c4ff8d..5cc34e7330fa 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vram.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vram.c
@@ -69,6 +69,7 @@ static const struct drm_gem_object_funcs
virtio_gpu_vram_funcs = {
.close = virtio_gpu_gem_object_close,
.free = virtio_gpu_vram_free,
.mmap = virtio_gpu_vram_mmap,
+ .export = virtgpu_gem_prime_export,
};
bool virtio_gpu_is_vram(struct virtio_gpu_object *bo)
--
2.29.2.729.g45daf8777d-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: make sure context is created in gem open
The context might still be missing when DRM_IOCTL_PRIME_FD_TO_HANDLE is
the first ioctl on the drm_file.
Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the
first 3D ioctl")
Cc: Gurchetan Singh
Cc: Gerd Hoffmann
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index c30c75ee83fc..8502400b2f9c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -39,9 +39,6 @@ static int virtio_gpu_gem_create(struct drm_file *file,
int ret;
u32 handle;
- if (vgdev->has_virgl_3d)
- virtio_gpu_create_context(dev, file);
-
ret = virtio_gpu_object_create(vgdev, params, &obj, NULL);
if (ret < 0)
return ret;
@@ -119,6 +116,11 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj,
if (!vgdev->has_virgl_3d)
goto out_notify;
+ /* the context might still be missing when the first ioctl is
+* DRM_IOCTL_MODE_CREATE_DUMB or DRM_IOCTL_PRIME_FD_TO_HANDLE
+*/
+ virtio_gpu_create_context(obj->dev, file);
+
objs = virtio_gpu_array_alloc(1);
if (!objs)
return -ENOMEM;
--
2.29.2.729.g45daf8777d-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] Revert "drm/amd/display: Expose new CRC window property"
This reverts commit 110d586ba77ed573eb7464ca69b6490ec0b70c5f.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 19 ---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 3 -
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +
5 files changed, 12 insertions(+), 210 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a06554745238..0515ed0d125c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -938,41 +938,6 @@ static void mmhub_read_system_context(struct amdgpu_device
*adev, struct dc_phy_
}
#endif
-#ifdef CONFIG_DEBUG_FS
-static int create_crtc_crc_properties(struct amdgpu_display_manager *dm)
-{
- dm->crc_win_x_start_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_X_START", 0, U16_MAX);
- if (!dm->crc_win_x_start_property)
- return -ENOMEM;
-
- dm->crc_win_y_start_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_Y_START", 0, U16_MAX);
- if (!dm->crc_win_y_start_property)
- return -ENOMEM;
-
- dm->crc_win_x_end_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_X_END", 0, U16_MAX);
- if (!dm->crc_win_x_end_property)
- return -ENOMEM;
-
- dm->crc_win_y_end_property =
- drm_property_create_range(adev_to_drm(dm->adev),
- DRM_MODE_PROP_ATOMIC,
- "AMD_CRC_WIN_Y_END", 0, U16_MAX);
- if (!dm->crc_win_y_end_property)
- return -ENOMEM;
-
- return 0;
-}
-#endif
-
static int amdgpu_dm_init(struct amdgpu_device *adev)
{
struct dc_init_data init_data;
@@ -1119,10 +1084,6 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
dc_init_callbacks(adev->dm.dc, &init_params);
}
-#endif
-#ifdef CONFIG_DEBUG_FS
- if (create_crtc_crc_properties(&adev->dm))
- DRM_ERROR("amdgpu: failed to create crc property.\n");
#endif
if (amdgpu_dm_initialize_drm_device(adev)) {
DRM_ERROR(
@@ -5456,64 +5417,12 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
state->crc_src = cur->crc_src;
state->cm_has_degamma = cur->cm_has_degamma;
state->cm_is_degamma_srgb = cur->cm_is_degamma_srgb;
-#ifdef CONFIG_DEBUG_FS
- state->crc_window = cur->crc_window;
-#endif
+
/* TODO Duplicate dc_stream after objects are stream object is
flattened */
return &state->base;
}
-#ifdef CONFIG_DEBUG_FS
-static int amdgpu_dm_crtc_atomic_set_property(struct drm_crtc *crtc,
- struct drm_crtc_state *crtc_state,
- struct drm_property *property,
- uint64_t val)
-{
- struct drm_device *dev = crtc->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
- struct dm_crtc_state *dm_new_state =
- to_dm_crtc_state(crtc_state);
-
- if (property == adev->dm.crc_win_x_start_property)
- dm_new_state->crc_window.x_start = val;
- else if (property == adev->dm.crc_win_y_start_property)
- dm_new_state->crc_window.y_start = val;
- else if (property == adev->dm.crc_win_x_end_property)
- dm_new_state->crc_window.x_end = val;
- else if (property == adev->dm.crc_win_y_end_property)
- dm_new_state->crc_window.y_end = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int amdgpu_dm_crtc_atomic_get_property(struct drm_crtc *crtc,
- const struct drm_crtc_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- struct drm_device *dev = crtc->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
- struct dm_crtc_state *dm_state =
- to_dm_crtc_state(state);
-
- if (property == adev->dm.crc_win_x_start_property)
- *val = dm_state->crc_window.x_start;
- else if (property == adev->dm.crc_win_y_start_property)
- *val = dm_state->crc_window.y_s
[PATCH 1/3] Revert "drm/amd/display: Fix unused variable warning"
This reverts commit b5d8f1d02ba7021cad1bd5ad8460ce5611c479d8.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 99c7f9eb44aa..a06554745238 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8549,7 +8549,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
manage_dm_interrupts(adev, acrtc, true);
}
- if (IS_ENABLED(CONFIG_DEBUG_FS) && new_crtc_state->active &&
+#ifdef CONFIG_DEBUG_FS
+ if (new_crtc_state->active &&
amdgpu_dm_is_valid_crc_source(dm_new_crtc_state->crc_src)) {
/**
* Frontend may have changed so reapply the CRC capture
@@ -8570,6 +8571,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
amdgpu_dm_crtc_configure_crc_source(
crtc, dm_new_crtc_state,
dm_new_crtc_state->crc_src);
}
+#endif
}
for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
index eba2f1d35d07..0235bfb246e5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h
@@ -46,13 +46,13 @@ static inline bool amdgpu_dm_is_valid_crc_source(enum
amdgpu_dm_pipe_crc_source
}
/* amdgpu_dm_crc.c */
+#ifdef CONFIG_DEBUG_FS
bool amdgpu_dm_crc_window_is_default(struct dm_crtc_state *dm_crtc_state);
bool amdgpu_dm_crc_window_changed(struct dm_crtc_state *dm_new_crtc_state,
struct dm_crtc_state
*dm_old_crtc_state);
int amdgpu_dm_crtc_configure_crc_source(struct drm_crtc *crtc,
struct dm_crtc_state *dm_crtc_state,
enum amdgpu_dm_pipe_crc_source source);
-#ifdef CONFIG_DEBUG_FS
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *src_name,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] Revert "drm/amdgpu/disply: fix documentation warnings in display manager"
This reverts commit 1206904465c8a9eebff9ca5a65effc8cf8f3cb84.
Cc: Wayne Lin
Cc: Alexander Deucher
Cc: Harry Wentland
Cc: Roman Li
Cc: Bindu R
Cc: Daniel Vetter
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 21 +--
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 27b32ce7b6c9..ef394e941d9d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -344,29 +344,10 @@ struct amdgpu_display_manager {
uint32_t active_vblank_irq_count;
#ifdef CONFIG_DEBUG_FS
- /**
-* @crc_win_x_start_property:
-*
-* X start of the crc calculation window
-*/
+ /* set the crc calculation window*/
struct drm_property *crc_win_x_start_property;
- /**
-* @crc_win_y_start_property:
-*
-* Y start of the crc calculation window
-*/
struct drm_property *crc_win_y_start_property;
- /**
-* @crc_win_x_end_property:
-*
-* X end of the crc calculation window
-*/
struct drm_property *crc_win_x_end_property;
- /**
-* @crc_win_y_end_property:
-*
-* Y end of the crc calculation window
-*/
struct drm_property *crc_win_y_end_property;
#endif
/**
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Revert "drm/amd/display: Expose new CRC window property" and changes associated with this commit
Hi, A couple of weeks ago, Daniel highlighted [1] some issue related to a patch entitle "drm/amd/display: Expose new CRC window property". After discussion, we realize that we can revert that patch because we will need to create a debugfs or full UAPI for CRC soon, which will make this code obsolete. We got two other patches related to this same code; for this reason, this patchset reverts all changes associated with that specific commit. Cc: Wayne Lin Cc: Alexander Deucher Cc: Harry Wentland Cc: Roman Li Cc: Bindu R Cc: Daniel Vetter 1. https://www.spinics.net/lists/dri-devel/msg283767.html Thanks Rodrigo Siqueira (3): Revert "drm/amd/display: Fix unused variable warning" Revert "drm/amdgpu/disply: fix documentation warnings in display manager" Revert "drm/amd/display: Expose new CRC window property" .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 142 ++ .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 38 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 56 +-- .../drm/amd/display/amdgpu_dm/amdgpu_dm_crc.h | 5 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 + 5 files changed, 14 insertions(+), 229 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: cma_heap: Fix memory leak in CMA heap
Bing Song noticed the CMA heap was leaking memory due to a flub
I made in commit a5d2d29e24be ("dma-buf: heaps: Move heap-helper
logic into the cma_heap implementation"), and provided this fix
which ensures the pagelist is also freed on release.
Cc: Bing Song
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reported-by: Bing Song
Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap
implementation")
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 3c4e34301172..364fc2f3e499 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -251,6 +251,9 @@ static void cma_heap_dma_buf_release(struct dma_buf *dmabuf)
buffer->vaddr = NULL;
}
+ /* free page list */
+ kfree(buffer->pages);
+ /* release memory */
cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount);
kfree(buffer);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
Am 07.01.21 um 19:07 schrieb Daniel Vetter:
On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
Drivers are not supposed to init the page pool directly any more.
Signed-off-by: Christian König
Please include reported-by credits and link to the bug reports on
lore.kernel.org when merging this. Also I guess this should have a Fixes:
line?
I'm not aware of a bug report, but the reported-by/Fixes lines are
indeed missing.
BTW: Any idea why dim add-link doesn't work?
And maybe some words on how/why stuff blows up.
Just a typo. I've forgot to remove two lines in radeon while rebasing
and still had the symbols exported so never noticed this.
Christian.
-Daniel
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d4328ff57757..35b715f82ed8 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
rdev->mman.initialized = true;
- ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
- dma_addressing_limited(&rdev->pdev->dev));
-
r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Thu, Jan 7, 2021 at 7:04 PM Daniel Vetter wrote:
> On Thu, Jan 7, 2021 at 7:00 PM Mario Kleiner
> wrote:
> >
> > On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> >>
> >> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
> >> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> >> > wrote:
> >> > >
> >> > > With modifiers one can actually have different format_info structs
> >> > > for the same format, which now matters for AMDGPU since we convert
> >> > > implicit modifiers to explicit modifiers with multiple planes.
> >> > >
> >> > > I checked other drivers and it doesn't look like they end up
> triggering
> >> > > this case so I think this is safe to relax.
> >> > >
> >> > > Signed-off-by: Bas Nieuwenhuizen
> >> > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> converted metadata.")
> >> > > ---
> >> > > drivers/gpu/drm/drm_plane.c | 2 +-
> >> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/drm_plane.c
> b/drivers/gpu/drm/drm_plane.c
> >> > > index e6231947f987..f5085990cfac 100644
> >> > > --- a/drivers/gpu/drm/drm_plane.c
> >> > > +++ b/drivers/gpu/drm/drm_plane.c
> >> > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct
> drm_device *dev,
> >> > > if (ret)
> >> > > goto out;
> >> > >
> >> > > - if (old_fb->format != fb->format) {
> >> > > + if (old_fb->format->format != fb->format->format) {
> >> >
> >> > This was btw. the original way before Ville made it more strict about
> >> > 4 years ago, to catch issues related to tiling, and more complex
> >> > layouts, like the dcc tiling/retiling introduced by your modifier
> >> > patches. That's why I hope my alternative patch is a good solution for
> >> > atomic drivers while keeping the strictness for potential legacy
> >> > drivers.
> >>
> >> Yeah this doesn't work in full generality, because hw might need to do a
> >> full modeset to do a full modeset to reallocate resources (like scanout
> >> fifo space) if the format changes.
> >>
> >> But for atomic drivers that should be caught in ->atomic_check, which
> >> should result in -EINVAL, so should do the right thing. So it should be
> >> all good, but imo needs a comment to explain what's going on:
> >>
> >> /*
> >> * Only check the FOURCC format code, excluding modifiers. This
> is
> >> * enough for all legacy drivers. Atomic drivers have their own
> >> * checks in their ->atomic_check implementation, which will
> >> * return -EINVAL if any hw or driver constraint is violated due
> >> * to modifier changes.
> >> */
> >>
> >> Also can you pls cc: intel-gfx to get this vetted by the intel-gfx ci?
> >>
> >> With that:
> >>
> >> Reviewed-by: Daniel Vetter
> >>
> >
> > Ah, my "atomic expert", posting simultaneously with myself :). Happy new
> year. Opinions on my variant, just replied a minute ago?
>
> Full disclosure, Ville wanted to do something similar since forever
> I'm not a huge fan of removing limitations of legacy ioctls. Worst
> case we break something, best case no gain in features since why don't
> you just use atomic. Since this (amdgpu modifiers) broke something we
> have to fix it, hence I'd go with the more minimal version from Bas
> here.
>
>
Fair point. Means though that somebody will have to convert many user-space
clients, e.g., all OSS Vulkan drivers. And XOrg could not do that, as the
kernel uabi even blocks use of atomic drmSetClientCap(...ATOMIC...) for any
process whose taskname starts with 'X', as a workaround for a
modesetting-ddx with broken atomic implementation. So at least for (pun
ahead) "X" applications, atomic modesetting is not an option.
For my use cases, X11/XOrg native is still the only display server capable
enough to fulfill the needs, although I'm mixing in a bit of
Vulkan/WSI/DirectDisplay for direct DRM/KMS access to work around some
limitations, e.g., to get HDR or fp16 support.
But in general your patch should be correct too.
> -Daniel
>
>
Thanks for the feedback. I rest my case.
-mario
> >
> > thanks,
> > -mario
> >
> >> >
> >> > -mario
> >> >
> >> > > DRM_DEBUG_KMS("Page flip is not allowed to change
> frame buffer format.\n");
> >> > > ret = -EINVAL;
> >> > > goto out;
> >> > > --
> >> > > 2.29.2
> >> > >
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Tue, Jan 05, 2021 at 07:23:08PM +0100, Christian König wrote:
> Drivers are not supposed to init the page pool directly any more.
>
> Signed-off-by: Christian König
Please include reported-by credits and link to the bug reports on
lore.kernel.org when merging this. Also I guess this should have a Fixes:
line?
And maybe some words on how/why stuff blows up.
-Daniel
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index d4328ff57757..35b715f82ed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> rdev->mman.initialized = true;
>
> - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
> - dma_addressing_limited(&rdev->pdev->dev));
> -
> r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Thu, Jan 7, 2021 at 7:00 PM Mario Kleiner wrote:
>
> On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
>>
>> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
>> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
>> > wrote:
>> > >
>> > > With modifiers one can actually have different format_info structs
>> > > for the same format, which now matters for AMDGPU since we convert
>> > > implicit modifiers to explicit modifiers with multiple planes.
>> > >
>> > > I checked other drivers and it doesn't look like they end up triggering
>> > > this case so I think this is safe to relax.
>> > >
>> > > Signed-off-by: Bas Nieuwenhuizen
>> > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
>> > > metadata.")
>> > > ---
>> > > drivers/gpu/drm/drm_plane.c | 2 +-
>> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>> > > index e6231947f987..f5085990cfac 100644
>> > > --- a/drivers/gpu/drm/drm_plane.c
>> > > +++ b/drivers/gpu/drm/drm_plane.c
>> > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device
>> > > *dev,
>> > > if (ret)
>> > > goto out;
>> > >
>> > > - if (old_fb->format != fb->format) {
>> > > + if (old_fb->format->format != fb->format->format) {
>> >
>> > This was btw. the original way before Ville made it more strict about
>> > 4 years ago, to catch issues related to tiling, and more complex
>> > layouts, like the dcc tiling/retiling introduced by your modifier
>> > patches. That's why I hope my alternative patch is a good solution for
>> > atomic drivers while keeping the strictness for potential legacy
>> > drivers.
>>
>> Yeah this doesn't work in full generality, because hw might need to do a
>> full modeset to do a full modeset to reallocate resources (like scanout
>> fifo space) if the format changes.
>>
>> But for atomic drivers that should be caught in ->atomic_check, which
>> should result in -EINVAL, so should do the right thing. So it should be
>> all good, but imo needs a comment to explain what's going on:
>>
>> /*
>> * Only check the FOURCC format code, excluding modifiers. This is
>> * enough for all legacy drivers. Atomic drivers have their own
>> * checks in their ->atomic_check implementation, which will
>> * return -EINVAL if any hw or driver constraint is violated due
>> * to modifier changes.
>> */
>>
>> Also can you pls cc: intel-gfx to get this vetted by the intel-gfx ci?
>>
>> With that:
>>
>> Reviewed-by: Daniel Vetter
>>
>
> Ah, my "atomic expert", posting simultaneously with myself :). Happy new
> year. Opinions on my variant, just replied a minute ago?
Full disclosure, Ville wanted to do something similar since forever
I'm not a huge fan of removing limitations of legacy ioctls. Worst
case we break something, best case no gain in features since why don't
you just use atomic. Since this (amdgpu modifiers) broke something we
have to fix it, hence I'd go with the more minimal version from Bas
here.
But in general your patch should be correct too.
-Daniel
>
> thanks,
> -mario
>
>> >
>> > -mario
>> >
>> > > DRM_DEBUG_KMS("Page flip is not allowed to change frame
>> > > buffer format.\n");
>> > > ret = -EINVAL;
>> > > goto out;
>> > > --
>> > > 2.29.2
>> > >
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Thu, Jan 7, 2021 at 6:57 PM Daniel Vetter wrote:
> On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
> > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> > wrote:
> > >
> > > With modifiers one can actually have different format_info structs
> > > for the same format, which now matters for AMDGPU since we convert
> > > implicit modifiers to explicit modifiers with multiple planes.
> > >
> > > I checked other drivers and it doesn't look like they end up triggering
> > > this case so I think this is safe to relax.
> > >
> > > Signed-off-by: Bas Nieuwenhuizen
> > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> converted metadata.")
> > > ---
> > > drivers/gpu/drm/drm_plane.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index e6231947f987..f5085990cfac 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device
> *dev,
> > > if (ret)
> > > goto out;
> > >
> > > - if (old_fb->format != fb->format) {
> > > + if (old_fb->format->format != fb->format->format) {
> >
> > This was btw. the original way before Ville made it more strict about
> > 4 years ago, to catch issues related to tiling, and more complex
> > layouts, like the dcc tiling/retiling introduced by your modifier
> > patches. That's why I hope my alternative patch is a good solution for
> > atomic drivers while keeping the strictness for potential legacy
> > drivers.
>
> Yeah this doesn't work in full generality, because hw might need to do a
> full modeset to do a full modeset to reallocate resources (like scanout
> fifo space) if the format changes.
>
> But for atomic drivers that should be caught in ->atomic_check, which
> should result in -EINVAL, so should do the right thing. So it should be
> all good, but imo needs a comment to explain what's going on:
>
> /*
> * Only check the FOURCC format code, excluding modifiers. This is
> * enough for all legacy drivers. Atomic drivers have their own
> * checks in their ->atomic_check implementation, which will
> * return -EINVAL if any hw or driver constraint is violated due
> * to modifier changes.
> */
>
> Also can you pls cc: intel-gfx to get this vetted by the intel-gfx ci?
>
> With that:
>
> Reviewed-by: Daniel Vetter
>
>
Ah, my "atomic expert", posting simultaneously with myself :). Happy new
year. Opinions on my variant, just replied a minute ago?
thanks,
-mario
>
> > -mario
> >
> > > DRM_DEBUG_KMS("Page flip is not allowed to change
> frame buffer format.\n");
> > > ret = -EINVAL;
> > > goto out;
> > > --
> > > 2.29.2
> > >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Thu, Jan 7, 2021 at 6:21 PM Liu, Zhan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> > -Original Message-
> > From: Liu, Zhan
> > Sent: 2021/January/06, Wednesday 10:04 AM
> > To: Bas Nieuwenhuizen ; Mario Kleiner
> >
> > Cc: dri-devel ; amd-gfx list > g...@lists.freedesktop.org>; Deucher, Alexander
> > ; Daniel Vetter ;
> > Kazlauskas, Nicholas ; Ville Syrjälä
> >
> > Subject: RE: [PATCH] drm: Check actual format for legacy pageflip.
> >
> >
> > > -Original Message-
> > > From: Liu, Zhan
> > > Sent: 2021/January/04, Monday 3:46 PM
> > > To: Bas Nieuwenhuizen ; Mario Kleiner
> > >
> > > Cc: dri-devel ; amd-gfx list > > g...@lists.freedesktop.org>; Deucher, Alexander
> > > ; Daniel Vetter ;
> > > Kazlauskas, Nicholas ; Ville Syrjälä
> > >
> > > Subject: Re: [PATCH] drm: Check actual format for legacy pageflip.
> > >
> > >
> > >
> > > + Ville
> > >
> > > On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner
> > >
> > > wrote:
> > > >
> > > > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> > > > wrote:
> > > > >
> > > > > With modifiers one can actually have different format_info structs
> > > > > for the same format, which now matters for AMDGPU since we convert
> > > > > implicit modifiers to explicit modifiers with multiple planes.
> > > > >
> > > > > I checked other drivers and it doesn't look like they end up
> > > > > triggering this case so I think this is safe to relax.
> > > > >
> > > > > Signed-off-by: Bas Nieuwenhuizen
> > > > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> > > > >converted metadata.")
> > > > > ---
> > > > > drivers/gpu/drm/drm_plane.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > > b/drivers/gpu/drm/drm_plane.c index e6231947f987..f5085990cfac
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct
> > > drm_device
> > > > >*dev,
> > > > > if (ret)
> > > > > goto out;
> > > > >
> > > > > - if (old_fb->format != fb->format) {
> > > > > + if (old_fb->format->format != fb->format->format) {
> > > >
> > >
> > > I agree with this patch, though considering the original way was made
> > > by Ville, I will wait for Ville's input first. Adding my "Acked-by"
here.
> > >
> > > This patch is:
> > > Acked-by: Zhan Liu
>
> Since there is no objection from the community on this patch over the
past few days, and this patch totally makes sense to me, this patch is:
>
> Reviewed-by: Zhan Liu
>
Well, there is my alternative one-line patch, which is equally simple and
solves the problem in a similar way that doesn't undo Ville's stricter
checks, but it doesn't seem to get any attention:
https://lists.freedesktop.org/archives/dri-devel/2021-January/292763.html
Mine keeps the check as strict as before for non-atomic drivers, but
removes the check for atomic drivers, given the assumption that they should
be able to do without it.
In the end both patches solve the problem in the short term, also
satisfying my (users) needs, and the future is unknown. But it would be
nice to get an opinion from an atomic expert which one is the more future
proof / elegant / final solution to stick to in the face of potential
future atomic kms drivers
With that said, i will add to Bas patch a
Reported-by: Mario Kleiner
Acked-by: Mario Kleiner
thanks,
-mario
> >
> > Ping...
> >
> > >
> > > > This was btw. the original way before Ville made it more strict
> > > > about
> > > > 4 years ago, to catch issues related to tiling, and more complex
> > > > layouts, like the dcc tiling/retiling introduced by your modifier
> > > > patches. That's why I hope my alternative patch is a good solution
> > > > for atomic drivers while keeping the strictness for potential legacy
> > > > drivers.
> > > >
> > > > -mario
> > > >
> > > > > DRM_DEBUG_KMS("Page flip is not allowed to change
> > > > >frame buffer format.\n");
> > > > > ret = -EINVAL;
> > > > > goto out;
> > > > > --
> > > > > 2.29.2
> > > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Check actual format for legacy pageflip.
On Sat, Jan 02, 2021 at 04:31:36PM +0100, Mario Kleiner wrote:
> On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> wrote:
> >
> > With modifiers one can actually have different format_info structs
> > for the same format, which now matters for AMDGPU since we convert
> > implicit modifiers to explicit modifiers with multiple planes.
> >
> > I checked other drivers and it doesn't look like they end up triggering
> > this case so I think this is safe to relax.
> >
> > Signed-off-by: Bas Nieuwenhuizen
> > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for converted
> > metadata.")
> > ---
> > drivers/gpu/drm/drm_plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index e6231947f987..f5085990cfac 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> > if (ret)
> > goto out;
> >
> > - if (old_fb->format != fb->format) {
> > + if (old_fb->format->format != fb->format->format) {
>
> This was btw. the original way before Ville made it more strict about
> 4 years ago, to catch issues related to tiling, and more complex
> layouts, like the dcc tiling/retiling introduced by your modifier
> patches. That's why I hope my alternative patch is a good solution for
> atomic drivers while keeping the strictness for potential legacy
> drivers.
Yeah this doesn't work in full generality, because hw might need to do a
full modeset to do a full modeset to reallocate resources (like scanout
fifo space) if the format changes.
But for atomic drivers that should be caught in ->atomic_check, which
should result in -EINVAL, so should do the right thing. So it should be
all good, but imo needs a comment to explain what's going on:
/*
* Only check the FOURCC format code, excluding modifiers. This is
* enough for all legacy drivers. Atomic drivers have their own
* checks in their ->atomic_check implementation, which will
* return -EINVAL if any hw or driver constraint is violated due
* to modifier changes.
*/
Also can you pls cc: intel-gfx to get this vetted by the intel-gfx ci?
With that:
Reviewed-by: Daniel Vetter
>
> -mario
>
> > DRM_DEBUG_KMS("Page flip is not allowed to change frame
> > buffer format.\n");
> > ret = -EINVAL;
> > goto out;
> > --
> > 2.29.2
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] PCI: Add a REBAR size quirk for Sapphire RX 5600 XT Pulse
RX 5600 XT Pulse advertises support for BAR0 being 256MB, 512MB, or 1GB, but it also supports 2GB, 4GB, and 8GB. Add a rebar size quirk so that CPU can fully access the BAR0. Signed-off-by: Christian König Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Nirmoy Das --- drivers/pci/pci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 16216186b51c..b061bbd4afb1 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) return 0; pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); - return (cap & PCI_REBAR_CAP_SIZES) >> 4; + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; + + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && + bar == 0 && cap == 0x700) + cap = 0x3f00; + + return cap; } EXPORT_SYMBOL(pci_rebar_get_possible_sizes); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/amdgpu: Resize BAR0 to the maximum available size, even if it doesn't cover VRAM
This allows BAR0 resizing to be done for cards which don't advertise
support for a size large enough to cover the VRAM but which do
advertise at least one size larger than the default. For example,
my RX 5600 XT, which advertises 256MB, 512MB and 1GB.
Signed-off-by: Darren Salt
Signed-off-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index dce0e66b2364..390f2cc13df7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1090,7 +1090,7 @@ void amdgpu_device_wb_free(struct amdgpu_device *adev,
u32 wb)
int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
{
u64 space_needed = roundup_pow_of_two(adev->gmc.real_vram_size);
- u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) - 1;
+ int rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
struct pci_bus *root;
struct resource *res;
unsigned i;
@@ -1121,6 +1121,10 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
if (!res)
return 0;
+ /* Limit the BAR size to what is available */
+ rbar_size = min(fls(pci_rebar_get_possible_sizes(adev->pdev, 0)) - 1,
+ rbar_size);
+
/* Disable memory decoding while we change the BAR addresses and size */
pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
pci_write_config_word(adev->pdev, PCI_COMMAND,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] PCI: Add pci_rebar_bytes_to_size()
Users of pci_resize_resource() need a way to calculate bar size
from desired bytes. Add a helper function and export it so that
modular drivers can use it.
Signed-off-by: Darren Salt
Signed-off-by: Christian König
Signed-off-by: Nirmoy Das
---
drivers/pci/pci.c | 2 +-
include/linux/pci.h | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ef80ed451415..16216186b51c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1648,7 +1648,7 @@ static void pci_restore_rebar_state(struct pci_dev *pdev)
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
res = pdev->resource + bar_idx;
- size = ilog2(resource_size(res)) - 20;
+ size = pci_rebar_bytes_to_size(resource_size(res));
ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 040cfad9..77fed01523e0 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1226,6 +1226,12 @@ void pci_update_resource(struct pci_dev *dev, int resno);
int __must_check pci_assign_resource(struct pci_dev *dev, int i);
int __must_check pci_reassign_resource(struct pci_dev *dev, int i,
resource_size_t add_size, resource_size_t align);
void pci_release_resource(struct pci_dev *dev, int resno);
+static inline int pci_rebar_bytes_to_size(u64 bytes)
+{
+ bytes = roundup_pow_of_two(bytes);
+ return max(ilog2(bytes), 20) - 20;
+}
+
u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
int pci_select_bars(struct pci_dev *dev, unsigned long flags);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] PCI: Export pci_rebar_get_possible_sizes()
From: Darren Salt Export pci_rebar_get_possible_sizes() for use by modular drivers. Signed-off-by: Darren Salt Signed-off-by: Nirmoy Das --- drivers/pci/pci.c | 1 + drivers/pci/pci.h | 1 - include/linux/pci.h | 1 + 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index e578d34095e9..ef80ed451415 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3579,6 +3579,7 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); return (cap & PCI_REBAR_CAP_SIZES) >> 4; } +EXPORT_SYMBOL(pci_rebar_get_possible_sizes); /** * pci_rebar_get_current_size - get the current size of a BAR diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index f86cae9aa1f4..640ae7d74fc3 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -608,7 +608,6 @@ int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment, struct resource *res); #endif -u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); int pci_rebar_get_current_size(struct pci_dev *pdev, int bar); int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size); static inline u64 pci_rebar_size_to_bytes(int size) diff --git a/include/linux/pci.h b/include/linux/pci.h index 22207a79762c..040cfad9 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1226,6 +1226,7 @@ void pci_update_resource(struct pci_dev *dev, int resno); int __must_check pci_assign_resource(struct pci_dev *dev, int i); int __must_check pci_reassign_resource(struct pci_dev *dev, int i, resource_size_t add_size, resource_size_t align); void pci_release_resource(struct pci_dev *dev, int resno); +u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size); int pci_select_bars(struct pci_dev *dev, unsigned long flags); bool pci_device_is_present(struct pci_dev *pdev); -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] A PCI quirk for resizable BAR 0 on Navi10
Hi Bjorn, I cleaned up the patch series[1] that Christian sent earlier to fix wrongly exported resizable bar capability dword by VBIOS of RX 5600 XT Pulse card. I didn't split #2 patch instead merged amdgpu changes of #2 patch to #3 patch and removed changes related to pci_rebar_size_to_bytes() as it isn't needed anymore. Apart from that I clean up rest of the patches as you suggested. Please let me know if I missed something. Regards, Nirmoy [1] https://www.spinics.net/lists/linux-pci/msg103422.html -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mipi-dbi: Switch to new kerneldoc syntax for named variable macro argument
On Fri, Jan 01, 2021 at 10:18:17PM +0100, Jonathan Neuschäfer wrote:
> The syntax without dots is available since commit 43756e347f21
> ("scripts/kernel-doc: Add support for named variable macro arguments").
>
> The same HTML output is produced with and without this patch.
>
> Signed-off-by: Jonathan Neuschäfer
Applied to drm-misc-next, thanks for your patch.
-Daniel
> ---
> include/drm/drm_mipi_dbi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
> index c2827ceaba0d2..f543d6e3e822c 100644
> --- a/include/drm/drm_mipi_dbi.h
> +++ b/include/drm/drm_mipi_dbi.h
> @@ -172,7 +172,7 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer
> *fb,
> * mipi_dbi_command - MIPI DCS command with optional parameter(s)
> * @dbi: MIPI DBI structure
> * @cmd: Command
> - * @seq...: Optional parameter(s)
> + * @seq: Optional parameter(s)
> *
> * Send MIPI DCS command to the controller. Use mipi_dbi_command_read() for
> * get/read.
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2] drm/amdgpu: Do not change amdgpu framebuffer format during page flip
> -Original Message- > From: Daniel Vetter > Sent: 2021/January/07, Thursday 12:33 PM > To: Koenig, Christian > Cc: Liu, Zhan ; amd-...@lists.freedesktop.org; Cornij, > Nikola ; Wang, Chao-kai (Stylon) > ; Wang, Chao-kai (Stylon) > ; dri-devel@lists.freedesktop.org; Kazlauskas, > Nicholas ; b...@basnieuwenhuizen.nl > Subject: Re: [PATCH v2] drm/amdgpu: Do not change amdgpu framebuffer > format during page flip > > On Sun, Jan 03, 2021 at 04:43:37PM +0100, Christian König wrote: > > Am 29.12.20 um 22:10 schrieb Zhan Liu: > > > [Why] > > > Driver cannot change amdgpu framebuffer (afb) format while doing > > > page flip. Force system doing so will cause ioctl error, and result > > > in breaking several functionalities including FreeSync. > > > > > > If afb format is forced to change during page flip, following > > > message will appear in dmesg.log: > > > > > > "[drm:drm_mode_page_flip_ioctl [drm]] Page flip is not allowed to > > > change frame buffer format." > > > > > > [How] > > > Do not change afb format while doing page flip. It is okay to check > > > whether afb format is valid here, however, forcing afb format change > > > shouldn't happen here. > > > > I don't think this we can do this. > > > > It is perfectly valid for a page flip to switch between linear and > > tiled formats on an I+A or A+A laptop. > > It is, but that's not the bug here. struct drm_framebuffer.format is supposed > to be invariant over the lifetime of a drm_fb object, you need to set it when > the fb is created and never change it afterwards. So the patch here isn't yet > the real deal. > > Also this means the implicit tiling information cannot be changed after a fb > is > created for a given bo, but we've discussed this at length and that limitation > should be all ok. > -Daniel Thank you Christian and Daniel for the input! Bas recently submitted an alternative patch ([PATCH] drm: Check actual format for legacy pageflip.) which addresses the same issue, and his patch makes more sense to me, so I will abandon my patch in this case. Thanks, Zhan > > > > > Christian. > > > > > > > > Signed-off-by: Zhan Liu > > > --- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > Thanks Nick and Bas. Here is my second patch for review. > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > > index a638709e9c92..8a12e27ff4ec 100644 > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > > @@ -832,7 +832,8 @@ static int convert_tiling_flags_to_modifier(struct > amdgpu_framebuffer *afb) > > > if (!format_info) > > > return -EINVAL; > > > - afb->base.format = format_info; > > > + if (!afb->base.format) > > > + afb->base.format = format_info; > > > } > > > } > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri- > devel&data=04%7C01%7C > > > zhan.liu%40amd.com%7Cda23e6e33a7e46dfc4e308d8b33242c8%7C3dd896 > 1fe4884e > > > 608e11a82d994e183d%7C0%7C0%7C637456375746425509%7CUnknown% > 7CTWFpbGZsb3 > > > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D%7 > > > C1000&sdata=5lCm4d6FHihfFHUf5mVym0O6lKmZHgR89%2F2Eqj2ojhg > %3D&r > > eserved=0 > > -- > Daniel Vetter > Software Engineer, Intel Corporation > https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ff > wll.ch%2F&data=04%7C01%7Czhan.liu%40amd.com%7Cda23e6e33a7e > 46dfc4e308d8b33242c8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7 > C0%7C637456375746425509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a > mp;sdata=44x858klbIcVeRtP%2BuJST2K3xuCLisjbfhV9rEQrzpA%3D&rese > rved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Do not change amdgpu framebuffer format during page flip
On Sun, Jan 03, 2021 at 04:43:37PM +0100, Christian König wrote: > Am 29.12.20 um 22:10 schrieb Zhan Liu: > > [Why] > > Driver cannot change amdgpu framebuffer (afb) format while doing > > page flip. Force system doing so will cause ioctl error, and result in > > breaking several functionalities including FreeSync. > > > > If afb format is forced to change during page flip, following message > > will appear in dmesg.log: > > > > "[drm:drm_mode_page_flip_ioctl [drm]] > > Page flip is not allowed to change frame buffer format." > > > > [How] > > Do not change afb format while doing page flip. It is okay to check > > whether afb format is valid here, however, forcing afb format change > > shouldn't happen here. > > I don't think this we can do this. > > It is perfectly valid for a page flip to switch between linear and tiled > formats on an I+A or A+A laptop. It is, but that's not the bug here. struct drm_framebuffer.format is supposed to be invariant over the lifetime of a drm_fb object, you need to set it when the fb is created and never change it afterwards. So the patch here isn't yet the real deal. Also this means the implicit tiling information cannot be changed after a fb is created for a given bo, but we've discussed this at length and that limitation should be all ok. -Daniel > > Christian. > > > > > Signed-off-by: Zhan Liu > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > Thanks Nick and Bas. Here is my second patch for review. > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > index a638709e9c92..8a12e27ff4ec 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c > > @@ -832,7 +832,8 @@ static int convert_tiling_flags_to_modifier(struct > > amdgpu_framebuffer *afb) > > if (!format_info) > > return -EINVAL; > > - afb->base.format = format_info; > > + if (!afb->base.format) > > + afb->base.format = format_info; > > } > > } > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
On Wed, Jan 6, 2021 at 8:50 PM Sai Prakash Ranjan
wrote:
>
> On 2021-01-05 01:00, Konrad Dybcio wrote:
> > Using this code on A5xx (and probably older too) causes a
> > smmu bug.
> >
> > Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system
> > cache(LLC)")
> > Signed-off-by: Konrad Dybcio
> > Tested-by: AngeloGioacchino Del Regno
> >
> > ---
>
> Reviewed-by: Sai Prakash Ranjan
>
> > drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 -
> > drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
> > 2 files changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > index 6cf9975e951e..f09175698827 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> > @@ -191,8 +191,6 @@ adreno_iommu_create_address_space(struct msm_gpu
> > *gpu,
> > struct platform_device *pdev)
> > {
> > struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> > - struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> > - struct io_pgtable_domain_attr pgtbl_cfg;
> > struct iommu_domain *iommu;
> > struct msm_mmu *mmu;
> > struct msm_gem_address_space *aspace;
> > @@ -202,13 +200,18 @@ adreno_iommu_create_address_space(struct msm_gpu
> > *gpu,
> > if (!iommu)
> > return NULL;
> >
> > - /*
> > - * This allows GPU to set the bus attributes required to use system
> > - * cache on behalf of the iommu page table walker.
> > - */
> > - if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
> > - pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
> > - iommu_domain_set_attr(iommu, DOMAIN_ATTR_IO_PGTABLE_CFG,
> > &pgtbl_cfg);
> > +
> > + if (adreno_is_a6xx(adreno_gpu)) {
> > + struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
> > + struct io_pgtable_domain_attr pgtbl_cfg;
> > + /*
> > + * This allows GPU to set the bus attributes required to use
> > system
> > + * cache on behalf of the iommu page table walker.
> > + */
> > + if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
> > + pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
> > + iommu_domain_set_attr(iommu,
> > DOMAIN_ATTR_IO_PGTABLE_CFG,
> > &pgtbl_cfg);
> > + }
I'm applying for -fixes as this is an obvious problem.. But kinda
thinking that we should try to move it into an a6xx specific
create_address_space() (or wrapper for the generic fxn)
Sai/Jordan, could I talk one of you into trying to clean this up
better for next cycle?
BR,
-R
> > }
> >
> > mmu = msm_iommu_new(&pdev->dev, iommu);
> > diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > index 4574d85c5680..08421fa54a50 100644
> > --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> > @@ -226,6 +226,11 @@ static inline int adreno_is_a540(struct adreno_gpu
> > *gpu)
> > return gpu->revn == 540;
> > }
> >
> > +static inline bool adreno_is_a6xx(struct adreno_gpu *gpu)
> > +{
> > + return ((gpu->revn < 700 && gpu->revn > 599));
> > +}
> > +
> > static inline int adreno_is_a618(struct adreno_gpu *gpu)
> > {
> > return gpu->revn == 618;
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm: Check actual format for legacy pageflip.
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Liu, Zhan
> Sent: 2021/January/06, Wednesday 10:04 AM
> To: Bas Nieuwenhuizen ; Mario Kleiner
>
> Cc: dri-devel ; amd-gfx list g...@lists.freedesktop.org>; Deucher, Alexander
> ; Daniel Vetter ;
> Kazlauskas, Nicholas ; Ville Syrjälä
>
> Subject: RE: [PATCH] drm: Check actual format for legacy pageflip.
>
>
> > -Original Message-
> > From: Liu, Zhan
> > Sent: 2021/January/04, Monday 3:46 PM
> > To: Bas Nieuwenhuizen ; Mario Kleiner
> >
> > Cc: dri-devel ; amd-gfx list > g...@lists.freedesktop.org>; Deucher, Alexander
> > ; Daniel Vetter ;
> > Kazlauskas, Nicholas ; Ville Syrjälä
> >
> > Subject: Re: [PATCH] drm: Check actual format for legacy pageflip.
> >
> >
> >
> > + Ville
> >
> > On Sat, Jan 2, 2021 at 4:31 PM Mario Kleiner
> >
> > wrote:
> > >
> > > On Sat, Jan 2, 2021 at 3:02 PM Bas Nieuwenhuizen
> > > wrote:
> > > >
> > > > With modifiers one can actually have different format_info structs
> > > > for the same format, which now matters for AMDGPU since we convert
> > > > implicit modifiers to explicit modifiers with multiple planes.
> > > >
> > > > I checked other drivers and it doesn't look like they end up
> > > > triggering this case so I think this is safe to relax.
> > > >
> > > > Signed-off-by: Bas Nieuwenhuizen
> > > > Fixes: 816853f9dc40 ("drm/amd/display: Set new format info for
> > > >converted metadata.")
> > > > ---
> > > > drivers/gpu/drm/drm_plane.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > b/drivers/gpu/drm/drm_plane.c index e6231947f987..f5085990cfac
> > > > 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -1163,7 +1163,7 @@ int drm_mode_page_flip_ioctl(struct
> > drm_device
> > > >*dev,
> > > > if (ret)
> > > > goto out;
> > > >
> > > > - if (old_fb->format != fb->format) {
> > > > + if (old_fb->format->format != fb->format->format) {
> > >
> >
> > I agree with this patch, though considering the original way was made
> > by Ville, I will wait for Ville's input first. Adding my "Acked-by" here.
> >
> > This patch is:
> > Acked-by: Zhan Liu
Since there is no objection from the community on this patch over the past few
days, and this patch totally makes sense to me, this patch is:
Reviewed-by: Zhan Liu
>
> Ping...
>
> >
> > > This was btw. the original way before Ville made it more strict
> > > about
> > > 4 years ago, to catch issues related to tiling, and more complex
> > > layouts, like the dcc tiling/retiling introduced by your modifier
> > > patches. That's why I hope my alternative patch is a good solution
> > > for atomic drivers while keeping the strictness for potential legacy
> > > drivers.
> > >
> > > -mario
> > >
> > > > DRM_DEBUG_KMS("Page flip is not allowed to change
> > > >frame buffer format.\n");
> > > > ret = -EINVAL;
> > > > goto out;
> > > > --
> > > > 2.29.2
> > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Fix MSM_INFO_GET_IOVA with carveout
On Sat, Jan 2, 2021 at 12:26 PM Iskren Chernev wrote:
>
> The msm_gem_get_iova should be guarded with gpu != NULL and not aspace
> != NULL, because aspace is NULL when using vram carveout.
>
> Fixes: 933415e24bd0d ("drm/msm: Add support for private address space
> instances")
>
> Signed-off-by: Iskren Chernev
> ---
> drivers/gpu/drm/msm/msm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c5e61cb3356df..c1953fb079133 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -775,9 +775,10 @@ static int msm_ioctl_gem_info_iova(struct drm_device
> *dev,
> struct drm_file *file, struct drm_gem_object *obj,
> uint64_t *iova)
> {
> + struct msm_drm_private *priv = dev->dev_private;
> struct msm_file_private *ctx = file->driver_priv;
>
> - if (!ctx->aspace)
> + if (!priv->gpu)
> return -EINVAL;
Does this actually work? It seems like you would hit a null ptr deref
in msm_gem_init_vma().. and in general I think a lot of code paths
would be surprised by a null address space, so this seems like a risky
idea.
Maybe instead we should be creating an address space for the vram carveout?
BR,
-R
> /*
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: simplefb: Fix info message during probe
Hi Hans, On Tue, Dec 29, 2020 at 02:02:30PM +0100, Hans de Goede wrote: > Hi, > > On 12/28/20 7:39 PM, Peter Robinson wrote: > > The info message was showing the mapped address for the framebuffer. To > > avoid > > security problems, all virtual addresses are converted to __ptrval__, so > > the message has pointless information: > > > > simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, > > 0x12c000 bytes, mapped to 0x(ptrval) > > > > Drop the extraneous bits to clean up the message: > > > > simple-framebuffer 3ea9b000.framebuffer: framebuffer at 0x3ea9b000, > > 0x12c000 bytes > > > > Signed-off-by: Peter Robinson > > Thanks, patch looks good to me: > > Reviewed-by: Hans de Goede Since you have commit rights for drm-misc I'm assuming you're also going to push this one? Thanks, Daniel > > Regards, > > Hans > > > --- > > drivers/video/fbdev/simplefb.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c > > index 533a047d07a2..62f0ded70681 100644 > > --- a/drivers/video/fbdev/simplefb.c > > +++ b/drivers/video/fbdev/simplefb.c > > @@ -477,9 +477,8 @@ static int simplefb_probe(struct platform_device *pdev) > > simplefb_clocks_enable(par, pdev); > > simplefb_regulators_enable(par, pdev); > > > > - dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes, mapped to > > 0x%p\n", > > -info->fix.smem_start, info->fix.smem_len, > > -info->screen_base); > > + dev_info(&pdev->dev, "framebuffer at 0x%lx, 0x%x bytes\n", > > +info->fix.smem_start, info->fix.smem_len); > > dev_info(&pdev->dev, "format=%s, mode=%dx%dx%d, linelength=%d\n", > > params.format->name, > > info->var.xres, info->var.yres, > > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/qxl: Use managed mode-config init
On Mon, Dec 28, 2020 at 07:04:41PM +0800, Tian Tao wrote:
> Using drmm_mode_config_init() sets up managed release of modesetting
> resources.
>
> Signed-off-by: Tian Tao
This changes the order of the cleanup actions, so most likely will break
really badly. You can only move a cleanup action safely over to drmm_ if
it is the last thing (at the time the patch is applied) done before
cleanup is finished. There's a _lot_ of code that's run after
qxl_modeset_fini.
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 012bce0..38d6b59 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -1195,7 +1195,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
> int i;
> int ret;
>
> - drm_mode_config_init(&qdev->ddev);
> + ret = drmm_mode_config_init(&qdev->ddev);
> + if (ret)
> + return ret;
>
> ret = qxl_create_monitors_object(qdev);
> if (ret)
> @@ -1228,5 +1230,4 @@ int qxl_modeset_init(struct qxl_device *qdev)
> void qxl_modeset_fini(struct qxl_device *qdev)
> {
> qxl_destroy_monitors_object(qdev);
> - drm_mode_config_cleanup(&qdev->ddev);
> }
> --
> 2.7.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pci: Use pcim_enable_device()
On Mon, Dec 28, 2020 at 06:39:56PM +0800, Tian Tao wrote: > Using the managed function simplifies the error handling. After > unloading the driver, the PCI device should now get disabled as > well. > > Signed-off-by: Tian Tao We cant do this in core code because it changes the order of how the cleanup code is done. Also this is legacy code, pls don't touch that, not worth the effort :-) -Daniel > --- > drivers/gpu/drm/drm_pci.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c > index 6dba4b8..0616172 100644 > --- a/drivers/gpu/drm/drm_pci.c > +++ b/drivers/gpu/drm/drm_pci.c > @@ -207,7 +207,7 @@ static int drm_get_pci_dev(struct pci_dev *pdev, > if (IS_ERR(dev)) > return PTR_ERR(dev); > > - ret = pci_enable_device(pdev); > + ret = pcim_enable_device(pdev); > if (ret) > goto err_free; > > @@ -234,7 +234,6 @@ static int drm_get_pci_dev(struct pci_dev *pdev, > > err_agp: > drm_pci_agp_destroy(dev); > - pci_disable_device(pdev); > err_free: > drm_dev_put(dev); > return ret; > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/35] drm/amdgpu: svm bo enable_signal call condition
Am 2021-01-07 um 11:28 a.m. schrieb Christian König:
> Am 07.01.21 um 17:16 schrieb Felix Kuehling:
>> Am 2021-01-07 um 5:56 a.m. schrieb Christian König:
>>
>>> Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Alex Sierra
[why]
To support svm bo eviction mechanism.
[how]
If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
enable_signal callback will be called inside amdgpu_evict_flags.
This also causes gutting of the BO by removing all placements,
so that TTM won't actually do an eviction. Instead it will discard
the memory held by the BO. This is needed for HMM migration to user
mode system memory pages.
>>> I don't think that this will work. What exactly are you doing here?
>> We discussed this a while ago when we talked about pipelined gutting.
>> And you actually helped us out with a fix for that
>> (https://patchwork.freedesktop.org/patch/379039/).
>
> That's not what I meant. The pipelined gutting is ok, but why the
> enable_signaling()?
That's what triggers our eviction fence callback
amdkfd_fence_enable_signaling that schedules the worker doing the
eviction. Without pipelined gutting we'd be getting that callback from
the GPU scheduler when it tries to execute the job that does the
migration. With pipelined gutting we have to call this somewhere ourselves.
I guess we could schedule the eviction worker directly without going
through the fence callback. I think we did it this way because it's more
similar to our KFD BO eviction handling where the worker gets scheduled
by the fence callback.
Regards,
Felix
>
> Christian.
>
>>
>> SVM BOs are BOs in VRAM containing data for HMM ranges. When such a BO
>> is evicted by TTM, we do an HMM migration of the data to system memory
>> (triggered by kgd2kfd_schedule_evict_and_restore_process in patch 30).
>> That means we don't need TTM to copy the BO contents to GTT any more.
>> Instead we want to use pipelined gutting to allow the VRAM to be freed
>> once the fence signals that the HMM migration is done (the
>> dma_fence_signal call near the end of svm_range_evict_svm_bo_worker in
>> patch 28).
>>
>> Regards,
>> Felix
>>
>>
>>> As Daniel pointed out HMM and dma_fences are fundamentally
>>> incompatible.
>>>
>>> Christian.
>>>
Signed-off-by: Alex Sierra
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f423f42cb9b5..62d4da95d22d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -107,6 +107,20 @@ static void amdgpu_evict_flags(struct
ttm_buffer_object *bo,
}
abo = ttm_to_amdgpu_bo(bo);
+ if (abo->flags & AMDGPU_AMDKFD_CREATE_SVM_BO) {
+ struct dma_fence *fence;
+ struct dma_resv *resv = &bo->base._resv;
+
+ rcu_read_lock();
+ fence = rcu_dereference(resv->fence_excl);
+ if (fence && !fence->ops->signaled)
+ dma_fence_enable_sw_signaling(fence);
+
+ placement->num_placement = 0;
+ placement->num_busy_placement = 0;
+ rcu_read_unlock();
+ return;
+ }
switch (bo->mem.mem_type) {
case AMDGPU_PL_GDS:
case AMDGPU_PL_GWS:
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.12] R-Car DU and misc other changes
On Tue, Jan 05, 2021 at 07:41:52AM +0200, Laurent Pinchart wrote: > Hi Dave and Daniel, > > The following changes since commit 5b2fc08c455bbf749489254a81baeffdf4c0a693: > > Merge tag 'amd-drm-fixes-5.11-2020-12-23' of > git://people.freedesktop.org/~agd5f/linux into drm-next (2020-12-24 10:31:16 > +1000) > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git tags/du-next-20210105 > > for you to fetch changes up to 3fc5a284213d5fca1c0807ea8725355d39808930: > > drm: bridge: adv7511: Remove redundant null check before > clk_disable_unprepare (2021-01-05 07:20:42 +0200) > > > - Add default modes for connectors in unknown state > - R-Car DU conversion to DRM-managed API Pulled, and also pulled the new drmm_ helper from imx, which means you can now convert over to these. Thanks, Daniel > - R-Car DU miscellaneous fixes > - Miscellaneous bridge and bridge bindings fixes > - Assorted misc driver cleanups > - Constify drm_driver for PCI devices > > > Fabrizio Castro (1): > dt-bindings: display: bridge: renesas,lvds: RZ/G2E needs > renesas,companion too > > Laurent Pinchart (20): > dt-bindings: display: bridge: thc63lvd1024: Document dual-output mode > drm: Add default modes for connectors in unknown state > drm: rcar-du: Fix crash when using LVDS1 clock for CRTC > drm: rcar-du: Release vsp device reference in all error paths > drm: rcar-du: Drop unneeded encoder cleanup in error path > drm: rcar-du: Use DRM-managed allocation for VSP planes > drm: rcar-du: Use DRM-managed allocation for encoders > drm: rcar-du: Embed drm_device in rcar_du_device > drm: rcar-du: Replace dev_private with container_of > drm: rcar-du: Skip encoder allocation for LVDS1 in dual-link mode > drm: rcar-du: Drop local encoder variable > drm: rcar-du: Fix leak of CMM platform device reference > drm: arc: Remove unnecessary drm_plane_cleanup() wrapper > drm: sti: Remove unnecessary drm_plane_cleanup() wrapper > drm: vc4: Remove unnecessary drm_plane_cleanup() wrapper > drm: zte: Remove unnecessary drm_plane_cleanup() wrapper > drm: Don't export the drm_gem_dumb_destroy() function > drm: Move legacy device list out of drm_driver > drm: Use a const drm_driver for legacy PCI devices > drm: Constify drm_driver in drivers that don't modify it > > Mark Brown (1): > drm/bridge: thc63lvd1024: Fix regulator_get_optional() misuse > > Qinglang Miao (1): > drm: rcar-du: Fix PM reference leak in rcar_cmm_enable() > > Wang Xiaojun (1): > drm: rcar-du: Fix the return check of of_parse_phandle and > of_find_device_by_node > > Xu Wang (2): > drm: bridge: dw-hdmi: Remove redundant null check before > clk_disable_unprepare > drm: bridge: adv7511: Remove redundant null check before > clk_disable_unprepare > > .../bindings/display/bridge/renesas,lvds.yaml | 6 +- > .../display/bridge/thine,thc63lvd1024.yaml | 16 ++-- > drivers/gpu/drm/arc/arcpgu_crtc.c | 9 +- > drivers/gpu/drm/arc/arcpgu_drv.c | 2 +- > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 +- > drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +- > drivers/gpu/drm/drm_drv.c | 4 - > drivers/gpu/drm/drm_dumb_buffers.c | 8 +- > drivers/gpu/drm/drm_gem.c | 12 +-- > drivers/gpu/drm/drm_internal.h | 3 + > drivers/gpu/drm/drm_pci.c | 33 +--- > drivers/gpu/drm/drm_probe_helper.c | 3 +- > drivers/gpu/drm/kmb/kmb_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_cmm.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 12 +-- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 33 +++- > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 16 ++-- > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 98 > +++--- > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 - > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 42 +++--- > drivers/gpu/drm/rcar-du/rcar_du_plane.c| 8 +- > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 28 +-- > drivers/gpu/drm/rcar-du/rcar_du_writeback.c| 2 +- > drivers/gpu/drm/sti/sti_cursor.c | 9 +- > drivers/gpu/drm/sti/sti_gdp.c | 9 +- > drivers/gpu/drm/sti/sti_hqvdp.c| 9 +- > drivers/gpu/drm/tdfx/tdfx_drv.c| 2 +- > drivers/gpu/drm/vc4/vc4_plane.c| 7 +- > drivers/gpu/drm/zte/zx_plane.c | 7 +- > include/drm/drm_device.h
Re: [PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit
On Thu, Jan 07, 2021 at 01:49:45PM +0100, Christian König wrote:
> Am 22.12.20 um 14:51 schrieb Daniel Vetter:
> > On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wrote:
> > > Only initialize the DMA coherent pools if they are used.
> > >
> > > Signed-off-by: Christian König
> > Ah, just realized the answer to my question on patch 2: The pools are
> > per-device, due to dma_alloc_coherent being per-device (but really mostly
> > it isn't, but that's what we have to deal with fighting the dma-api
> > abstraction).
> >
> > I think this would make a lot more sense if the shrinkers are per-pool
> > (and also most of the debugfs files), since as-is in a multi-gpu system
> > the first gpu's pool gets preferrentially thrashed. Which isn't a nice
> > design. Splitting that into per gpu shrinkers means we get equal shrinking
> > without having to maintain a global lru. This is how xfs seems to set up
> > their shrinkers, and in general xfs people have a solid understanding of
> > this stuff.
>
> Well fairness and not trashing the first GPUs pool is the reason why I
> implemented just one shrinker plus a global LRU.
That's kinda defeating the point of how the core mm works. At least of how
I'm understanding how it works. Imo we shouldn't try to re-implement this
kind of balancing across different pools in our callback, since core mm
tries pretty hard to equally shrink already (it only shrinks each shrinker
a little bit each round, but does a lot of rounds under memory pressure).
Also maintaining your own global lru means global locking for the usual
case of none-to-little memory contention, unecessarily wasting the fast
path.
> In other words shrink_slab() just uses list_for_each_entry() on all
> shrinkers.
>
> In the pool shrinker callback shrink one pool and move it to the end of the
> shrinker list.
>
> >
> > Aside: I think it also would make tons of sense to split up your new ttm
> > bo shrinker up into a per-device lru, and throw the global system memory
> > lru out the window completely :-) Assuming we can indeed get rid of it,
> > and vmwgfx doesn't need it somewhere still.
>
> Yeah, I already have that as a patch set here, but I have this dependent on
> a larger rename of the device structures.
Hm maybe include that in the next round, just for the bigger picture?
Don't have to merge it all in one go, just want to make sure we agree on
where we're going.
> > Aside from this lgtm, but I guess will change a bit with that shuffling.
>
> Thanks for the review, going to send out a new version with the
> fs_reclaim_acquire/release added in a minute.
Cool.
Cheers, Daniel
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
> > > 1 file changed, 16 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> > > b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index 1cdacd58753a..f09e34614226 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -504,10 +504,12 @@ void ttm_pool_init(struct ttm_pool *pool, struct
> > > device *dev,
> > > pool->use_dma_alloc = use_dma_alloc;
> > > pool->use_dma32 = use_dma32;
> > > - for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > - for (j = 0; j < MAX_ORDER; ++j)
> > > - ttm_pool_type_init(&pool->caching[i].orders[j],
> > > -pool, i, j);
> > > + if (use_dma_alloc) {
> > > + for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > + for (j = 0; j < MAX_ORDER; ++j)
> > > + ttm_pool_type_init(&pool->caching[i].orders[j],
> > > +pool, i, j);
> > > + }
> > > }
> > > EXPORT_SYMBOL(ttm_pool_init);
> > > @@ -523,9 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > > {
> > > unsigned int i, j;
> > > - for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > - for (j = 0; j < MAX_ORDER; ++j)
> > > - ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > > + if (pool->use_dma_alloc) {
> > > + for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > + for (j = 0; j < MAX_ORDER; ++j)
> > > + ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > > + }
> > > }
> > > EXPORT_SYMBOL(ttm_pool_fini);
> > > @@ -630,6 +634,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct
> > > seq_file *m)
> > > {
> > > unsigned int i;
> > > + if (!pool->use_dma_alloc) {
> > > + seq_puts(m, "unused\n");
> > > + return 0;
> > > + }
> > > +
> > > ttm_pool_debugfs_header(m);
> > > spin_lock(&shrinker_lock);
> > > --
> > > 2.25.1
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On 1/7/21 11:30 AM, Daniel Vetter wrote:
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link them together
so they are freed when the device is finally reaped?
For sure better to optimize and allocate on demand when we reach
this corner case, but why the linking ?
Shouldn't drm_prime_gem_destroy be good enough place to free ?
I want to avoid keeping the page in the GEM object.
What we can do is to allocate a page on demand for each fault and link
the together in the bdev instead.
And when the bdev is then finally destroyed after the last application
closed we can finally release all of them.
Christian.
Hey, started to implement this and then realized that by allocating a page
for each fault indiscriminately
we will be allocating a new page for each faulting virtual address within a
VA range belonging the same BO
and this is obviously too much and not the intention. Should I instead use
let's say a hashtable with the hash
key being faulting BO address to actually keep allocating and reusing same
dummy zero page per GEM BO
(or for that matter DRM file object address for non imported BOs) ?
Why do we need a hashtable? All the sw structures to track this should
still be around:
- if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf,
so defensively allocate a per-bo page
- otherwise allocate a per-file page
That exactly what we have in current implementation
Or is the idea to save the struct page * pointer? That feels a bit like
over-optimizing stuff. Better to have a simple implementation first and
then tune it if (and only if) any part of it becomes a problem for normal
usage.
Exactly - the idea is to avoid adding extra pointer to drm_gem_object,
Christian suggested to instead keep a linked list of dummy pages to be
allocated on demand once we hit a vm_fault. I will then also prefault the entire
VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them
to that single dummy page.
This strongly feels like premature optimization. If you're worried about
the overhead on amdgpu, pay down the debt by removing one of the redundant
pointers between gem and ttm bo structs (I think we still have some) :-)
Until we've nuked these easy&obvious ones we shouldn't play "avoid 1
pointer just because" games with hashtables.
-Daniel
Well, if you and Christian can agree on this approach and suggest maybe what
pointer is
redundant and can be removed from GEM struct so we can use the 'credit' to add
the dummy page
to GEM I will be happy to follow through.
P.S Hash table is off the table anyway and we are talking only about linked list
here since by prefaulting
the entire VA range for a vmf->vma i will be avoiding redundant page faults to
same VMA VA range and so
don't need to search and reuse an existing dummy page but simply create a new
one for each next fault.
Andrey
Andrey
-Daniel
Andrey
Andrey
Regards,
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..ff3d39f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
+ file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!file->dummy_page) {
+ ret = -ENOMEM;
+ goto out_prime_destroy;
+ }
+
return file;
out_prime_destroy:
@@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
+ __free_page(file->dummy_page);
+
drm_prime_destroy_file_private(&file->prime);
WARN_ON(!list_empty(&file->event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7..987b45c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
ret = drm_prime_add_buf_handle(&file_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!obj->dummy_page)
+
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On Thu, Jan 07, 2021 at 11:26:52AM -0500, Andrey Grodzovsky wrote:
>
> On 1/7/21 11:21 AM, Daniel Vetter wrote:
> > On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
> > > On 11/23/20 3:01 AM, Christian König wrote:
> > > > Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
> > > > > On 11/21/20 9:15 AM, Christian König wrote:
> > > > > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
> > > > > > > Will be used to reroute CPU mapped BO's page faults once
> > > > > > > device is removed.
> > > > > > Uff, one page for each exported DMA-buf? That's not something we
> > > > > > can do.
> > > > > >
> > > > > > We need to find a different approach here.
> > > > > >
> > > > > > Can't we call alloc_page() on each fault and link them together
> > > > > > so they are freed when the device is finally reaped?
> > > > >
> > > > > For sure better to optimize and allocate on demand when we reach
> > > > > this corner case, but why the linking ?
> > > > > Shouldn't drm_prime_gem_destroy be good enough place to free ?
> > > > I want to avoid keeping the page in the GEM object.
> > > >
> > > > What we can do is to allocate a page on demand for each fault and link
> > > > the together in the bdev instead.
> > > >
> > > > And when the bdev is then finally destroyed after the last application
> > > > closed we can finally release all of them.
> > > >
> > > > Christian.
> > >
> > > Hey, started to implement this and then realized that by allocating a page
> > > for each fault indiscriminately
> > > we will be allocating a new page for each faulting virtual address within
> > > a
> > > VA range belonging the same BO
> > > and this is obviously too much and not the intention. Should I instead use
> > > let's say a hashtable with the hash
> > > key being faulting BO address to actually keep allocating and reusing same
> > > dummy zero page per GEM BO
> > > (or for that matter DRM file object address for non imported BOs) ?
> > Why do we need a hashtable? All the sw structures to track this should
> > still be around:
> > - if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf,
> >so defensively allocate a per-bo page
> > - otherwise allocate a per-file page
>
>
> That exactly what we have in current implementation
>
>
> >
> > Or is the idea to save the struct page * pointer? That feels a bit like
> > over-optimizing stuff. Better to have a simple implementation first and
> > then tune it if (and only if) any part of it becomes a problem for normal
> > usage.
>
>
> Exactly - the idea is to avoid adding extra pointer to drm_gem_object,
> Christian suggested to instead keep a linked list of dummy pages to be
> allocated on demand once we hit a vm_fault. I will then also prefault the
> entire
> VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them
> to that single dummy page.
This strongly feels like premature optimization. If you're worried about
the overhead on amdgpu, pay down the debt by removing one of the redundant
pointers between gem and ttm bo structs (I think we still have some) :-)
Until we've nuked these easy&obvious ones we shouldn't play "avoid 1
pointer just because" games with hashtables.
-Daniel
>
> Andrey
>
>
> > -Daniel
> >
> > > Andrey
> > >
> > >
> > > > > Andrey
> > > > >
> > > > >
> > > > > > Regards,
> > > > > > Christian.
> > > > > >
> > > > > > > Signed-off-by: Andrey Grodzovsky
> > > > > > > ---
> > > > > > > drivers/gpu/drm/drm_file.c | 8
> > > > > > > drivers/gpu/drm/drm_prime.c | 10 ++
> > > > > > > include/drm/drm_file.h | 2 ++
> > > > > > > include/drm/drm_gem.h | 2 ++
> > > > > > > 4 files changed, 22 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/drm_file.c
> > > > > > > b/drivers/gpu/drm/drm_file.c
> > > > > > > index 0ac4566..ff3d39f 100644
> > > > > > > --- a/drivers/gpu/drm/drm_file.c
> > > > > > > +++ b/drivers/gpu/drm/drm_file.c
> > > > > > > @@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct
> > > > > > > drm_minor *minor)
> > > > > > > goto out_prime_destroy;
> > > > > > > }
> > > > > > > + file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > > > > > > + if (!file->dummy_page) {
> > > > > > > + ret = -ENOMEM;
> > > > > > > + goto out_prime_destroy;
> > > > > > > + }
> > > > > > > +
> > > > > > > return file;
> > > > > > > out_prime_destroy:
> > > > > > > @@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
> > > > > > > if (dev->driver->postclose)
> > > > > > > dev->driver->postclose(dev, file);
> > > > > > > + __free_page(file->dummy_page);
> > > > > > > +
> > > > > > > drm_prime_destroy_file_private(&file->prime);
> > > > > > > WARN_ON(!list_empty(&file->event_list));
> > > > > > > diff --git a/drivers/gpu/drm/drm_prime.c
> > > > > > > b/drivers/gpu/drm/drm_prime.c
> > > > > > > index 1693aa7..987b45c 100644
> >
Re: [PATCH 29/35] drm/amdgpu: svm bo enable_signal call condition
Am 07.01.21 um 17:16 schrieb Felix Kuehling:
Am 2021-01-07 um 5:56 a.m. schrieb Christian König:
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Alex Sierra
[why]
To support svm bo eviction mechanism.
[how]
If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
enable_signal callback will be called inside amdgpu_evict_flags.
This also causes gutting of the BO by removing all placements,
so that TTM won't actually do an eviction. Instead it will discard
the memory held by the BO. This is needed for HMM migration to user
mode system memory pages.
I don't think that this will work. What exactly are you doing here?
We discussed this a while ago when we talked about pipelined gutting.
And you actually helped us out with a fix for that
(https://patchwork.freedesktop.org/patch/379039/).
That's not what I meant. The pipelined gutting is ok, but why the
enable_signaling()?
Christian.
SVM BOs are BOs in VRAM containing data for HMM ranges. When such a BO
is evicted by TTM, we do an HMM migration of the data to system memory
(triggered by kgd2kfd_schedule_evict_and_restore_process in patch 30).
That means we don't need TTM to copy the BO contents to GTT any more.
Instead we want to use pipelined gutting to allow the VRAM to be freed
once the fence signals that the HMM migration is done (the
dma_fence_signal call near the end of svm_range_evict_svm_bo_worker in
patch 28).
Regards,
Felix
As Daniel pointed out HMM and dma_fences are fundamentally incompatible.
Christian.
Signed-off-by: Alex Sierra
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f423f42cb9b5..62d4da95d22d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -107,6 +107,20 @@ static void amdgpu_evict_flags(struct
ttm_buffer_object *bo,
}
abo = ttm_to_amdgpu_bo(bo);
+ if (abo->flags & AMDGPU_AMDKFD_CREATE_SVM_BO) {
+ struct dma_fence *fence;
+ struct dma_resv *resv = &bo->base._resv;
+
+ rcu_read_lock();
+ fence = rcu_dereference(resv->fence_excl);
+ if (fence && !fence->ops->signaled)
+ dma_fence_enable_sw_signaling(fence);
+
+ placement->num_placement = 0;
+ placement->num_busy_placement = 0;
+ rcu_read_unlock();
+ return;
+ }
switch (bo->mem.mem_type) {
case AMDGPU_PL_GDS:
case AMDGPU_PL_GWS:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
Typo Correction bellow On 1/7/21 11:26 AM, Andrey Grodzovsky wrote: Or is the idea to save the struct page * pointer? That feels a bit like over-optimizing stuff. Better to have a simple implementation first and then tune it if (and only if) any part of it becomes a problem for normal usage. Exactly - the idea is to avoid adding extra pointer to drm_gem_object, Christian suggested to instead keep a linked list of dummy pages to be allocated on demand once we hit a vm_fault. I will then also prefault the entire VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them to that single dummy page. Obviously the range is from vma->vm_start to vma->vm_end Andrey Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On 1/7/21 11:21 AM, Daniel Vetter wrote:
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link them together
so they are freed when the device is finally reaped?
For sure better to optimize and allocate on demand when we reach
this corner case, but why the linking ?
Shouldn't drm_prime_gem_destroy be good enough place to free ?
I want to avoid keeping the page in the GEM object.
What we can do is to allocate a page on demand for each fault and link
the together in the bdev instead.
And when the bdev is then finally destroyed after the last application
closed we can finally release all of them.
Christian.
Hey, started to implement this and then realized that by allocating a page
for each fault indiscriminately
we will be allocating a new page for each faulting virtual address within a
VA range belonging the same BO
and this is obviously too much and not the intention. Should I instead use
let's say a hashtable with the hash
key being faulting BO address to actually keep allocating and reusing same
dummy zero page per GEM BO
(or for that matter DRM file object address for non imported BOs) ?
Why do we need a hashtable? All the sw structures to track this should
still be around:
- if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf,
so defensively allocate a per-bo page
- otherwise allocate a per-file page
That exactly what we have in current implementation
Or is the idea to save the struct page * pointer? That feels a bit like
over-optimizing stuff. Better to have a simple implementation first and
then tune it if (and only if) any part of it becomes a problem for normal
usage.
Exactly - the idea is to avoid adding extra pointer to drm_gem_object,
Christian suggested to instead keep a linked list of dummy pages to be
allocated on demand once we hit a vm_fault. I will then also prefault the entire
VA range from vma->vm_end - vma->vm_start to vma->vm_end and map them
to that single dummy page.
Andrey
-Daniel
Andrey
Andrey
Regards,
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..ff3d39f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
+ file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!file->dummy_page) {
+ ret = -ENOMEM;
+ goto out_prime_destroy;
+ }
+
return file;
out_prime_destroy:
@@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
+ __free_page(file->dummy_page);
+
drm_prime_destroy_file_private(&file->prime);
WARN_ON(!list_empty(&file->event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7..987b45c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
ret = drm_prime_add_buf_handle(&file_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!obj->dummy_page)
+ ret = -ENOMEM;
+ }
+
mutex_unlock(&file_priv->prime.lock);
if (ret)
goto fail;
@@ -1020,6 +1027,9 @@ void drm_prime_gem_destroy(struct
drm_gem_object *obj, struct sg_table *sg)
dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
+
+ __free_page(obj->dummy_page);
+
/* remove the reference */
dma_buf_put(dma_buf);
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 716990b..2a011fc 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -346,6 +346,8 @@ struct drm_file {
*/
struct drm_prime_file_private prime;
+ struct page *dummy_page;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 337a483..76a97a3 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -311,6 +311,8 @@ struct
Re: [PATCH 00/35] Add HMM-based SVM memory manager to KFD
Am 2021-01-07 um 4:23 a.m. schrieb Daniel Vetter: > On Wed, Jan 06, 2021 at 10:00:52PM -0500, Felix Kuehling wrote: >> This is the first version of our HMM based shared virtual memory manager >> for KFD. There are still a number of known issues that we're working through >> (see below). This will likely lead to some pretty significant changes in >> MMU notifier handling and locking on the migration code paths. So don't >> get hung up on those details yet. >> >> But I think this is a good time to start getting feedback. We're pretty >> confident about the ioctl API, which is both simple and extensible for the >> future. (see patches 4,16) The user mode side of the API can be found here: >> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/fxkamd/hmm-wip/src/svm.c >> >> I'd also like another pair of eyes on how we're interfacing with the GPU VM >> code in amdgpu_vm.c (see patches 12,13), retry page fault handling (24,25), >> and some retry IRQ handling changes (32). >> >> >> Known issues: >> * won't work with IOMMU enabled, we need to dma_map all pages properly >> * still working on some race conditions and random bugs >> * performance is not great yet > Still catching up, but I think there's another one for your list: > > * hmm gpu context preempt vs page fault handling. I've had a short >discussion about this one with Christian before the holidays, and also >some private chats with Jerome. It's nasty since no easy fix, much less >a good idea what's the best approach here. Do you have a pointer to that discussion or any more details? Thanks, Felix > > I'll try to look at this more in-depth when I'm catching up on mails. > -Daniel > >> Alex Sierra (12): >> drm/amdgpu: replace per_device_list by array >> drm/amdkfd: helper to convert gpu id and idx >> drm/amdkfd: add xnack enabled flag to kfd_process >> drm/amdkfd: add ioctl to configure and query xnack retries >> drm/amdkfd: invalidate tables on page retry fault >> drm/amdkfd: page table restore through svm API >> drm/amdkfd: SVM API call to restore page tables >> drm/amdkfd: add svm_bo reference for eviction fence >> drm/amdgpu: add param bit flag to create SVM BOs >> drm/amdkfd: add svm_bo eviction mechanism support >> drm/amdgpu: svm bo enable_signal call condition >> drm/amdgpu: add svm_bo eviction to enable_signal cb >> >> Philip Yang (23): >> drm/amdkfd: select kernel DEVICE_PRIVATE option >> drm/amdkfd: add svm ioctl API >> drm/amdkfd: Add SVM API support capability bits >> drm/amdkfd: register svm range >> drm/amdkfd: add svm ioctl GET_ATTR op >> drm/amdgpu: add common HMM get pages function >> drm/amdkfd: validate svm range system memory >> drm/amdkfd: register overlap system memory range >> drm/amdkfd: deregister svm range >> drm/amdgpu: export vm update mapping interface >> drm/amdkfd: map svm range to GPUs >> drm/amdkfd: svm range eviction and restore >> drm/amdkfd: register HMM device private zone >> drm/amdkfd: validate vram svm range from TTM >> drm/amdkfd: support xgmi same hive mapping >> drm/amdkfd: copy memory through gart table >> drm/amdkfd: HMM migrate ram to vram >> drm/amdkfd: HMM migrate vram to ram >> drm/amdgpu: reserve fence slot to update page table >> drm/amdgpu: enable retry fault wptr overflow >> drm/amdkfd: refine migration policy with xnack on >> drm/amdkfd: add svm range validate timestamp >> drm/amdkfd: multiple gpu migrate vram to vram >> >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|3 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|4 +- >> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 16 +- >> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c| 83 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h|7 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h|5 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 90 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 47 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 10 + >> drivers/gpu/drm/amd/amdgpu/vega10_ih.c| 32 +- >> drivers/gpu/drm/amd/amdgpu/vega20_ih.c| 32 +- >> drivers/gpu/drm/amd/amdkfd/Kconfig|1 + >> drivers/gpu/drm/amd/amdkfd/Makefile |4 +- >> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 170 +- >> drivers/gpu/drm/amd/amdkfd/kfd_iommu.c|8 +- >> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 866 ++ >> drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 59 + >> drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 52 +- >> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 200 +- >> .../amd/amdkfd/kfd_process_queue_manager.c|6 +- >> drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2564 + >> drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 135 + >> drivers/gpu/drm/amd/amdkfd/kfd_topology.c |1 + >> drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 10 +- >>
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On Tue, Jan 05, 2021 at 04:04:16PM -0500, Andrey Grodzovsky wrote:
>
> On 11/23/20 3:01 AM, Christian König wrote:
> > Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
> > >
> > > On 11/21/20 9:15 AM, Christian König wrote:
> > > > Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
> > > > > Will be used to reroute CPU mapped BO's page faults once
> > > > > device is removed.
> > > >
> > > > Uff, one page for each exported DMA-buf? That's not something we can do.
> > > >
> > > > We need to find a different approach here.
> > > >
> > > > Can't we call alloc_page() on each fault and link them together
> > > > so they are freed when the device is finally reaped?
> > >
> > >
> > > For sure better to optimize and allocate on demand when we reach
> > > this corner case, but why the linking ?
> > > Shouldn't drm_prime_gem_destroy be good enough place to free ?
> >
> > I want to avoid keeping the page in the GEM object.
> >
> > What we can do is to allocate a page on demand for each fault and link
> > the together in the bdev instead.
> >
> > And when the bdev is then finally destroyed after the last application
> > closed we can finally release all of them.
> >
> > Christian.
>
>
> Hey, started to implement this and then realized that by allocating a page
> for each fault indiscriminately
> we will be allocating a new page for each faulting virtual address within a
> VA range belonging the same BO
> and this is obviously too much and not the intention. Should I instead use
> let's say a hashtable with the hash
> key being faulting BO address to actually keep allocating and reusing same
> dummy zero page per GEM BO
> (or for that matter DRM file object address for non imported BOs) ?
Why do we need a hashtable? All the sw structures to track this should
still be around:
- if gem_bo->dma_buf is set the buffer is currently exported as a dma-buf,
so defensively allocate a per-bo page
- otherwise allocate a per-file page
Or is the idea to save the struct page * pointer? That feels a bit like
over-optimizing stuff. Better to have a simple implementation first and
then tune it if (and only if) any part of it becomes a problem for normal
usage.
-Daniel
>
> Andrey
>
>
> >
> > >
> > > Andrey
> > >
> > >
> > > >
> > > > Regards,
> > > > Christian.
> > > >
> > > > >
> > > > > Signed-off-by: Andrey Grodzovsky
> > > > > ---
> > > > > drivers/gpu/drm/drm_file.c | 8
> > > > > drivers/gpu/drm/drm_prime.c | 10 ++
> > > > > include/drm/drm_file.h | 2 ++
> > > > > include/drm/drm_gem.h | 2 ++
> > > > > 4 files changed, 22 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > > > > index 0ac4566..ff3d39f 100644
> > > > > --- a/drivers/gpu/drm/drm_file.c
> > > > > +++ b/drivers/gpu/drm/drm_file.c
> > > > > @@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor
> > > > > *minor)
> > > > > goto out_prime_destroy;
> > > > > }
> > > > > + file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > > > > + if (!file->dummy_page) {
> > > > > + ret = -ENOMEM;
> > > > > + goto out_prime_destroy;
> > > > > + }
> > > > > +
> > > > > return file;
> > > > > out_prime_destroy:
> > > > > @@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
> > > > > if (dev->driver->postclose)
> > > > > dev->driver->postclose(dev, file);
> > > > > + __free_page(file->dummy_page);
> > > > > +
> > > > > drm_prime_destroy_file_private(&file->prime);
> > > > > WARN_ON(!list_empty(&file->event_list));
> > > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > > index 1693aa7..987b45c 100644
> > > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > > @@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device
> > > > > *dev,
> > > > > ret = drm_prime_add_buf_handle(&file_priv->prime,
> > > > > dma_buf, *handle);
> > > > > +
> > > > > + if (!ret) {
> > > > > + obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > > > > + if (!obj->dummy_page)
> > > > > + ret = -ENOMEM;
> > > > > + }
> > > > > +
> > > > > mutex_unlock(&file_priv->prime.lock);
> > > > > if (ret)
> > > > > goto fail;
> > > > > @@ -1020,6 +1027,9 @@ void drm_prime_gem_destroy(struct
> > > > > drm_gem_object *obj, struct sg_table *sg)
> > > > > dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
> > > > > dma_buf = attach->dmabuf;
> > > > > dma_buf_detach(attach->dmabuf, attach);
> > > > > +
> > > > > + __free_page(obj->dummy_page);
> > > > > +
> > > > > /* remove the reference */
> > > > > dma_buf_put(dma_buf);
> > > > > }
> > > > > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> > > > > index 716990b..2a011fc 100644
> > > > > --- a/include/drm/drm_file.h
> > > >
Re: [PATCH 29/35] drm/amdgpu: svm bo enable_signal call condition
Am 2021-01-07 um 5:56 a.m. schrieb Christian König:
> Am 07.01.21 um 04:01 schrieb Felix Kuehling:
>> From: Alex Sierra
>>
>> [why]
>> To support svm bo eviction mechanism.
>>
>> [how]
>> If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
>> enable_signal callback will be called inside amdgpu_evict_flags.
>> This also causes gutting of the BO by removing all placements,
>> so that TTM won't actually do an eviction. Instead it will discard
>> the memory held by the BO. This is needed for HMM migration to user
>> mode system memory pages.
>
> I don't think that this will work. What exactly are you doing here?
We discussed this a while ago when we talked about pipelined gutting.
And you actually helped us out with a fix for that
(https://patchwork.freedesktop.org/patch/379039/).
SVM BOs are BOs in VRAM containing data for HMM ranges. When such a BO
is evicted by TTM, we do an HMM migration of the data to system memory
(triggered by kgd2kfd_schedule_evict_and_restore_process in patch 30).
That means we don't need TTM to copy the BO contents to GTT any more.
Instead we want to use pipelined gutting to allow the VRAM to be freed
once the fence signals that the HMM migration is done (the
dma_fence_signal call near the end of svm_range_evict_svm_bo_worker in
patch 28).
Regards,
Felix
>
> As Daniel pointed out HMM and dma_fences are fundamentally incompatible.
>
> Christian.
>
>>
>> Signed-off-by: Alex Sierra
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> index f423f42cb9b5..62d4da95d22d 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> @@ -107,6 +107,20 @@ static void amdgpu_evict_flags(struct
>> ttm_buffer_object *bo,
>> }
>> abo = ttm_to_amdgpu_bo(bo);
>> + if (abo->flags & AMDGPU_AMDKFD_CREATE_SVM_BO) {
>> + struct dma_fence *fence;
>> + struct dma_resv *resv = &bo->base._resv;
>> +
>> + rcu_read_lock();
>> + fence = rcu_dereference(resv->fence_excl);
>> + if (fence && !fence->ops->signaled)
>> + dma_fence_enable_sw_signaling(fence);
>> +
>> + placement->num_placement = 0;
>> + placement->num_busy_placement = 0;
>> + rcu_read_unlock();
>> + return;
>> + }
>> switch (bo->mem.mem_type) {
>> case AMDGPU_PL_GDS:
>> case AMDGPU_PL_GWS:
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch] fbcon: i want fbcon soft scrollback feature come back
On Thu, Jan 7, 2021 at 4:48 PM xuhuijie wrote: > This commit 50145474f6ef(fbcon: remove soft scrollback code) remove soft > scrollback in > fbcon. So the shift+PageDown and shift+PageUp is missing. But PageUp is a > vary important > feature when system panic or reset. I can get log by PageUp before, but now > there is no > way to get. Especially on the server system, we always use bmc to control > computer. > So I hope the community can add this feature back. Adding Linus. Short summary: Not going to happen without significant effort: https://lore.kernel.org/stable/cakmk7uey-b_npmoh9wya4ncsk8al_jk+-+frzsrk6noqqrv...@mail.gmail.com/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
On 05/01/2021 00:11, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G-57 on MT8183) will
require platform-specific handling, disable devfreq for now.
Can you explain what actually goes wrong here? AFAICT the existing code
does support controlling multiple regulators - but clearly this is the
first platform that exercises that code with num_supplies>1.
Steve
Signed-off-by: Nicolas Boichat
---
Changes in v6:
- New change
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index f44d28fad085..1f49043aae73 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -92,6 +92,15 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
+ if (pfdev->comp->num_supplies > 1) {
+ /*
+* GPUs with more than 1 supply require platform-specific
handling:
+* continue without devfreq
+*/
+ DRM_DEV_ERROR(dev, "More than 1 supply is not supported yet\n");
+ return 0;
+ }
+
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
On Thu, Jan 07, 2021 at 10:01:00AM -0500, Alex Deucher wrote: > On Wed, Dec 16, 2020 at 10:30 AM Greg Kroah-Hartman > wrote: > > > > On Wed, Dec 16, 2020 at 02:52:25PM +, Deucher, Alexander wrote: > > > [AMD Public Use] > > > > > > > -Original Message- > > > > From: Laurent Pinchart > > > > Sent: Tuesday, December 15, 2020 9:15 PM > > > > To: Koenig, Christian > > > > Cc: Daniel Vetter ; Laurent Pinchart > > > > ; dri- > > > > de...@lists.freedesktop.org; Dave Airlie ; Greg > > > > Kroah- > > > > Hartman ; Thomas Gleixner > > > > ; Deucher, Alexander ; > > > > Rob Clark ; Sean Paul ; Ben > > > > Skeggs ; Gerd Hoffmann ; > > > > Thierry Reding ; Eric Anholt > > > > ; > > > > VMware Graphics ; Thomas > > > > Hellstrom > > > > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > > > > > > > Hi Christian, > > > > > > > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > > > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > > > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > > > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > > > > Most of the DRM drivers uAPI headers are licensed under the MIT > > > > > license, and carry copies of the license with slight variations. > > > > > Replace them with SPDX headers. > > > > > >>> My personal opinion is that this is a really good idea, but my > > > > > >>> professional is that we need the acknowledgment from our legal > > > > department for this. > > > > > >> I think official ack from amd on first patch, especially the .rst > > > > > >> snippet, would be really good indeed. > > > > > > Any update on this one ? > > > > > > > > > > Sorry totally forgot to forward this because I was waiting for split > > > > > up patches. > > > > > > > > > > Going to do so right now. > > > > > > > > Has there been any update ? :-) > > > > > > AMD legal requires the full license. > > > > Um, what? Please let me talk to them about this, it's not ok for one > > individual company, out of 450+, to somehow decide to do something > > different. > > > > Please put your lawyers in contact with me and I will have them discuss > > it with the proper lawyers on our side. > > After more discussion, the lawyers have allowed us to use the SPDX licenses > now. Wonderful, thanks for pushing this through and letting us know! greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings
On Thu, Jan 7, 2021 at 11:28 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 11.12.20 um 10:50 schrieb Daniel Vetter:
> [...]
> >> +/**
> >> + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM
> >> object
> >> + * @shmem: shmem GEM object
> >> + * @map: Returns the kernel virtual address of the SHMEM GEM object's
> >> backing
> >> + * store.
> >> + *
> >> + * This function makes sure that a contiguous kernel virtual address
> >> mapping
> >> + * exists for the buffer backing the shmem GEM object.
> >> + *
> >> + * The function is called with the BO's reservation object locked.
> >> Callers must
> >> + * hold the lock until after unmapping the buffer.
> >> + *
> >> + * This function can be used to implement
> >> &drm_gem_object_funcs.vmap_local. But
> >> + * it can also be called by drivers directly, in which case it will hide
> >> the
> >> + * differences between dma-buf imported and natively allocated objects.
> >> + *
> >> + * Acquired mappings should be cleaned up by calling
> >> drm_gem_shmem_vunmap_local().
> >> + *
> >> + * Returns:
> >> + * 0 on success or a negative error code on failure.
> >> + */
> >> +int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct
> >> dma_buf_map *map)
> >> +{
> >> +struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >> +int ret;
> >> +
> >> +dma_resv_assert_held(obj->resv);
> >> +
> >> +ret = mutex_lock_interruptible(&shmem->vmap_lock);
> >
> > This bites. You need to check for shmem->import_attach and call
> > dma_buf_vmap_local directly here before you take any shmem helper locks.
> > Real fix would be to replace both vmap_lock and pages_lock with dma_resv
> > lock, but that's more work. Same for vunmap_local
>
> This comment confuses me. AFAICT vmap_lock protects vmap_use_count. Why
> does this exact code work in drm_gem_shmem_vmap() but not in _local() ?
You'd hold the dma_resv lock both inside and outside of the
->vmap_lock mutex. Which deadlocks. For the _vmap version we more or
less mandate that the caller doens't hold the dma_resv lock already,
hence why we can get away with that.
-Daniel
> Best regards
> Thomas
>
> >
> > With that fixed on the helper part of this patch:
> >
> > Reviewed-by: Daniel Vetter
> >
> >
> >> +if (ret)
> >> +return ret;
> >> +ret = drm_gem_shmem_vmap_locked(shmem, map);
> >> +mutex_unlock(&shmem->vmap_lock);
> >> +
> >> +return ret;
> >> +}
> >> +EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
> >> +
> >> static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object
> >> *shmem,
> >> struct dma_buf_map *map)
> >> {
> >> @@ -366,7 +406,7 @@ static void drm_gem_shmem_vunmap_locked(struct
> >> drm_gem_shmem_object *shmem,
> >> drm_gem_shmem_put_pages(shmem);
> >> }
> >>
> >> -/*
> >> +/**
> >>* drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object
> >>* @shmem: shmem GEM object
> >>* @map: Kernel virtual address where the SHMEM GEM object was mapped
> >> @@ -389,6 +429,33 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj,
> >> struct dma_buf_map *map)
> >> }
> >> EXPORT_SYMBOL(drm_gem_shmem_vunmap);
> >>
> >> +/**
> >> + * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM
> >> object
> >> + * @shmem: shmem GEM object
> >> + * @map: Kernel virtual address where the SHMEM GEM object was mapped
> >> + *
> >> + * This function cleans up a kernel virtual address mapping acquired by
> >> + * drm_gem_shmem_vmap_local(). The mapping is only removed when the use
> >> count
> >> + * drops to zero.
> >> + *
> >> + * The function is called with the BO's reservation object locked.
> >> + *
> >> + * This function can be used to implement
> >> &drm_gem_object_funcs.vmap_local.
> >> + * But it can also be called by drivers directly, in which case it will
> >> hide
> >> + * the differences between dma-buf imported and natively allocated
> >> objects.
> >> + */
> >> +void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct
> >> dma_buf_map *map)
> >> +{
> >> +struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> >> +
> >> +dma_resv_assert_held(obj->resv);
> >> +
> >> +mutex_lock(&shmem->vmap_lock);
> >> +drm_gem_shmem_vunmap_locked(shmem, map);
> >> +mutex_unlock(&shmem->vmap_lock);
> >> +}
> >> +EXPORT_SYMBOL(drm_gem_shmem_vunmap_local);
> >> +
> >> struct drm_gem_shmem_object *
> >> drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
> >> struct drm_device *dev, size_t size,
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> index 1dfc42170059..a33e28d4c5e9 100644
> >> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> >> @@ -1552,22 +1552,32 @@ mgag200_handle_damage(struct mga_device *mdev,
> >> struct drm_framebuffer *fb,
> >>struct
Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers
On Wed, Dec 16, 2020 at 10:30 AM Greg Kroah-Hartman wrote: > > On Wed, Dec 16, 2020 at 02:52:25PM +, Deucher, Alexander wrote: > > [AMD Public Use] > > > > > -Original Message- > > > From: Laurent Pinchart > > > Sent: Tuesday, December 15, 2020 9:15 PM > > > To: Koenig, Christian > > > Cc: Daniel Vetter ; Laurent Pinchart > > > ; dri- > > > de...@lists.freedesktop.org; Dave Airlie ; Greg Kroah- > > > Hartman ; Thomas Gleixner > > > ; Deucher, Alexander ; > > > Rob Clark ; Sean Paul ; Ben > > > Skeggs ; Gerd Hoffmann ; > > > Thierry Reding ; Eric Anholt ; > > > VMware Graphics ; Thomas > > > Hellstrom > > > Subject: Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers > > > > > > Hi Christian, > > > > > > On Fri, Jul 17, 2020 at 04:05:42PM +0200, Christian König wrote: > > > > Am 17.07.20 um 04:27 schrieb Laurent Pinchart: > > > > > On Mon, Jun 22, 2020 at 11:29:33AM +0200, Daniel Vetter wrote: > > > > >> On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote: > > > > >>> Am 21.06.20 um 04:07 schrieb Laurent Pinchart: > > > > Most of the DRM drivers uAPI headers are licensed under the MIT > > > > license, and carry copies of the license with slight variations. > > > > Replace them with SPDX headers. > > > > >>> My personal opinion is that this is a really good idea, but my > > > > >>> professional is that we need the acknowledgment from our legal > > > department for this. > > > > >> I think official ack from amd on first patch, especially the .rst > > > > >> snippet, would be really good indeed. > > > > > Any update on this one ? > > > > > > > > Sorry totally forgot to forward this because I was waiting for split > > > > up patches. > > > > > > > > Going to do so right now. > > > > > > Has there been any update ? :-) > > > > AMD legal requires the full license. > > Um, what? Please let me talk to them about this, it's not ok for one > individual company, out of 450+, to somehow decide to do something > different. > > Please put your lawyers in contact with me and I will have them discuss > it with the proper lawyers on our side. After more discussion, the lawyers have allowed us to use the SPDX licenses now. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mediatek: dsi: Fix EoTp flag
SoC will transmit the EoTp (End of Transmission packet) when MIPI_DSI_MODE_EOT_PACKET flag is set. Enabling EoTp will make the line time larger, so the hfp and hbp should be reduced to keep line time. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dsi.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index 65fd99c528af..8c70ec39bfe1 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -401,8 +401,11 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) break; } - tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; - tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) + tmp_reg |= HSTX_CKLP_EN; + + if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET)) + tmp_reg |= DIS_EOT; writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); } @@ -478,6 +481,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) timing->da_hs_zero + timing->da_hs_exit + 3; delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12; + delta += dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET ? 2 : 0; horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp; horizontal_front_back_byte = horizontal_frontporch_byte + horizontal_backporch_byte; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: Remove usage of drm_display_mode_to_videomode()
Hi Marek,
thanks for the patch. It works fine on stm32mp1 eval board with bridge
DSI & DPI panel.
Tested-by: Yannick Fertré
Best regards
On 12/24/20 7:20 AM, Marek Vasut wrote:
> There is not much value in the extra conversion step, the calculations
> required for the LTDC IP are different than what is used in the
> drm_display_mode_to_videomode(), so just do the right ones in the LTDC
> driver right away.
>
> Signed-off-by: Marek Vasut
> Cc: Alexandre Torgue
> Cc: Antonio Borneo
> Cc: Benjamin Gaignard
> Cc: Maxime Coquelin
> Cc: Philippe Cornu
> Cc: Sam Ravnborg
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/stm/ltdc.c | 33 +
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 22c7e9fa5ab7..e8fc8fc50d94 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -545,7 +545,6 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
> struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> struct drm_device *ddev = crtc->dev;
> struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> - struct videomode vm;
> u32 bus_flags = 0;
> u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
> u32 total_width, total_height;
> @@ -565,31 +564,33 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> }
> }
>
> - drm_display_mode_to_videomode(mode, &vm);
> -
> DRM_DEBUG_DRIVER("CRTC:%d mode:%s\n", crtc->base.id, mode->name);
> - DRM_DEBUG_DRIVER("Video mode: %dx%d", vm.hactive, vm.vactive);
> + DRM_DEBUG_DRIVER("Video mode: %dx%d", mode->hdisplay, mode->vdisplay);
> DRM_DEBUG_DRIVER(" hfp %d hbp %d hsl %d vfp %d vbp %d vsl %d\n",
> - vm.hfront_porch, vm.hback_porch, vm.hsync_len,
> - vm.vfront_porch, vm.vback_porch, vm.vsync_len);
> + mode->hsync_start - mode->hdisplay,
> + mode->htotal - mode->hsync_end,
> + mode->hsync_end - mode->hsync_start,
> + mode->vsync_start - mode->vdisplay,
> + mode->vtotal - mode->vsync_end,
> + mode->vsync_end - mode->vsync_start);
>
> /* Convert video timings to ltdc timings */
> - hsync = vm.hsync_len - 1;
> - vsync = vm.vsync_len - 1;
> - accum_hbp = hsync + vm.hback_porch;
> - accum_vbp = vsync + vm.vback_porch;
> - accum_act_w = accum_hbp + vm.hactive;
> - accum_act_h = accum_vbp + vm.vactive;
> - total_width = accum_act_w + vm.hfront_porch;
> - total_height = accum_act_h + vm.vfront_porch;
> + hsync = mode->hsync_end - mode->hsync_start - 1;
> + vsync = mode->vsync_end - mode->vsync_start - 1;
> + accum_hbp = mode->htotal - mode->hsync_start - 1;
> + accum_vbp = mode->vtotal - mode->vsync_start - 1;
> + accum_act_w = accum_hbp + mode->hdisplay;
> + accum_act_h = accum_vbp + mode->vdisplay;
> + total_width = mode->htotal - 1;
> + total_height = mode->vtotal - 1;
>
> /* Configures the HS, VS, DE and PC polarities. Default Active Low */
> val = 0;
>
> - if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH)
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> val |= GCR_HSPOL;
>
> - if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> val |= GCR_VSPOL;
>
> if (bus_flags & DRM_BUS_FLAG_DE_LOW)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/ttm: optimize ttm pool shrinker a bit
Am 22.12.20 um 14:51 schrieb Daniel Vetter:
On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wrote:
Only initialize the DMA coherent pools if they are used.
Signed-off-by: Christian König
Ah, just realized the answer to my question on patch 2: The pools are
per-device, due to dma_alloc_coherent being per-device (but really mostly
it isn't, but that's what we have to deal with fighting the dma-api
abstraction).
I think this would make a lot more sense if the shrinkers are per-pool
(and also most of the debugfs files), since as-is in a multi-gpu system
the first gpu's pool gets preferrentially thrashed. Which isn't a nice
design. Splitting that into per gpu shrinkers means we get equal shrinking
without having to maintain a global lru. This is how xfs seems to set up
their shrinkers, and in general xfs people have a solid understanding of
this stuff.
Well fairness and not trashing the first GPUs pool is the reason why I
implemented just one shrinker plus a global LRU.
In other words shrink_slab() just uses list_for_each_entry() on all
shrinkers.
In the pool shrinker callback shrink one pool and move it to the end of
the shrinker list.
Aside: I think it also would make tons of sense to split up your new ttm
bo shrinker up into a per-device lru, and throw the global system memory
lru out the window completely :-) Assuming we can indeed get rid of it,
and vmwgfx doesn't need it somewhere still.
Yeah, I already have that as a patch set here, but I have this dependent
on a larger rename of the device structures.
Aside from this lgtm, but I guess will change a bit with that shuffling.
Thanks for the review, going to send out a new version with the
fs_reclaim_acquire/release added in a minute.
Christian.
-Daniel
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 1cdacd58753a..f09e34614226 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -504,10 +504,12 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
pool->use_dma_alloc = use_dma_alloc;
pool->use_dma32 = use_dma32;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_init(&pool->caching[i].orders[j],
- pool, i, j);
+ if (use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_init(&pool->caching[i].orders[j],
+ pool, i, j);
+ }
}
EXPORT_SYMBOL(ttm_pool_init);
@@ -523,9 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
{
unsigned int i, j;
- for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
- ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ if (pool->use_dma_alloc) {
+ for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
+ for (j = 0; j < MAX_ORDER; ++j)
+ ttm_pool_type_fini(&pool->caching[i].orders[j]);
+ }
}
EXPORT_SYMBOL(ttm_pool_fini);
@@ -630,6 +634,11 @@ int ttm_pool_debugfs(struct ttm_pool *pool, struct seq_file *m)
{
unsigned int i;
+ if (!pool->use_dma_alloc) {
+ seq_puts(m, "unused\n");
+ return 0;
+ }
+
ttm_pool_debugfs_header(m);
spin_lock(&shrinker_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-next
On Wed, Jan 06, 2021 at 12:13:12PM +0100, Maarten Lankhorst wrote:
> drm-misc-next-2021-01-06:
> drm-misc-next for v5.12:
>
> Core Changes:
> - Lots of drm documentation updates by Simor Ser.
Extra kudos for documentation work!
> - Require that each crtc has a unique primary plane.
> - Add fixme that fbdev_generic_setup is confusing.
>
> Driver Changes:
> - Update addresses for TI display drivers maintainers.
> - Make DRM_VIRTIO_GPU select VIRTIO.
> - Small fixes to qxl, virtio, hisilicon, tve200, panel/s6e63m0.
> The following changes since commit 5fbd41d3bf123af6a135bdea564087ec0f563eb0:
>
> Merge tag 'drm-misc-next-2020-11-27-1' of
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-12-15 10:21:48
> +0100)
Pulled, thanks.
-Daniel
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-01-06
>
> for you to fetch changes up to cf9a4be47fd14473b4d0dd6f494ed7279c2bc8a0:
>
> drm/doc: render drm.h uapi docs (2021-01-05 14:22:26 +0100)
>
>
> drm-misc-next for v5.12:
>
> Core Changes:
> - Lots of drm documentation updates by Simor Ser.
> - Require that each crtc has a unique primary plane.
> - Add fixme that fbdev_generic_setup is confusing.
>
> Driver Changes:
> - Update addresses for TI display drivers maintainers.
> - Make DRM_VIRTIO_GPU select VIRTIO.
> - Small fixes to qxl, virtio, hisilicon, tve200, panel/s6e63m0.
>
>
> Arnd Bergmann (1):
> drm/kmb: fix array bounds warning
>
> Bernard Zhao (1):
> via/via_irq: use __func__ to replace string function name
>
> Chia-I Wu (1):
> drm/virtio: align blob resources to page sizes
>
> Christian König (13):
> drm/radeon: fix check order in radeon_bo_move
> drm/radeon: stop using pages with drm_prime_sg_to_page_addr_arrays v2
> drm/amdgpu: stop using pages with drm_prime_sg_to_page_addr_arrays
> drm/nouveau: stop using pages with drm_prime_sg_to_page_addr_arrays v2
> drm/vmwgfx: switch to ttm_sg_tt_init
> drm/qxl: switch to ttm_sg_tt_init
> drm/ttm: nuke ttm_dma_tt_init
> drm/prime: split array import functions v4
> drm/ttm/drivers: remove unecessary ttm_module.h include v2
> drm/ttm: stop destroying pinned ghost object
> drm/ttm: cleanup BO size handling v3
> drm/ttm: use pin_count more extensively
> drm/ttm: cleanup LRU handling further
>
> Chuhong Yuan (1):
> drm/fb-helper: Add missed unlocks in setcmap_legacy()
>
> Dafna Hirschfeld (2):
> drm/rockchip: for error print, use the correct device pointer
> drm/rockchip: fix typo in Kconfig 's/HDMI/dsi/'
>
> Dan Carpenter (3):
> drm/kmb: Remove an unnecessary NULL check
> gma500: clean up error handling in init
> drm/panel: khadas: Fix error code in khadas_ts050_panel_add()
>
> Daniel Vetter (10):
> drm/ttm: Warn on pinning without holding a reference
> drm/nouveau: Drop mutex_lock_nested for atomic
> dma-buf: Fix kerneldoc formatting
> drm/vkms: Unset preferred_depth
> drm/amdkfd: fix ttm size refactor fallout
> dma-buf: Remove kmap kerneldoc vestiges
> dma-buf: some kerneldoc formatting fixes
> dma-buf: begin/end_cpu might lock the dma_resv lock
> dma-buf: doc polish for pin/unpin
> drm/fb-helper: Add a FIXME that generic_setup is very confusing
>
> Dave Stevenson (4):
> drm/vc4: dsi: Correct DSI register definition
> drm/vc4: dsi: Add support for DSI0
> dt-bindings: Add compatible for BCM2711 DSI1
> drm/vc4: dsi: Add configuration for BCM2711 DSI1
>
> Douglas Anderson (7):
> drm: panel: simple: Fixup the struct panel_desc kernel doc
> drm: panel: simple: Defer unprepare delay till next prepare to shorten
> it
> drm: panel: simple: Allow specifying the delay from prepare to enable
> dt-bindings: dt-bindings: display: simple: Add BOE NV110WTM-N61
> drm: panel: simple: Add BOE NV110WTM-N61
> drm: panel: Fully transition panel_desc kerneldoc to inline style
> drm: panel: add flags to BOE NV110WTM-N61
>
> Enrico Weigelt, metux IT consult (1):
> drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
>
> Guido Günther (6):
> drm/panel: st7703: Use dev_err_probe
> drm/panel: mantix: Tweak init sequence
> drm/panel: mantix: Allow to specify default mode for different panels
> drm/panel: mantix: Support panel from Shenzhen Yashi Changhua
> Intelligent Technology Co
> dt-bindings: vendor-prefixes: Add ys vendor prefix
> dt-bindings: display: mantix: Add compatible for panel from YS
>
> Gurchetan Singh (3):
> drm/virtio: virtio_{blah} --> virtio_gpu_{blah}
> drm/virtio: rework virtio_fence_signaled
> drm/virtio: consider dma-fence context when signaling
>
> Jialin Z
Re: [PATCH V2] drm/stm: Fix bus_flags handling
Hi Marek,
thanks for the patch. It works fine on stm32mp1 eval board with bridge
DSI & DPI panel.
Tested-by: Yannick Fertré
Best regards
On 12/24/20 7:19 AM, Marek Vasut wrote:
> The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW
> or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no
> matter what polarity the next bridge or display might require, these flags
> are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set,
> and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and
> DISPLAY_FLAGS_DE_HIGH were always set.
>
> The fix for this problem is taken almost verbatim from MXSFB driver. In
> case there is a bridge attached to the LTDC, the bridge might have extra
> polarity requirements, so extract bus_flags from the bridge and use them
> for LTDC configuration. Otherwise, extract bus_flags from the connector,
> which is the display.
>
> Fixes: b759012c5fa7 ("drm/stm: Add STM32 LTDC driver")
> Signed-off-by: Marek Vasut
> Cc: Alexandre Torgue
> Cc: Antonio Borneo
> Cc: Benjamin Gaignard
> Cc: Maxime Coquelin
> Cc: Philippe Cornu
> Cc: Sam Ravnborg
> Cc: Vincent Abriou
> Cc: Yannick Fertre
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Check if ldev->bridge->timings is non-NULL before accessing it
> ---
> drivers/gpu/drm/stm/ltdc.c | 22 --
> drivers/gpu/drm/stm/ltdc.h | 2 ++
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 1c9f18b4adfc..22c7e9fa5ab7 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -546,11 +546,17 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> struct drm_device *ddev = crtc->dev;
> struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> struct videomode vm;
> + u32 bus_flags = 0;
> u32 hsync, vsync, accum_hbp, accum_vbp, accum_act_w, accum_act_h;
> u32 total_width, total_height;
> u32 val;
> int ret;
>
> + if (ldev->bridge && ldev->bridge->timings)
> + bus_flags = ldev->bridge->timings->input_bus_flags;
> + else if (ldev->connector)
> + bus_flags = ldev->connector->display_info.bus_flags;
> +
> if (!pm_runtime_active(ddev->dev)) {
> ret = pm_runtime_get_sync(ddev->dev);
> if (ret) {
> @@ -586,10 +592,10 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc
> *crtc)
> if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
> val |= GCR_VSPOL;
>
> - if (vm.flags & DISPLAY_FLAGS_DE_LOW)
> + if (bus_flags & DRM_BUS_FLAG_DE_LOW)
> val |= GCR_DEPOL;
>
> - if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
> val |= GCR_PCPOL;
>
> reg_update_bits(ldev->regs, LTDC_GCR,
> @@ -1098,6 +1104,8 @@ static const struct drm_encoder_helper_funcs
> ltdc_encoder_helper_funcs = {
>
> static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge
> *bridge)
> {
> + struct ltdc_device *ldev = ddev->dev_private;
> + struct drm_connector_list_iter iter;
> struct drm_encoder *encoder;
> int ret;
>
> @@ -1119,6 +1127,16 @@ static int ltdc_encoder_init(struct drm_device *ddev,
> struct drm_bridge *bridge)
> return -EINVAL;
> }
>
> + ldev->bridge = bridge;
> +
> + /*
> + * Get hold of the connector. This is a bit of a hack, until the bridge
> + * API gives us bus flags and formats.
> + */
> + drm_connector_list_iter_begin(ddev, &iter);
> + ldev->connector = drm_connector_list_iter_next(&iter);
> + drm_connector_list_iter_end(&iter);
> +
> DRM_DEBUG_DRIVER("Bridge encoder:%d created\n", encoder->base.id);
>
> return 0;
> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
> index f153b908c70e..d0d2c81de29a 100644
> --- a/drivers/gpu/drm/stm/ltdc.h
> +++ b/drivers/gpu/drm/stm/ltdc.h
> @@ -38,6 +38,8 @@ struct ltdc_device {
> u32 irq_status;
> struct fps_info plane_fpsi[LTDC_MAX_LAYER];
> struct drm_atomic_state *suspend_state;
> + struct drm_bridge *bridge;
> + struct drm_connector *connector;
> };
>
> int ltdc_load(struct drm_device *ddev);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9, 10/11] drm/mediatek: add DDP support for MT8183
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月7日 週四 上午11:12寫道：
>
> Add DDP support for MT8167 SoC.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 48
> ++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 1f99db6..1308046 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -15,6 +15,8 @@
>
> #define MT2701_DISP_MUTEX0_MOD00x2c
> #define MT2701_DISP_MUTEX0_SOF00x30
> +#define MT8183_DISP_MUTEX0_MOD00x30
> +#define MT8183_DISP_MUTEX0_SOF00x2c
>
> #define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
> #define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
> @@ -38,6 +40,18 @@
> #define MT8167_MUTEX_MOD_DISP_DITHER 15
> #define MT8167_MUTEX_MOD_DISP_UFOE 16
>
> +#define MT8183_MUTEX_MOD_DISP_RDMA00
> +#define MT8183_MUTEX_MOD_DISP_RDMA11
> +#define MT8183_MUTEX_MOD_DISP_OVL0 9
> +#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
> +#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
> +#define MT8183_MUTEX_MOD_DISP_WDMA012
> +#define MT8183_MUTEX_MOD_DISP_COLOR0 13
> +#define MT8183_MUTEX_MOD_DISP_CCORR0 14
> +#define MT8183_MUTEX_MOD_DISP_AAL0 15
> +#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
> +#define MT8183_MUTEX_MOD_DISP_DITHER0 17
> +
> #define MT8173_MUTEX_MOD_DISP_OVL0 11
> #define MT8173_MUTEX_MOD_DISP_OVL1 12
> #define MT8173_MUTEX_MOD_DISP_RDMA013
> @@ -89,6 +103,10 @@
> #define MT8167_MUTEX_SOF_DPI0 2
> #define MT8167_MUTEX_SOF_DPI1 3
>
> +#define MT8183_MUTEX_SOF_DPI0 2
> +#define MT8183_MUTEX_EOF_DSI0 (MUTEX_SOF_DSI0 << 6)
> +#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
> +
>
> struct mtk_disp_mutex {
> int id;
> @@ -183,6 +201,20 @@ struct mtk_ddp {
> [DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
> };
>
> +static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
> + [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
> + [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
> + [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
> + [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
> + [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
> + [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
> +};
> +
> static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
> @@ -200,6 +232,12 @@ struct mtk_ddp {
> [DDP_MUTEX_SOF_DPI1] = MT8167_MUTEX_SOF_DPI1,
> };
>
> +static const unsigned int mt8183_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
> + [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
> + [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
> + [DDP_MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
According to discussion in [1], add comment for the odd EOF setting.
[1]
https://patchwork.kernel.org/project/linux-mediatek/patch/1595469798-3824-8-git-send-email-yongqiang@mediatek.com/
Regards,
Chun-Kuang.
> +};
> +
> static const struct mtk_ddp_data mt2701_ddp_driver_data = {
> .mutex_mod = mt2701_mutex_mod,
> .mutex_sof = mt2712_mutex_sof,
> @@ -229,6 +267,14 @@ struct mtk_ddp {
> .mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
> };
>
> +static const struct mtk_ddp_data mt8183_ddp_driver_data = {
> + .mutex_mod = mt8183_mutex_mod,
> + .mutex_sof = mt8183_mutex_sof,
> + .mutex_mod_reg = MT8183_DISP_MUTEX0_MOD0,
> + .mutex_sof_reg = MT8183_DISP_MUTEX0_SOF0,
> + .no_clk = true,
> +};
> +
> struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int
> id)
> {
> struct mtk_ddp *ddp = dev_get_drvdata(dev);
> @@ -449,6 +495,8 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> .data = &mt8167_ddp_driver_data},
> { .compatible = "mediatek,mt8173-disp-mutex",
> .data = &mt8173_ddp_driver_data},
> + { .compatible = "mediatek,mt8183-disp-mutex",
> + .data = &mt8183_ddp_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek m
Re: [PULL] drm-intel-next
On Mon, Jan 04, 2021 at 01:10:18PM -0800, Rodrigo Vivi wrote: > Hi Dave and Daniel, > > Happy New Year. > > Here goes the first pull request targeting 5.12. > > drm-intel-next-2021-01-04: > - Display hotplug fix for gen2/gen3 (Chris) > - Remove trailing semicolon (Tom) > - Suppress display warnings for old ifwi presend on our CI (Chris) > - OA/Perf related workaround (Lionel) > - Replace I915_READ/WRITE per new uncore and display read/write functions > (Jani)\ > . > - PSR improvements (Jose) > - HDR and other color changes on LSPCON (Uma, Ville) > - FBC fixes for TGL (Uma) > - Record plane update times for debugging (Chris) > - Refactor panel backlight control functions (Dave) > - Display power improvements (Imre) > - Add VRR register definition (Manasi) > - Atomic modeset improvements for bigjoiner pipes (Ville) > - Switch off the scanout during driver unregister (Chris) > - Clean-up DP's FEW enable (Manasi) > - Fix VDSCP slice count (Manasi) > - Fix and clean up around rc_model_size for DSC (Jani) > - Remove Type-C noisy debug warn message (Sean) > - Display HPD code clean-up (Ville) > - Refactor Intel Display (Dave) > - Start adding support for Intel's eDP backlight controls (Lyude) Pulled, thanks. -Daniel > > Thanks, > Rodrigo. > > The following changes since commit b3bf99daaee96a141536ce5c60a0d6dba6ec1d23: > > drm/i915/display: Defer initial modeset until after GGTT is initialised > (2020-11-26 11:01:52 +) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-01-04 > > for you to fetch changes up to b3304591f14b437b6bccd8dbff06006c11837031: > > drm/i915/dp: Track pm_qos per connector (2020-12-30 21:22:55 +) > > > - Display hotplug fix for gen2/gen3 (Chris) > - Remove trailing semicolon (Tom) > - Suppress display warnings for old ifwi presend on our CI (Chris) > - OA/Perf related workaround (Lionel) > - Replace I915_READ/WRITE per new uncore and display read/write functions > (Jani)\ > . > - PSR improvements (Jose) > - HDR and other color changes on LSPCON (Uma, Ville) > - FBC fixes for TGL (Uma) > - Record plane update times for debugging (Chris) > - Refactor panel backlight control functions (Dave) > - Display power improvements (Imre) > - Add VRR register definition (Manasi) > - Atomic modeset improvements for bigjoiner pipes (Ville) > - Switch off the scanout during driver unregister (Chris) > - Clean-up DP's FEW enable (Manasi) > - Fix VDSCP slice count (Manasi) > - Fix and clean up around rc_model_size for DSC (Jani) > - Remove Type-C noisy debug warn message (Sean) > - Display HPD code clean-up (Ville) > - Refactor Intel Display (Dave) > - Start adding support for Intel's eDP backlight controls (Lyude) > > > Chris Wilson (6): > Revert "drm/i915: re-order if/else ladder for hpd_irq_setup" > drm/i915/display: Suppress "Combo PHY A HW state changed unexpectedly" > drm/i915/display: Record the plane update times for debugging > drm/i915/gem: Spring clean debugfs > drm/i915: Disable outputs during unregister > drm/i915/dp: Track pm_qos per connector > > Dave Airlie (6): > drm/i915: refactor panel backlight control functions. (v2) > drm/i915/display: move needs_modeset to an inline in header > drm/i915/display: move to_intel_frontbuffer to header > drm/i915/display: fix misused comma > drm/i915: refactor cursor code out of i915_display.c > drm/i915: refactor i915 plane code into separate file. > > Imre Deak (10): > drm/i915: Use CRTC index consistently during getting/putting CRTC power > domains > drm/i915: Factor out helpers to get/put a set of tracked power domains > drm/i915: Track power references taken for enabled CRTCs > drm/i915/ddi: Track power reference taken for encoder DDI IO use > drm/i915/ddi: Track power reference taken for encoder main lane AUX use > drm/i915: Track power reference taken for eDP VDD > drm/i915: Rename power_domains.wakeref to init_wakeref > drm/i915: Track power reference taken to disable power well > functionality > drm/i915: Make intel_display_power_put_unchecked() an internal-only > function > drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout > > Jani Nikula (15): > drm/i915/debugfs: remove RPS autotuning details from i915_rps_boost_info > drm/i915: remove last traces of I915_READ_FW() and I915_WRITE_FW() > drm/i915/cdclk: prefer intel_de_write() over I915_WRITE() > drm/i915/debugfs: remove the i915_cache_sharing debugfs file > drm/i915/debugfs: replace I915_READ() with intel_uncore_read() > drm/i915/suspend: replace I915_READ()/WRITE() with > intel_de_read()/write() > drm/i915/pm: replace I915_READ()/WRITE() with > intel_uncore_read()/write() >
[PATCH 2/2] drm/imx: ipuv3-plane: add color encoding and range properties
Add COLOR_ENCODING and COLOR_RANGE plane properties and use them to
control the DP CSC matrix.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 44 +--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index d77210043fe2..7909156d3a78 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -284,6 +284,8 @@ static void ipu_plane_state_reset(struct drm_plane *plane)
__drm_atomic_helper_plane_reset(plane, &ipu_state->base);
ipu_state->base.zpos = zpos;
ipu_state->base.normalized_zpos = zpos;
+ ipu_state->base.color_encoding = DRM_COLOR_YCBCR_BT601;
+ ipu_state->base.color_range = DRM_COLOR_YCBCR_LIMITED_RANGE;
}
}
@@ -589,6 +591,25 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
fb->modifier, &eba);
}
+ if (!old_state->fb ||
+ old_state->fb->format->format != fb->format->format ||
+ old_state->color_encoding != state->color_encoding ||
+ old_state->color_range != state->color_range) {
+ ics = ipu_drm_fourcc_to_colorspace(fb->format->format);
+ switch (ipu_plane->dp_flow) {
+ case IPU_DP_FLOW_SYNC_BG:
+ ipu_dp_setup_channel(ipu_plane->dp,
state->color_encoding,
+state->color_range, ics,
+IPUV3_COLORSPACE_RGB);
+ break;
+ case IPU_DP_FLOW_SYNC_FG:
+ ipu_dp_setup_channel(ipu_plane->dp,
state->color_encoding,
+state->color_range, ics,
+IPUV3_COLORSPACE_UNKNOWN);
+ break;
+ }
+ }
+
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
/* nothing to do if PRE is used */
if (ipu_state->use_pre)
@@ -605,20 +626,6 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
return;
}
- ics = ipu_drm_fourcc_to_colorspace(fb->format->format);
- switch (ipu_plane->dp_flow) {
- case IPU_DP_FLOW_SYNC_BG:
- ipu_dp_setup_channel(ipu_plane->dp, DRM_COLOR_YCBCR_BT601,
-DRM_COLOR_YCBCR_LIMITED_RANGE, ics,
-IPUV3_COLORSPACE_RGB);
- break;
- case IPU_DP_FLOW_SYNC_FG:
- ipu_dp_setup_channel(ipu_plane->dp, DRM_COLOR_YCBCR_BT601,
-DRM_COLOR_YCBCR_LIMITED_RANGE, ics,
-IPUV3_COLORSPACE_UNKNOWN);
- break;
- }
-
ipu_dmfc_config_wait4eot(ipu_plane->dmfc, drm_rect_width(dst));
width = drm_rect_width(&state->src) >> 16;
@@ -859,6 +866,15 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev,
struct ipu_soc *ipu,
if (ret)
return ERR_PTR(ret);
+ ret = drm_plane_create_color_properties(&ipu_plane->base,
+ BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709),
+ BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
+ DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_LIMITED_RANGE);
+ if (ret)
+ return ERR_PTR(ret);
+
ret = ipu_plane_get_resources(dev, ipu_plane);
if (ret) {
DRM_ERROR("failed to get %s plane resources: %pe\n",
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] gpu: ipu-v3: Add Rec.709 limited range support to DP
Add YCbCr encoding and quantization range parameters to
ipu_dp_setup_channel() and configure the CSC DP matrix
accordingly.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 9 ++---
drivers/gpu/ipu-v3/ipu-dp.c | 25 ++---
include/video/imx-ipu-v3.h| 2 ++
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 075508051b5f..d77210043fe2 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -608,11 +608,14 @@ static void ipu_plane_atomic_update(struct drm_plane
*plane,
ics = ipu_drm_fourcc_to_colorspace(fb->format->format);
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
- ipu_dp_setup_channel(ipu_plane->dp, ics, IPUV3_COLORSPACE_RGB);
+ ipu_dp_setup_channel(ipu_plane->dp, DRM_COLOR_YCBCR_BT601,
+DRM_COLOR_YCBCR_LIMITED_RANGE, ics,
+IPUV3_COLORSPACE_RGB);
break;
case IPU_DP_FLOW_SYNC_FG:
- ipu_dp_setup_channel(ipu_plane->dp, ics,
- IPUV3_COLORSPACE_UNKNOWN);
+ ipu_dp_setup_channel(ipu_plane->dp, DRM_COLOR_YCBCR_BT601,
+DRM_COLOR_YCBCR_LIMITED_RANGE, ics,
+IPUV3_COLORSPACE_UNKNOWN);
break;
}
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 8f67e985f26a..6a558205db96 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include "ipu-prv.h"
@@ -125,6 +126,8 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, u16
y_pos)
EXPORT_SYMBOL_GPL(ipu_dp_set_window_pos);
static void ipu_dp_csc_init(struct ipu_flow *flow,
+ enum drm_color_encoding ycbcr_enc,
+ enum drm_color_range range,
enum ipu_color_space in,
enum ipu_color_space out,
u32 place)
@@ -148,7 +151,18 @@ static void ipu_dp_csc_init(struct ipu_flow *flow,
flow->base + DP_CSC_0);
writel(0x200 | (2 << 14) | (0x200 << 16) | (2 << 30),
flow->base + DP_CSC_1);
+ } else if (ycbcr_enc == DRM_COLOR_YCBCR_BT709) {
+ /* Rec.709 limited range */
+ writel(0x095 | (0x000 << 16), flow->base + DP_CSC_A_0);
+ writel(0x0e5 | (0x095 << 16), flow->base + DP_CSC_A_1);
+ writel(0x3e5 | (0x3bc << 16), flow->base + DP_CSC_A_2);
+ writel(0x095 | (0x10e << 16), flow->base + DP_CSC_A_3);
+ writel(0x000 | (0x3e10 << 16) | (1 << 30),
+ flow->base + DP_CSC_0);
+ writel(0x09a | (1 << 14) | (0x3dbe << 16) | (1 << 30),
+ flow->base + DP_CSC_1);
} else {
+ /* BT.601 limited range */
writel(0x095 | (0x000 << 16), flow->base + DP_CSC_A_0);
writel(0x0cc | (0x095 << 16), flow->base + DP_CSC_A_1);
writel(0x3ce | (0x398 << 16), flow->base + DP_CSC_A_2);
@@ -165,6 +179,8 @@ static void ipu_dp_csc_init(struct ipu_flow *flow,
}
int ipu_dp_setup_channel(struct ipu_dp *dp,
+ enum drm_color_encoding ycbcr_enc,
+ enum drm_color_range range,
enum ipu_color_space in,
enum ipu_color_space out)
{
@@ -183,7 +199,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
* foreground and background are of same colorspace, put
* colorspace converter after combining unit.
*/
- ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
+ ipu_dp_csc_init(flow, ycbcr_enc, range,
+ flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
@@ -192,10 +209,12 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
* foreground identical to output, apply color
* conversion on background
*/
- ipu_dp_csc_init(flow, flow->background.in_cs,
+ ipu_dp_csc_init(flow, ycbcr_enc, range,
+ flow->background.in_cs,
flow->out_cs, DP_COM_CONF_CSC_DEF_BG);
else
- ipu_dp_csc_init(flow, flow->foreground.in_cs,
+ ipu_dp_csc_init(flow, ycbcr_enc, range,
+ flow->foreground.in_cs,
flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
Re: [PATCH] drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence
Hi,
On 11/24/20 4:49 PM, Ville Syrjälä wrote:
> On Wed, Nov 18, 2020 at 01:40:58PM +0100, Hans de Goede wrote:
>> Commit 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
>> added an intel_dsi_msleep() helper which skips sleeping if the
>> MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
>> and it moved a bunch of msleep-s over to this new helper.
>>
>> This was based on my reading of the big comment around line 730 which
>> starts with "Panel enable/disable sequences from the VBT spec.",
>> where the "v3 video mode seq" column does not have any wait t# entries.
>>
>> Given that this code has been used on a lot of different devices without
>> issues until now, it seems that my interpretation of the spec here is
>> mostly correct.
>>
>> But now I have encountered one device, an Acer Aspire Switch 10 E
>> SW3-016, where the panel will not light up unless we do actually honor the
>> panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
>>
>> What seems to set this model apart is that it is lacking a
>> MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
>> delay usually happens.
>>
>> Fix the panel not lighting up on this model by using an unconditional
>> msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
>> no MIPI_SEQ_DEASSERT_RESET sequence.
>>
>> Fixes: 25b4620ee822 ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/vlv_dsi.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> index 194c239ab6b1..ef673277b36d 100644
>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> @@ -816,10 +816,14 @@ static void intel_dsi_pre_enable(struct
>> intel_atomic_state *state,
>> intel_dsi_prepare(encoder, pipe_config);
>>
>> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>> -intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>>
>> -/* Deassert reset */
>> -intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> +if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
>> +intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>> +/* Deassert reset */
>> +intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> +} else {
>> +msleep(intel_dsi->panel_on_delay);
>> +}
>
> Could perhaps use a comment ot explain to the reader what's going on.
>
> Looks sane enough to me, and if we get this wrong we just get a bigger
> delay than necessary I guess. So mostly harmless.
>
> Reviewed-by: Ville Syrjälä
Thank you, and sorry for being slow with getting around to
pushing this to drm-intel-next.
I've just pushed it to drm-intel-next with a comment added above the if
(and dropped the single line comment inside the if), so this now
looks like this:
/*
* Give the panel time to power-on and then deassert its reset.
* Depending on the VBT MIPI sequences version the deassert-seq
* may contain the necessary delay, intel_dsi_msleep() will skip
* the delay in that case. If there is no deassert-seq, then an
* unconditional msleep is used to give the panel time to power-on.
*/
if (dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
} else {
msleep(intel_dsi->panel_on_delay);
}
(the code is unchanged from when you reviewed it).
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 32/35] drm/amdgpu: enable retry fault wptr overflow
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Philip Yang
If xnack is on, VM retry fault interrupt send to IH ring1, and ring1
will be full quickly. IH cannot receive other interrupts, this causes
deadlock if migrating buffer using sdma and waiting for sdma done while
handling retry fault.
Remove VMC from IH storm client, enable ring1 write pointer overflow,
then IH will drop retry fault interrupts and be able to receive other
interrupts while driver is handling retry fault.
IH ring1 write pointer doesn't writeback to memory by IH, and ring1
write pointer recorded by self-irq is not updated, so always read
the latest ring1 write pointer from register.
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 32 +-
drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 32 +-
2 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
index 88626d83e07b..ca8efa5c6978 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c
@@ -220,10 +220,8 @@ static int vega10_ih_enable_ring(struct amdgpu_device
*adev,
tmp = vega10_ih_rb_cntl(ih, tmp);
if (ih == &adev->irq.ih)
tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, RPTR_REARM,
!!adev->irq.msi_enabled);
- if (ih == &adev->irq.ih1) {
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_ENABLE, 0);
+ if (ih == &adev->irq.ih1)
tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, RB_FULL_DRAIN_ENABLE, 1);
- }
if (amdgpu_sriov_vf(adev)) {
if (psp_reg_program(&adev->psp, ih_regs->psp_reg_id, tmp)) {
dev_err(adev->dev, "PSP program IH_RB_CNTL failed!\n");
@@ -265,7 +263,6 @@ static int vega10_ih_irq_init(struct amdgpu_device *adev)
u32 ih_chicken;
int ret;
int i;
- u32 tmp;
/* disable irqs */
ret = vega10_ih_toggle_interrupts(adev, false);
@@ -291,15 +288,6 @@ static int vega10_ih_irq_init(struct amdgpu_device *adev)
}
}
- tmp = RREG32_SOC15(OSSSYS, 0, mmIH_STORM_CLIENT_LIST_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_STORM_CLIENT_LIST_CNTL,
- CLIENT18_IS_STORM_CLIENT, 1);
- WREG32_SOC15(OSSSYS, 0, mmIH_STORM_CLIENT_LIST_CNTL, tmp);
-
- tmp = RREG32_SOC15(OSSSYS, 0, mmIH_INT_FLOOD_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_INT_FLOOD_CNTL, FLOOD_CNTL_ENABLE, 1);
- WREG32_SOC15(OSSSYS, 0, mmIH_INT_FLOOD_CNTL, tmp);
-
pci_set_master(adev->pdev);
/* enable interrupts */
@@ -345,11 +333,17 @@ static u32 vega10_ih_get_wptr(struct amdgpu_device *adev,
u32 wptr, tmp;
struct amdgpu_ih_regs *ih_regs;
- wptr = le32_to_cpu(*ih->wptr_cpu);
- ih_regs = &ih->ih_regs;
+ if (ih == &adev->irq.ih) {
+ /* Only ring0 supports writeback. On other rings fall back
+* to register-based code with overflow checking below.
+*/
+ wptr = le32_to_cpu(*ih->wptr_cpu);
- if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
- goto out;
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+ }
+
+ ih_regs = &ih->ih_regs;
/* Double check that the overflow wasn't already cleared. */
wptr = RREG32_NO_KIQ(ih_regs->ih_rb_wptr);
@@ -440,15 +434,11 @@ static int vega10_ih_self_irq(struct amdgpu_device *adev,
struct amdgpu_irq_src *source,
struct amdgpu_iv_entry *entry)
{
- uint32_t wptr = cpu_to_le32(entry->src_data[0]);
-
switch (entry->ring_id) {
case 1:
- *adev->irq.ih1.wptr_cpu = wptr;
schedule_work(&adev->irq.ih1_work);
break;
case 2:
- *adev->irq.ih2.wptr_cpu = wptr;
schedule_work(&adev->irq.ih2_work);
break;
default: break;
diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
index 42032ca380cc..60d1bd51781e 100644
--- a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
@@ -220,10 +220,8 @@ static int vega20_ih_enable_ring(struct amdgpu_device
*adev,
tmp = vega20_ih_rb_cntl(ih, tmp);
if (ih == &adev->irq.ih)
tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, RPTR_REARM,
!!adev->irq.msi_enabled);
- if (ih == &adev->irq.ih1) {
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_ENABLE, 0);
+ if (ih == &adev->irq.ih1)
tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, RB_FULL_DRAIN_ENABLE, 1);
- }
if (amdgpu_sriov_vf(adev)) {
if (psp_reg_program(&adev->psp, ih_regs->psp_reg_id, tmp)) {
d
Re: [PATCH 31/35] drm/amdgpu: reserve fence slot to update page table
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Philip Yang
Forgot to reserve a fence slot to use sdma to update page table, cause
below kernel BUG backtrace to handle vm retry fault while application is
exiting.
[ 133.048143] kernel BUG at
/home/yangp/git/compute_staging/kernel/drivers/dma-buf/dma-resv.c:281!
[ 133.048487] Workqueue: events amdgpu_irq_handle_ih1 [amdgpu]
[ 133.048506] RIP: 0010:dma_resv_add_shared_fence+0x204/0x280
[ 133.048672] amdgpu_vm_sdma_commit+0x134/0x220 [amdgpu]
[ 133.048788] amdgpu_vm_bo_update_range+0x220/0x250 [amdgpu]
[ 133.048905] amdgpu_vm_handle_fault+0x202/0x370 [amdgpu]
[ 133.049031] gmc_v9_0_process_interrupt+0x1ab/0x310 [amdgpu]
[ 133.049165] ? kgd2kfd_interrupt+0x9a/0x180 [amdgpu]
[ 133.049289] ? amdgpu_irq_dispatch+0xb6/0x240 [amdgpu]
[ 133.049408] amdgpu_irq_dispatch+0xb6/0x240 [amdgpu]
[ 133.049534] amdgpu_ih_process+0x9b/0x1c0 [amdgpu]
[ 133.049657] amdgpu_irq_handle_ih1+0x21/0x60 [amdgpu]
[ 133.049669] process_one_work+0x29f/0x640
[ 133.049678] worker_thread+0x39/0x3f0
[ 133.049685] ? process_one_work+0x640/0x640
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index abdd4e7b4c3b..bd9de870f8f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3301,7 +3301,7 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev,
unsigned int pasid,
struct amdgpu_bo *root;
uint64_t value, flags;
struct amdgpu_vm *vm;
- long r;
+ int r;
bool is_compute_context = false;
spin_lock(&adev->vm_manager.pasid_lock);
@@ -3359,6 +3359,12 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev,
unsigned int pasid,
value = 0;
}
+ r = dma_resv_reserve_shared(root->tbo.base.resv, 1);
+ if (r) {
+ pr_debug("failed %d to reserve fence slot\n", r);
+ goto error_unlock;
+ }
+
r = amdgpu_vm_bo_update_mapping(adev, adev, vm, true, false, NULL, addr,
addr, flags, value, NULL, NULL,
NULL);
@@ -3370,7 +3376,7 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev,
unsigned int pasid,
error_unlock:
amdgpu_bo_unreserve(root);
if (r < 0)
- DRM_ERROR("Can't handle page fault (%ld)\n", r);
+ DRM_ERROR("Can't handle page fault (%d)\n", r);
error_unref:
amdgpu_bo_unref(&root);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 29/35] drm/amdgpu: svm bo enable_signal call condition
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Alex Sierra
[why]
To support svm bo eviction mechanism.
[how]
If the BO crated has AMDGPU_AMDKFD_CREATE_SVM_BO flag set,
enable_signal callback will be called inside amdgpu_evict_flags.
This also causes gutting of the BO by removing all placements,
so that TTM won't actually do an eviction. Instead it will discard
the memory held by the BO. This is needed for HMM migration to user
mode system memory pages.
I don't think that this will work. What exactly are you doing here?
As Daniel pointed out HMM and dma_fences are fundamentally incompatible.
Christian.
Signed-off-by: Alex Sierra
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index f423f42cb9b5..62d4da95d22d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -107,6 +107,20 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
*bo,
}
abo = ttm_to_amdgpu_bo(bo);
+ if (abo->flags & AMDGPU_AMDKFD_CREATE_SVM_BO) {
+ struct dma_fence *fence;
+ struct dma_resv *resv = &bo->base._resv;
+
+ rcu_read_lock();
+ fence = rcu_dereference(resv->fence_excl);
+ if (fence && !fence->ops->signaled)
+ dma_fence_enable_sw_signaling(fence);
+
+ placement->num_placement = 0;
+ placement->num_busy_placement = 0;
+ rcu_read_unlock();
+ return;
+ }
switch (bo->mem.mem_type) {
case AMDGPU_PL_GDS:
case AMDGPU_PL_GWS:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/35] drm/amdgpu: export vm update mapping interface
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Philip Yang
It will be used by kfd to map svm range to GPU, because svm range does
not have amdgpu_bo and bo_va, cannot use amdgpu_bo_update interface, use
amdgpu vm update interface directly.
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 -
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 10 ++
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index fdbe7d4e8b8b..9c557e8bf0e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1589,15 +1589,14 @@ static int amdgpu_vm_update_ptes(struct
amdgpu_vm_update_params *params,
* Returns:
* 0 for success, -EINVAL for failure.
*/
-static int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
- struct amdgpu_device *bo_adev,
- struct amdgpu_vm *vm, bool immediate,
- bool unlocked, struct dma_resv *resv,
- uint64_t start, uint64_t last,
- uint64_t flags, uint64_t offset,
- struct drm_mm_node *nodes,
- dma_addr_t *pages_addr,
- struct dma_fence **fence)
+int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
+ struct amdgpu_device *bo_adev,
+ struct amdgpu_vm *vm, bool immediate,
+ bool unlocked, struct dma_resv *resv,
+ uint64_t start, uint64_t last, uint64_t flags,
+ uint64_t offset, struct drm_mm_node *nodes,
+ dma_addr_t *pages_addr,
+ struct dma_fence **fence)
{
struct amdgpu_vm_update_params params;
enum amdgpu_sync_mode sync_mode;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 2bf4ef5fb3e1..73ca630520fd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -366,6 +366,8 @@ struct amdgpu_vm_manager {
spinlock_t pasid_lock;
};
+struct amdgpu_bo_va_mapping;
+
#define amdgpu_vm_copy_pte(adev, ib, pe, src, count)
((adev)->vm_manager.vm_pte_funcs->copy_pte((ib), (pe), (src), (count)))
#define amdgpu_vm_write_pte(adev, ib, pe, value, count, incr)
((adev)->vm_manager.vm_pte_funcs->write_pte((ib), (pe), (value), (count),
(incr)))
#define amdgpu_vm_set_pte_pde(adev, ib, pe, addr, count, incr, flags)
((adev)->vm_manager.vm_pte_funcs->set_pte_pde((ib), (pe), (addr), (count),
(incr), (flags)))
@@ -397,6 +399,14 @@ int amdgpu_vm_clear_freed(struct amdgpu_device *adev,
struct dma_fence **fence);
int amdgpu_vm_handle_moved(struct amdgpu_device *adev,
struct amdgpu_vm *vm);
+int amdgpu_vm_bo_update_mapping(struct amdgpu_device *adev,
+ struct amdgpu_device *bo_adev,
+ struct amdgpu_vm *vm, bool immediate,
+ bool unlocked, struct dma_resv *resv,
+ uint64_t start, uint64_t last, uint64_t flags,
+ uint64_t offset, struct drm_mm_node *nodes,
+ dma_addr_t *pages_addr,
+ struct dma_fence **fence);
int amdgpu_vm_bo_update(struct amdgpu_device *adev,
struct amdgpu_bo_va *bo_va,
bool clear);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/35] drm/amdgpu: add common HMM get pages function
Am 07.01.21 um 04:01 schrieb Felix Kuehling:
From: Philip Yang
Move the HMM get pages function from amdgpu_ttm and to amdgpu_mn. This
common function will be used by new svm APIs.
Signed-off-by: Philip Yang
Signed-off-by: Felix Kuehling
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 83 +
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 76 +++---
3 files changed, 100 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 828b5167ff12..997da4237a10 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -155,3 +155,86 @@ void amdgpu_mn_unregister(struct amdgpu_bo *bo)
mmu_interval_notifier_remove(&bo->notifier);
bo->notifier.mm = NULL;
}
+
+int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier *notifier,
+ struct mm_struct *mm, struct page **pages,
+ uint64_t start, uint64_t npages,
+ struct hmm_range **phmm_range, bool readonly,
+ bool mmap_locked)
+{
+ struct hmm_range *hmm_range;
+ unsigned long timeout;
+ unsigned long i;
+ unsigned long *pfns;
+ int r = 0;
+
+ hmm_range = kzalloc(sizeof(*hmm_range), GFP_KERNEL);
+ if (unlikely(!hmm_range))
+ return -ENOMEM;
+
+ pfns = kvmalloc_array(npages, sizeof(*pfns), GFP_KERNEL);
+ if (unlikely(!pfns)) {
+ r = -ENOMEM;
+ goto out_free_range;
+ }
+
+ hmm_range->notifier = notifier;
+ hmm_range->default_flags = HMM_PFN_REQ_FAULT;
+ if (!readonly)
+ hmm_range->default_flags |= HMM_PFN_REQ_WRITE;
+ hmm_range->hmm_pfns = pfns;
+ hmm_range->start = start;
+ hmm_range->end = start + npages * PAGE_SIZE;
+ timeout = jiffies + msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
+
+retry:
+ hmm_range->notifier_seq = mmu_interval_read_begin(notifier);
+
+ if (likely(!mmap_locked))
+ mmap_read_lock(mm);
+
+ r = hmm_range_fault(hmm_range);
+
+ if (likely(!mmap_locked))
+ mmap_read_unlock(mm);
+ if (unlikely(r)) {
+ /*
+* FIXME: This timeout should encompass the retry from
+* mmu_interval_read_retry() as well.
+*/
+ if (r == -EBUSY && !time_after(jiffies, timeout))
+ goto retry;
+ goto out_free_pfns;
+ }
+
+ /*
+* Due to default_flags, all pages are HMM_PFN_VALID or
+* hmm_range_fault() fails. FIXME: The pages cannot be touched outside
+* the notifier_lock, and mmu_interval_read_retry() must be done first.
+*/
+ for (i = 0; pages && i < npages; i++)
+ pages[i] = hmm_pfn_to_page(pfns[i]);
+
+ *phmm_range = hmm_range;
+
+ return 0;
+
+out_free_pfns:
+ kvfree(pfns);
+out_free_range:
+ kfree(hmm_range);
+
+ return r;
+}
+
+int amdgpu_hmm_range_get_pages_done(struct hmm_range *hmm_range)
+{
+ int r;
+
+ r = mmu_interval_read_retry(hmm_range->notifier,
+ hmm_range->notifier_seq);
+ kvfree(hmm_range->hmm_pfns);
+ kfree(hmm_range);
+
+ return r;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
index a292238f75eb..7f7d37a457c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
@@ -30,6 +30,13 @@
#include
#include
+int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier *notifier,
+ struct mm_struct *mm, struct page **pages,
+ uint64_t start, uint64_t npages,
+ struct hmm_range **phmm_range, bool readonly,
+ bool mmap_locked);
+int amdgpu_hmm_range_get_pages_done(struct hmm_range *hmm_range);
+
#if defined(CONFIG_HMM_MIRROR)
int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned long addr);
void amdgpu_mn_unregister(struct amdgpu_bo *bo);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index aaad9e304ad9..f423f42cb9b5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -32,7 +32,6 @@
#include
#include
-#include
#include
#include
#include
@@ -843,10 +842,8 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
struct page **pages)
struct amdgpu_ttm_tt *gtt = (void *)ttm;
unsigned long start = gtt->userptr;
struct vm_area_struct *vma;
- struct hmm_range *range;
- unsigned long timeout;
struct mm_struct *mm;
- unsigned long i;
+ bool readonly;
Re: [PATCH v3 8/8] drm: Upcast struct drm_device.dev to struct pci_device; replace pdev
AFAICT these are false positives. The instances have been fixed already. Am 07.01.21 um 10:45 schrieb kernel test robot: Hi Thomas, I love your patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next linus/master v5.11-rc2 next-20210104] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: x86_64-randconfig-s021-20210107 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://github.com/0day-ci/linux/commit/380912f7b62c23322562c40e19efd7ad84d57e9c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Thomas-Zimmermann/drm-Move-struct-drm_device-pdev-to-legacy/20210107-161007 git checkout 380912f7b62c23322562c40e19efd7ad84d57e9c # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/oaktrail_device.c: In function 'oaktrail_chip_setup': drivers/gpu/drm/gma500/oaktrail_device.c:509:26: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 509 | if (pci_enable_msi(dev->pdev)) | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds.c: In function 'oaktrail_lvds_set_power': drivers/gpu/drm/gma500/oaktrail_lvds.c:63:25: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 63 | pm_request_idle(&dev->pdev->dev); | ^~~~ | dev -- drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_clock': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:69:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 69 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'get_data': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:83:11: warning: variable 'tmp' set but not used [-Wunused-but-set-variable] 83 | u32 val, tmp; | ^~~ drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c: In function 'oaktrail_lvds_i2c_init': drivers/gpu/drm/gma500/oaktrail_lvds_i2c.c:148:35: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 148 | chan->adapter.dev.parent = &dev->pdev->dev; | ^~~~ | dev -- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load': drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:661:22: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 661 | pci_set_master(dev->pdev); | ^~~~ | dev In file included from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:31: drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:47: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 690 | dev_priv->io_start = pci_resource_start(dev->pdev, 0); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) |^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:691:49: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 691 | dev_priv->vram_start = pci_resource_start(dev->pdev, 1); | ^~~~ include/linux/pci.h:1854:40: note: in definition of macro 'pci_resource_start' 1854 | #define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start) |^~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:692:49: error: 'struct drm_device' has no member named 'pdev'; did you mean 'dev'? 692 | dev_priv->mmio_start = pci_resource_start(dev->pdev, 2); |
Re: [PATCH v9, 08/11] drm/mediatek: add has_dither private data for gamma
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月7日 週四 上午11:12寫道：
>
> not all SoC has dither function in gamma module
> dd private data to control this function setting
'add' ?
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> index 8501821..4eab82a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -24,7 +24,7 @@
> #define LUT_10BIT_MASK 0x03ff
>
> struct mtk_disp_gamma_data {
> - u32 reserved;
> + bool has_dither;
> };
>
> /**
> @@ -72,7 +72,8 @@ static void mtk_gamma_config(struct mtk_ddp_comp *comp,
> unsigned int w,
>
> mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_GAMMA_SIZE);
>
> - mtk_dither_set(comp, bpc, DISP_GAMMA_CFG, cmdq_pkt);
> + if (gamma->data && gamma->data->has_dither)
> + mtk_dither_set(comp, bpc, DISP_GAMMA_CFG, cmdq_pkt);
> }
>
> static void mtk_gamma_start(struct mtk_ddp_comp *comp)
> @@ -168,8 +169,13 @@ static int mtk_disp_gamma_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct mtk_disp_gamma_data mt8173_gamma_driver_data = {
> + .has_dither = true,
> +};
> +
> static const struct of_device_id mtk_disp_gamma_driver_dt_match[] = {
> - { .compatible = "mediatek,mt8173-disp-gamma"},
> + { .compatible = "mediatek,mt8173-disp-gamma",
> + .data = &mt8173_gamma_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_gamma_driver_dt_match);
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings
Hi Daniel
Am 11.12.20 um 10:50 schrieb Daniel Vetter:
[...]
+/**
+ * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
+ * store.
+ *
+ * This function makes sure that a contiguous kernel virtual address mapping
+ * exists for the buffer backing the shmem GEM object.
+ *
+ * The function is called with the BO's reservation object locked. Callers must
+ * hold the lock until after unmapping the buffer.
+ *
+ * This function can be used to implement &drm_gem_object_funcs.vmap_local. But
+ * it can also be called by drivers directly, in which case it will hide the
+ * differences between dma-buf imported and natively allocated objects.
+ *
+ * Acquired mappings should be cleaned up by calling
drm_gem_shmem_vunmap_local().
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_gem_shmem_vmap_local(struct drm_gem_object *obj, struct dma_buf_map
*map)
+{
+ struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+ int ret;
+
+ dma_resv_assert_held(obj->resv);
+
+ ret = mutex_lock_interruptible(&shmem->vmap_lock);
This bites. You need to check for shmem->import_attach and call
dma_buf_vmap_local directly here before you take any shmem helper locks.
Real fix would be to replace both vmap_lock and pages_lock with dma_resv
lock, but that's more work. Same for vunmap_local
This comment confuses me. AFAICT vmap_lock protects vmap_use_count. Why
does this exact code work in drm_gem_shmem_vmap() but not in _local() ?
Best regards
Thomas
With that fixed on the helper part of this patch:
Reviewed-by: Daniel Vetter
+ if (ret)
+ return ret;
+ ret = drm_gem_shmem_vmap_locked(shmem, map);
+ mutex_unlock(&shmem->vmap_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_shmem_vmap_local);
+
static void drm_gem_shmem_vunmap_locked(struct drm_gem_shmem_object *shmem,
struct dma_buf_map *map)
{
@@ -366,7 +406,7 @@ static void drm_gem_shmem_vunmap_locked(struct
drm_gem_shmem_object *shmem,
drm_gem_shmem_put_pages(shmem);
}
-/*
+/**
* drm_gem_shmem_vunmap - Unmap a virtual mapping fo a shmem GEM object
* @shmem: shmem GEM object
* @map: Kernel virtual address where the SHMEM GEM object was mapped
@@ -389,6 +429,33 @@ void drm_gem_shmem_vunmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
}
EXPORT_SYMBOL(drm_gem_shmem_vunmap);
+/**
+ * drm_gem_shmem_vunmap_local - Unmap a virtual mapping fo a shmem GEM object
+ * @shmem: shmem GEM object
+ * @map: Kernel virtual address where the SHMEM GEM object was mapped
+ *
+ * This function cleans up a kernel virtual address mapping acquired by
+ * drm_gem_shmem_vmap_local(). The mapping is only removed when the use count
+ * drops to zero.
+ *
+ * The function is called with the BO's reservation object locked.
+ *
+ * This function can be used to implement &drm_gem_object_funcs.vmap_local.
+ * But it can also be called by drivers directly, in which case it will hide
+ * the differences between dma-buf imported and natively allocated objects.
+ */
+void drm_gem_shmem_vunmap_local(struct drm_gem_object *obj, struct dma_buf_map
*map)
+{
+ struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
+
+ dma_resv_assert_held(obj->resv);
+
+ mutex_lock(&shmem->vmap_lock);
+ drm_gem_shmem_vunmap_locked(shmem, map);
+ mutex_unlock(&shmem->vmap_lock);
+}
+EXPORT_SYMBOL(drm_gem_shmem_vunmap_local);
+
struct drm_gem_shmem_object *
drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
struct drm_device *dev, size_t size,
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 1dfc42170059..a33e28d4c5e9 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1552,22 +1552,32 @@ mgag200_handle_damage(struct mga_device *mdev, struct
drm_framebuffer *fb,
struct drm_rect *clip)
{
struct drm_device *dev = &mdev->base;
+ struct drm_gem_object *obj = fb->obj[0];
struct dma_buf_map map;
void *vmap;
int ret;
- ret = drm_gem_shmem_vmap(fb->obj[0], &map);
+ ret = dma_resv_lock(obj->resv, NULL);
if (drm_WARN_ON(dev, ret))
- return; /* BUG: SHMEM BO should always be vmapped */
+ return;
+ ret = drm_gem_shmem_vmap_local(obj, &map);
+ if (drm_WARN_ON(dev, ret))
+ goto err_dma_resv_unlock; /* BUG: SHMEM BO should always be
vmapped */
vmap = map.vaddr; /* TODO: Use mapping abstraction properly */
drm_fb_memcpy_dstclip(mdev->vram, vmap, fb, clip);
- drm_gem_shmem_vunmap(fb->obj[0], &map);
+ drm_gem_shmem_vunmap_local(obj, &map);
+ dma_resv_unlock(obj->resv);
/*
Re: [GIT PULL] drm/imx: fixes and drm managed resources
On Mon, Jan 04, 2021 at 06:10:31PM +0100, Philipp Zabel wrote: > Hi Dave, Daniel, > > this PR includes the drmm encoder/plane/crtc allocation functions and > converts the imx-drm driver to use them. > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > git://git.pengutronix.de/git/pza/linux.git tags/imx-drm-next-2021-01-04 Pulled, thanks. Daniel > > for you to fetch changes up to 16da8e9a7767ac77720f49bfa870def61a250cda: > > drm/imx: ipuv3-crtc: use drm managed resources (2021-01-04 12:59:34 +0100) > > > drm/imx: fixes and drm managed resources > > - Reduce stack usage in ipu-di. > - Fix imx-ldb for compile tests. > - Make drm encoder control functions optional. > - Add drm managed variants drmm_encoder_alloc(), > drmm_simple_encoder_alloc(), drmm_universal_plane_alloc(), and > drmm_crtc_alloc_with_planes() for drm_encoder_init(), > drm_simple_encoder_init(), drm_universal_plane_init(), and > drm_crtc_init_with_planes(), respectively. > - Update imx-drm to use the new functions for drm managed resource > allocation, moving initialization from bind to probe where possible. > - Fix imx-tve clock provider leak. > > > Krzysztof Kozlowski (1): > drm/imx: depend on COMMON_CLK to fix compile tests > > Lee Jones (1): > gpu/ipu-v3/ipu-di: Strip out 2 unused 'di_sync_config' entries > > Philipp Zabel (19): > drm/encoder: make encoder control functions optional > drm: add drmm_encoder_alloc() > drm/simple_kms_helper: add drmm_simple_encoder_alloc() > drm/plane: add drmm_universal_plane_alloc() > drm/crtc: add drmm_crtc_alloc_with_planes() > drm/imx: dw_hdmi-imx: move initialization into probe > drm/imx: imx-ldb: use local connector variable > drm/imx: imx-ldb: move initialization into probe > drm/imx: imx-tve: use local encoder and connector variables > drm/imx: imx-tve: move initialization into probe > drm/imx: imx-tve: use devm_clk_register > drm/imx: parallel-display: use local bridge and connector variables > drm/imx: parallel-display: move initialization into probe > drm/imx: dw_hdmi-imx: use drm managed resources > drm/imx: imx-ldb: use drm managed resources > drm/imx: imx-tve: use drm managed resources > drm/imx: parallel-display: use drm managed resources > drm/imx: ipuv3-plane: use drm managed resources > drm/imx: ipuv3-crtc: use drm managed resources > > Zheng Yongjun (1): > gpu: drm: imx: convert comma to semicolon > > drivers/gpu/drm/drm_crtc.c | 125 ++--- > drivers/gpu/drm/drm_encoder.c | 113 +-- > drivers/gpu/drm/drm_mode_config.c | 2 +- > drivers/gpu/drm/drm_plane.c | 134 > +--- > drivers/gpu/drm/drm_simple_kms_helper.c | 14 +++- > drivers/gpu/drm/imx/Kconfig | 1 + > drivers/gpu/drm/imx/dw_hdmi-imx.c | 95 ++ > drivers/gpu/drm/imx/imx-ldb.c | 109 +++--- > drivers/gpu/drm/imx/imx-tve.c | 109 +- > drivers/gpu/drm/imx/ipuv3-crtc.c| 131 ++- > drivers/gpu/drm/imx/ipuv3-plane.c | 69 > drivers/gpu/drm/imx/ipuv3-plane.h | 3 - > drivers/gpu/drm/imx/parallel-display.c | 93 +++--- > drivers/gpu/ipu-v3/ipu-di.c | 4 - > include/drm/drm_crtc.h | 33 > include/drm/drm_encoder.h | 32 +++- > include/drm/drm_plane.h | 42 ++ > include/drm/drm_simple_kms_helper.h | 24 ++ > 18 files changed, 712 insertions(+), 421 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9, 07/11] drm/mediatek: separate gamma module
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月7日 週四 上午11:12寫道：
>
> mt8183 gamma module will different with mt8173
> separate gamma for add private data
I've applied series "Decouple Mediatek DRM sub driver" [1] into
mediatek-drm-next [2] and this patch would conflict with
mediatek-drm-next, so please rebase this series onto
mediatek-drm-next.
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=399915
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 185
>
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 58 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 192 insertions(+), 58 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_gamma.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index a892ede..17a08e2 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> mediatek-drm-y := mtk_disp_color.o \
> + mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> new file mode 100644
> index 000..8501821
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
> @@ -0,0 +1,185 @@
> +/*
> + * SPDX-License-Identifier:
> + *
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_GAMMA_EN 0x
> +#define GAMMA_EN BIT(0)
> +#define DISP_GAMMA_CFG 0x0020
> +#define GAMMA_LUT_EN BIT(1)
> +#define DISP_GAMMA_SIZE0x0030
> +#define DISP_GAMMA_LUT 0x0700
> +
> +#define LUT_10BIT_MASK 0x03ff
> +
> +struct mtk_disp_gamma_data {
> + u32 reserved;
> +};
> +
> +/**
> + * struct mtk_disp_gamma - DISP_GAMMA driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_gamma {
> + struct mtk_ddp_comp ddp_comp;
> + const struct mtk_disp_gamma_data*data;
> +};
> +
> +static inline struct mtk_disp_gamma *comp_to_gamma(struct mtk_ddp_comp *comp)
> +{
> + return container_of(comp, struct mtk_disp_gamma, ddp_comp);
> +}
> +
> +void mtk_gamma_set(struct mtk_ddp_comp *comp, struct drm_crtc_state *state)
> +{
> + unsigned int i, reg;
> + struct drm_color_lut *lut;
> + void __iomem *lut_base;
> + u32 word;
> +
> + if (state->gamma_lut) {
> + reg = readl(comp->regs + DISP_GAMMA_CFG);
> + reg = reg | GAMMA_LUT_EN;
> + writel(reg, comp->regs + DISP_GAMMA_CFG);
> + lut_base = comp->regs + DISP_GAMMA_LUT;
> + lut = (struct drm_color_lut *)state->gamma_lut->data;
> + for (i = 0; i < MTK_LUT_SIZE; i++) {
> + word = (((lut[i].red >> 6) & LUT_10BIT_MASK) << 20) +
> + (((lut[i].green >> 6) & LUT_10BIT_MASK) <<
> 10) +
> + ((lut[i].blue >> 6) & LUT_10BIT_MASK);
> + writel(word, (lut_base + i * 4));
> + }
> + }
> +}
> +
> +static void mtk_gamma_config(struct mtk_ddp_comp *comp, unsigned int w,
> +unsigned int h, unsigned int vrefresh,
> +unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_gamma *gamma = comp_to_gamma(comp);
> +
> + mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_GAMMA_SIZE);
> +
> + mtk_dither_set(comp, bpc, DISP_GAMMA_CFG, cmdq_pkt);
> +}
> +
> +static void mtk_gamma_start(struct mtk_ddp_comp *comp)
> +{
> + writel(GAMMA_EN, comp->regs + DISP_GAMMA_EN);
> +}
> +
> +static void mtk_gamma_stop(struct mtk_ddp_comp *comp)
> +{
> + writel_relaxed(0x0, comp->regs + DISP_GAMMA_EN);
> +}
> +
> +static const struct mtk_ddp_comp_funcs mtk_disp_gamma_funcs = {
> + .gamma_set = mtk_gamma_set,
> + .config = mtk_gamma_config,
> + .start = mtk_gamma_start,
> + .stop = mtk_gamma_stop,
> +};
> +
> +static int mtk_disp_gamma_bind(struct device *dev, struct device *master,
> + void *data)
> +{
>
Re: [PATCH v9, 02/11] dt-bindings: mediatek: add description for mt8183 display
Hi, Yongqiang: Yongqiang Niu 於 2021年1月7日 週四 上午11:11寫道： > > add description for mt8183 display Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Yongqiang Niu > Reviewed-by: Chun-Kuang Hu > Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > index b07881e..c562cda 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > @@ -43,7 +43,7 @@ Required properties (all function blocks): > "mediatek,-dpi" - DPI controller, see > mediatek,dpi.txt > "mediatek,-disp-mutex"- display mutex > "mediatek,-disp-od" - overdrive > - the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173. > + the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173 and mt8183. > - reg: Physical base address and length of the function block register space > - interrupts: The interrupt signal from the function block (required, except > for >merge and split function blocks). > -- > 1.8.1.1.dirty > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9, 05/11] drm/mediatek: add fifo_size into rdma private data
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月7日 週四 上午11:12寫道：
>
> Get the fifo size from device tree
> because each rdma in the same SoC may have different fifo size
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index d46b8ae..8c64d5c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -64,6 +64,7 @@ struct mtk_disp_rdma {
> struct mtk_ddp_comp ddp_comp;
> struct drm_crtc *crtc;
> const struct mtk_disp_rdma_data *data;
> + u32 fifo_size;
> };
>
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -132,12 +133,18 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> unsigned int threshold;
> unsigned int reg;
> struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + u32 rdma_fifo_size;
>
> mtk_ddp_write_mask(cmdq_pkt, width, comp,
>DISP_REG_RDMA_SIZE_CON_0, 0xfff);
> mtk_ddp_write_mask(cmdq_pkt, height, comp,
>DISP_REG_RDMA_SIZE_CON_1, 0xf);
>
> + if (rdma->fifo_size)
> + rdma_fifo_size = rdma->fifo_size;
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> +
> /*
> * Enable FIFO underflow since DSI and DPI can't be blocked.
> * Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -146,7 +153,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
> unsigned int width,
> */
> threshold = width * height * vrefresh * 4 * 7 / 100;
> reg = RDMA_FIFO_UNDERFLOW_EN |
> - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> mtk_ddp_write(cmdq_pkt, reg, comp, DISP_REG_RDMA_FIFO_CON);
> }
> @@ -292,6 +299,16 @@ static int mtk_disp_rdma_probe(struct platform_device
> *pdev)
> return comp_id;
> }
>
> + if (of_find_property(dev->of_node, "mediatek,rdma-fifo-size", &ret)) {
> + ret = of_property_read_u32(dev->of_node,
> + "mediatek,rdma-fifo-size",
> + &priv->fifo_size);
> + if (ret) {
> + dev_err(dev, "Failed to get rdma fifo size\n");
> + return ret;
> + }
> + }
> +
> ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
> &mtk_disp_rdma_funcs);
> if (ret) {
> --
> 1.8.1.1.dirty
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
