[PATCH] drm/amdgpu: enable DCN for navi10 headless SKU
From: "Tianci.Yin" There is a NULL pointer crash when DCN disabled on headless SKU. On normal SKU, the variable adev->ddev.mode_config.funcs is initialized in dm_hw_init(), and it is fine to access it in amdgpu_device_resume(). But on headless SKU, DCN is disabled, the funcs variable is not initialized, then crash arises. Enable DCN to fix this issue. Change-Id: I33bc30210e3420e60ceb59175e39855d00b05b06 Signed-off-by: Tianci.Yin --- drivers/gpu/drm/amd/amdgpu/nv.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c index e33d8022cc32..67375b2948f5 100644 --- a/drivers/gpu/drm/amd/amdgpu/nv.c +++ b/drivers/gpu/drm/amd/amdgpu/nv.c @@ -535,8 +535,7 @@ int nv_set_ip_blocks(struct amdgpu_device *adev) if (adev->enable_virtual_display || amdgpu_sriov_vf(adev)) amdgpu_device_ip_block_add(adev, _virtual_ip_block); #if defined(CONFIG_DRM_AMD_DC) - else if (amdgpu_device_has_dc_support(adev) && -!nv_is_headless_sku(adev->pdev)) + else if (amdgpu_device_has_dc_support(adev)) amdgpu_device_ip_block_add(adev, _ip_block); #endif amdgpu_device_ip_block_add(adev, _v10_0_ip_block); -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[pull] amdgpu, amdkfd, radeon amd-drm-next-5.11
Hi Dave, Daniel, Updates for 5.11. This should merge pretty cleanly. I created a backmerge branch[1] in case you run into any issues. [1] https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.11-backmerge The following changes since commit f2fa07b39fafb2a5f49c71a504862c5efa57d03e: drm/amd/amdkfd: Surface files in Sysfs to allow users to get number of compute units that are in use. (2020-09-30 15:26:27 -0400) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.11-2020-11-05 for you to fetch changes up to 514ad1b6bb6e2fa205b5511bd3d50e33457f6180: drm/amdgpu: Fix Arcturus fan speed reporting (2020-11-05 14:23:06 -0500) amd-drm-next-5.11-2020-11-05: amdgpu: - Add initial support for Vangogh - Add support for Green Sardine - Add initial support for Dimgrey Cavefish - Scatter/Gather display support for Renoir - Updates for Sienna Cichlid - Updates for Navy Flounder - SMU7 power improvements - Modifier support for gfx9+ - CI BACO fixes - Arcturus SMU fixes - Lots of code cleanups - DC fixes - Kernel doc fixes - Add more GPU HW client information to page fault error logging - MPO clock tuning for RV - FP fixes for DCN3 on ARM and PPC radeon: - Expose voltage via hwmon on Sumo APUs amdkfd: - Fix unique id handling - Misc fixes Aaron Liu (1): drm/amdgpu: enable green_sardine_asd.bin loading (v2) Alex Deucher (27): drm/amdgpu/swsmu: add interrupt work function drm/amdgpu/swsmu: add interrupt work handler for smu11 parts drm/amdgpu/gfx10: add updated register offsets for VGH drm/amdgpu: IP discovery table is not ready yet for VG drm/amdgpu/mmhub2.3: print client id string for mmhub drm/amdgpu/swsmu: fix ARC build errors drm/amdgpu: prevent spurious warning drm/amdgpu: add Green_Sardine APU flag drm/amdgpu/swsmu: clean up a bunch of stale interfaces drm/amdgpu/swsmu: init the baco mutex in early_init drm/amdgpu/display: DRM_AMD_DC_DCN3_02 depends on DRM_AMD_DC_DCN3_01 drm/amdgpu: move amdgpu_num_kcq handling to a helper drm/amdgpu/gmc10: remove dummy read workaround for newer chips drm/amdgpu: add GC 10.3 NOALLOC registers drm/amdgpu/display: use kvzalloc again in dc_create_state drm/amdgpu/swsmu: drop smu i2c bus on navi1x drm/amdgpu/pm: fix the fan speed in fan1_input in manual mode for navi1x drm/amdgpu/display: re-add surface size calculation in dcn30_hwseq.c drm/amdgpu/display: fix indentation in defer_delay_converter_wa() drm/amdgpu/powerplay: Only apply optimized mclk dpm policy on polaris drm/amdgpu/display: remove DRM_AMD_DC_GREEN_SARDINE drm/amdgpu/display: remove dal_cmd_tbl_helper_dcn2_get_table2 drm/amdgpu: drop CONFIG_DRM_AMD_DC_DCN3_01 from atomfirmware.h drm/amdgpu: allow TMZ on vangogh drm/amdgpu/display: fix warnings when CONFIG_DRM_AMD_DC_DCN is not set drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into CONFIG_DRM_AMD_DC_DCN (v3) drm/amdgpu/display: FP fixes for DCN3.x (v4) Alex Sierra (2): drm/amdgpu: align frag_end to covered address space drm/amdgpu: replace ih ip block for vega20 and arcturus Alvin Lee (7): drm/amd/display: Don't allow pstate if no support in blank drm/amd/display: Program meta addresses correctly drm/amd/display: Only flush inst_fb if backdoor loading drm/amd/display: Set WM set A to 0 if full pstate not supported drm/amd/display: Update GSL state if leaving immediate flip drm/amd/display: Keep GSL for full updates with planes that flip VSYNC drm/amd/display: Reset flip_immediate to topmost plane Andrey Grodzovsky (3): drm/amd/display: Revert "drm/amd/display: Fix a list corruption" drm/amd/display: Avoid MST manager resource leak. drm/amd/psp: Fix sysfs: cannot create duplicate filename Anthony Koo (5): drm/amd/display: [FW Promotion] Release 0.0.36 drm/amd/display: [FW Promotion] Release 0.0.37 drm/amd/display: [FW Promotion] Release 0.0.38 drm/amd/display: [FW Promotion] Release 0.0.39 drm/amd/display: [FW Promotion] Release 0.0.40 Aric Cyr (9): drm/amd/display: 3.2.105 drm/amd/display: Check for flip pending before locking pipes drm/amd/display: FreeSync not active near lower bound of non-LFC monitor range drm/amd/display: 3.2.106 drm/amd/display: 3.2.107 drm/amd/display: Don't trigger flip twice when ODM combine in use drm/amd/display: 3.2.108 drm/amd/display: 3.2.109 drm/amd/display: 3.2.110 Arnd Bergmann (2): drm/amdgpu: fix incorrect enum type drm/amdgpu: fix build_coefficients() argument Ashley Thomas (2): drm/amd/display: Source minimum HBlank support drm/amd/display: fail instead of div by zero/bugcheck Bas
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
On Thu, 05 Nov 2020, Daniel Vetter wrote: > On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote: > > > > On Thu, 05 Nov 2020, Thierry Reding wrote: > > > > > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > > > There are 5000 warnings to work through. > > > > > > > > It will take a couple more sets. > > > > > > > > Lee Jones (19): > > > > gpu: host1x: bus: Add missing description for 'driver' > > > > gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries > > > > gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused > > > > gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues > > > > gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused > > > > gpu: drm: scheduler: sched_main: Provide missing description for > > > > 'sched' paramter > > > > gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc > > > > headers > > > > gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables > > > > gpu: drm: selftests: test-drm_framebuffer: Remove set but unused > > > > variable 'fb' > > > > gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of > > > > kernel-doc abuses > > > > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header > > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > > > 'analogix_dp_write_byte_to_dpcd' > > > > gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses > > > > gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct > > > > drm_dp_sideband_msg_req_body' onto the heap > > > > gpu: drm: radeon: radeon_drv: Remove unused variable 'ret' > > > > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > > > > kernel-doc header > > > > gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc > > > > misdemeanours > > > > gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused > > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > > > 'analogix_dp_start_aux_transaction' > > > > > > As commented on the other patches, the subject prefixes on most of these > > > look wrong, but it's generally a nice cleanup. > > > > The prefixes are automated. I'll add this to my list of awkward > > subsystems and go through them all manually again tomorrow. :D > > tbh for autmoation they look really good :-) Only the prefixes are automated unfortunately. :) > I'd say if you replace the intermediate ": " with just a / you'll be > perfectly in style for drivers/gpu. But really I think it's ok as-is, It's up to you. Make the call and I'll abide. > imo no need to change since this is a giantic tree wide effort. Yes, you're not kidding, and thanks for noticing. Only 10,000 (from 18,000) more to go though. :D GPU is a biggy (5,000), although one patch in [Set 2] fixes 2,000 in one hit, which is great! I'll probably submit that tomorrow. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
On Thu, 05 Nov 2020, Thierry Reding wrote: > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > There are 5000 warnings to work through. > > > > It will take a couple more sets. > > > > Lee Jones (19): > > gpu: host1x: bus: Add missing description for 'driver' > > gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries > > gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused > > gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues > > gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused > > gpu: drm: scheduler: sched_main: Provide missing description for > > 'sched' paramter > > gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc > > headers > > gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables > > gpu: drm: selftests: test-drm_framebuffer: Remove set but unused > > variable 'fb' > > gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of > > kernel-doc abuses > > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > 'analogix_dp_write_byte_to_dpcd' > > gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses > > gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct > > drm_dp_sideband_msg_req_body' onto the heap > > gpu: drm: radeon: radeon_drv: Remove unused variable 'ret' > > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > > kernel-doc header > > gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc > > misdemeanours > > gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > 'analogix_dp_start_aux_transaction' > > As commented on the other patches, the subject prefixes on most of these > look wrong, but it's generally a nice cleanup. The prefixes are automated. I'll add this to my list of awkward subsystems and go through them all manually again tomorrow. :D -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
On Thu, 05 Nov 2020, Sam Ravnborg wrote: > Hi Lee. > > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > Thanks for looking into this. > > > There are 5000 warnings to work through. > > > > It will take a couple more sets. > :-) > > > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header > I have a patch here that inline the comments - and fix the warning as a > side effect. I will get it posted tonight as this is better. > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > 'analogix_dp_write_byte_to_dpcd' > When I looked at his I had another unused function after removing the > first. > > > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > > kernel-doc header > Agree on this simple approch, will apply. > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > 'analogix_dp_start_aux_transaction' > OK, this was the one I referred to above. They should be squashed into > one patch. I can squash them if you prefer. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote: > > On Thu, 05 Nov 2020, Thierry Reding wrote: > > > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > > > There are 5000 warnings to work through. > > > > > > It will take a couple more sets. > > > > > > Lee Jones (19): > > > gpu: host1x: bus: Add missing description for 'driver' > > > gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries > > > gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused > > > gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues > > > gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused > > > gpu: drm: scheduler: sched_main: Provide missing description for > > > 'sched' paramter > > > gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc > > > headers > > > gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables > > > gpu: drm: selftests: test-drm_framebuffer: Remove set but unused > > > variable 'fb' > > > gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of > > > kernel-doc abuses > > > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > > 'analogix_dp_write_byte_to_dpcd' > > > gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses > > > gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct > > > drm_dp_sideband_msg_req_body' onto the heap > > > gpu: drm: radeon: radeon_drv: Remove unused variable 'ret' > > > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > > > kernel-doc header > > > gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc > > > misdemeanours > > > gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused > > > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > > > 'analogix_dp_start_aux_transaction' > > > > As commented on the other patches, the subject prefixes on most of these > > look wrong, but it's generally a nice cleanup. > > The prefixes are automated. I'll add this to my list of awkward > subsystems and go through them all manually again tomorrow. :D tbh for autmoation they look really good :-) I'd say if you replace the intermediate ": " with just a / you'll be perfectly in style for drivers/gpu. But really I think it's ok as-is, imo no need to change since this is a giantic tree wide effort. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdkfd: replace idr_init() by idr_init_base()
On Wed, Nov 04, 2020 at 03:01:17PM -0500, Felix Kuehling wrote:
> On 2020-11-04 10:13 a.m., Deepak R Varma wrote:
> > idr_init() uses base 0 which is an invalid identifier. The new function
> > idr_init_base allows IDR to set the ID lookup from base 1. This avoids
> > all lookups that otherwise starts from 0 since 0 is always unused.
>
> I disagree. We call idr_alloc with start=0 for both these IDRs. That means 0
> seems to be a valid handle.
Hello Felix,
You are correct. There are calls made to idr_alloc with start range from
0. So, for this driver, id=0 seems a valid use case. The change I
proposed is not relevant for this driver. You may please ignore the
patch.
Thank you,
./drv
>
> Regards,
> Felix
>
>
> >
> > References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
> >
> > Signed-off-by: Deepak R Varma
> > ---
> > drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 +-
> > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
> > b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
> > index ba2c2ce0c55a..b3339b53c8ad 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c
> > @@ -230,7 +230,7 @@ static int create_other_event(struct kfd_process *p,
> > struct kfd_event *ev)
> > void kfd_event_init_process(struct kfd_process *p)
> > {
> > mutex_init(>event_mutex);
> > - idr_init(>event_idr);
> > + idr_init_base(>event_idr, 1);
> > p->signal_page = NULL;
> > p->signal_event_count = 0;
> > }
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > index 65803e153a22..022e61babe30 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> > @@ -1289,7 +1289,7 @@ struct kfd_process_device
> > *kfd_create_process_device_data(struct kfd_dev *dev,
> > list_add(>per_device_list, >per_device_data);
> > /* Init idr used for memory handle translation */
> > - idr_init(>alloc_idr);
> > + idr_init_base(>alloc_idr, 1);
> > return pdd;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > There are 5000 warnings to work through. > > It will take a couple more sets. > > Lee Jones (19): > gpu: host1x: bus: Add missing description for 'driver' > gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries > gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused > gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues > gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused > gpu: drm: scheduler: sched_main: Provide missing description for > 'sched' paramter > gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc > headers > gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables > gpu: drm: selftests: test-drm_framebuffer: Remove set but unused > variable 'fb' > gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of > kernel-doc abuses > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > 'analogix_dp_write_byte_to_dpcd' > gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses > gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct > drm_dp_sideband_msg_req_body' onto the heap > gpu: drm: radeon: radeon_drv: Remove unused variable 'ret' > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > kernel-doc header > gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc > misdemeanours > gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > 'analogix_dp_start_aux_transaction' As commented on the other patches, the subject prefixes on most of these look wrong, but it's generally a nice cleanup. Thanks! Thierry signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
Hi Lee. On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. Thanks for looking into this. > There are 5000 warnings to work through. > > It will take a couple more sets. :-) > gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header I have a patch here that inline the comments - and fix the warning as a side effect. I will get it posted tonight as this is better. > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > 'analogix_dp_write_byte_to_dpcd' When I looked at his I had another unused function after removing the first. > gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant > kernel-doc header Agree on this simple approch, will apply. > gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function > 'analogix_dp_start_aux_transaction' OK, this was the one I referred to above. They should be squashed into one patch. Sam ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 00/19] [Set 1] Rid W=1 warnings from GPU
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. There are 5000 warnings to work through. It will take a couple more sets. Lee Jones (19): gpu: host1x: bus: Add missing description for 'driver' gpu: ipu-v3: ipu-di: Strip out 2 unused 'di_sync_config' entries gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused gpu: drm: omapdrm: omap_irq: Fix a couple of doc-rot issues gpu: drm: selftests: test-drm_mm: Mark 'hole_end' as always_unused gpu: drm: scheduler: sched_main: Provide missing description for 'sched' paramter gpu: drm: scheduler: sched_entity: Demote non-conformant kernel-doc headers gpu: drm: omapdrm: dss: dsi: Rework and remove a few unused variables gpu: drm: selftests: test-drm_framebuffer: Remove set but unused variable 'fb' gpu: drm: ttm: ttm_bo: Fix one function header - demote lots of kernel-doc abuses gpu: drm: panel: panel-simple: Fix 'struct panel_desc's header gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function 'analogix_dp_write_byte_to_dpcd' gpu: drm: ttm: ttm_tt: Demote kernel-doc header format abuses gpu: drm: selftests: test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap gpu: drm: radeon: radeon_drv: Remove unused variable 'ret' gpu: drm: panel: panel-ilitek-ili9322: Demote non-conformant kernel-doc header gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc misdemeanours gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused gpu: drm: bridge: analogix: analogix_dp_reg: Remove unused function 'analogix_dp_start_aux_transaction' drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 +- .../gpu/drm/bridge/analogix/analogix_dp_reg.c | 88 --- drivers/gpu/drm/imx/ipuv3-plane.c | 2 +- drivers/gpu/drm/omapdrm/dss/dsi.c | 9 +- drivers/gpu/drm/omapdrm/omap_irq.c| 6 +- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 2 +- drivers/gpu/drm/panel/panel-simple.c | 2 + drivers/gpu/drm/radeon/radeon_device.c| 23 ++--- drivers/gpu/drm/radeon/radeon_drv.c | 3 +- drivers/gpu/drm/scheduler/sched_entity.c | 4 +- drivers/gpu/drm/scheduler/sched_main.c| 1 + .../drm/selftests/test-drm_dp_mst_helper.c| 29 +++--- .../gpu/drm/selftests/test-drm_framebuffer.c | 3 +- drivers/gpu/drm/selftests/test-drm_mm.c | 2 +- drivers/gpu/drm/ttm/ttm_bo.c | 23 ++--- drivers/gpu/drm/ttm/ttm_tt.c | 4 +- drivers/gpu/host1x/bus.c | 1 + drivers/gpu/ipu-v3/ipu-di.c | 4 - 18 files changed, 59 insertions(+), 153 deletions(-) Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Andrzej Hajda Cc: Christian Koenig Cc: "Christian König" Cc: Daniel Vetter Cc: David Airlie Cc: David Francis Cc: dri-de...@lists.freedesktop.org Cc: Fabio Estevam Cc: Gareth Hughes Cc: Huang Rui Cc: Jason Yan Cc: Jernej Skrabec Cc: Jingoo Han Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Laurent Pinchart Cc: Lee Jones Cc: linaro-mm-...@lists.linaro.org Cc: Linus Walleij Cc: linux-me...@vger.kernel.org Cc: linux-te...@vger.kernel.org Cc: Lyude Paul Cc: Neil Armstrong Cc: Nirmoy Das Cc: NXP Linux Team Cc: Pengutronix Kernel Team Cc: Philipp Zabel Cc: Rob Clark Cc: Sam Ravnborg Cc: Sascha Hauer Cc: Shawn Guo Cc: Sumit Semwal Cc: Thierry Reding Cc: Tomi Valkeinen -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 17/19] gpu: drm: radeon: radeon_device: Fix a bunch of kernel-doc misdemeanours
- Demote non-conformant headers
- Fix misnaming issues
- Rename labels with identical names
- Remove incorrect descriptions
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
for ‘radeon_device_is_virtual’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_device.c:552: warning: duplicate section name
'Note'
drivers/gpu/drm/radeon/radeon_device.c:556: warning: duplicate section name
'Note'
drivers/gpu/drm/radeon/radeon_device.c:561: warning: duplicate section name
'Note'
drivers/gpu/drm/radeon/radeon_device.c:564: warning: duplicate section name
'Note'
drivers/gpu/drm/radeon/radeon_device.c:1106: warning: Function parameter or
member 'family' not described in 'radeon_gart_size_auto'
drivers/gpu/drm/radeon/radeon_device.c:1291: warning: Function parameter or
member 'ddev' not described in 'radeon_device_init'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Function parameter or
member 'dev' not described in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Function parameter or
member 'suspend' not described in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Function parameter or
member 'fbcon' not described in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Function parameter or
member 'freeze' not described in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Excess function
parameter 'pdev' description in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1565: warning: Excess function
parameter 'state' description in 'radeon_suspend_kms'
drivers/gpu/drm/radeon/radeon_device.c:1669: warning: Function parameter or
member 'dev' not described in 'radeon_resume_kms'
drivers/gpu/drm/radeon/radeon_device.c:1669: warning: Function parameter or
member 'resume' not described in 'radeon_resume_kms'
drivers/gpu/drm/radeon/radeon_device.c:1669: warning: Function parameter or
member 'fbcon' not described in 'radeon_resume_kms'
drivers/gpu/drm/radeon/radeon_device.c:1669: warning: Excess function
parameter 'pdev' description in 'radeon_resume_kms'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/radeon/radeon_device.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 266e3cbbd09bd..7f384ffe848a7 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -544,21 +544,21 @@ int radeon_wb_init(struct radeon_device *rdev)
* Note: GTT start, end, size should be initialized before calling this
* function on AGP platform.
*
- * Note: We don't explicitly enforce VRAM start to be aligned on VRAM size,
+ * Note 1: We don't explicitly enforce VRAM start to be aligned on VRAM size,
* this shouldn't be a problem as we are using the PCI aperture as a reference.
* Otherwise this would be needed for rv280, all r3xx, and all r4xx, but
* not IGP.
*
- * Note: we use mc_vram_size as on some board we need to program the mc to
+ * Note 2: we use mc_vram_size as on some board we need to program the mc to
* cover the whole aperture even if VRAM size is inferior to aperture size
* Novell bug 204882 + along with lots of ubuntu ones
*
- * Note: when limiting vram it's safe to overwritte real_vram_size because
+ * Note 3: when limiting vram it's safe to overwritte real_vram_size because
* we are not in case where real_vram_size is inferior to mc_vram_size (ie
* note afected by bogus hw of Novell bug 204882 + along with lots of ubuntu
* ones)
*
- * Note: IGP TOM addr should be the same as the aperture addr, we don't
+ * Note 4: IGP TOM addr should be the same as the aperture addr, we don't
* explicitly check for that thought.
*
* FIXME: when reducing VRAM size align new size on power of 2.
@@ -627,7 +627,7 @@ void radeon_gtt_location(struct radeon_device *rdev, struct
radeon_mc *mc)
* GPU helpers function.
*/
-/**
+/*
* radeon_device_is_virtual - check if we are running is a virtual environment
*
* Check if the asic has been passed through to a VM (all asics).
@@ -1100,7 +1100,7 @@ static bool radeon_check_pot_argument(int arg)
/**
* Determine a sensible default GART size according to ASIC family.
*
- * @family ASIC family name
+ * @family: ASIC family name
*/
static int radeon_gart_size_auto(enum radeon_family family)
{
@@ -1276,7 +1276,7 @@ static const struct vga_switcheroo_client_ops
radeon_switcheroo_ops = {
* radeon_device_init - initialize the driver
*
* @rdev: radeon_device pointer
- * @pdev: drm dev pointer
+ * @ddev: drm dev pointer
* @pdev: pci dev pointer
* @flags: driver flags
*
@@ -1550,12 +1550,9 @@ void
[PATCH 15/19] gpu: drm: radeon: radeon_drv: Remove unused variable 'ret'
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_drv.c: In function
‘radeon_pmops_runtime_suspend’:
drivers/gpu/drm/radeon/radeon_drv.c:455:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gareth Hughes
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 65061c949aeea..f5f1cb700d873 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -452,7 +452,6 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
- int ret;
if (!radeon_is_px(drm_dev)) {
pm_runtime_forbid(dev);
@@ -462,7 +461,7 @@ static int radeon_pmops_runtime_suspend(struct device *dev)
drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(drm_dev);
- ret = radeon_suspend_kms(drm_dev, false, false, false);
+ radeon_suspend_kms(drm_dev, false, false, false);
pci_save_state(pdev);
pci_disable_device(pdev);
pci_ignore_hotplug(pdev);
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 18/19] gpu: drm: amd: amdgpu: amdgpu: Mark global variables as __maybe_unused
These 3 variables are used in *some* sourcefiles which include amdgpu.h, but not *all*. This leads to a flurry of build warnings. Fixes the following W=1 kernel build warning(s): from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67, drivers/gpu/drm/amd/amdgpu/amdgpu.h:198:19: warning: ‘no_system_mem_limit’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/amd/amdgpu/amdgpu.h:197:19: warning: ‘debug_evictions’ defined but not used [-Wunused-const-variable=] drivers/gpu/drm/amd/amdgpu/amdgpu.h:196:18: warning: ‘sched_policy’ defined but not used [-Wunused-const-variable=] NB: Repeats ~650 times - snipped for brevity. Cc: Alex Deucher Cc: "Christian König" Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 183b09d71b64a..5939753080056 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -193,9 +193,9 @@ extern int sched_policy; extern bool debug_evictions; extern bool no_system_mem_limit; #else -static const int sched_policy = KFD_SCHED_POLICY_HWS; -static const bool debug_evictions; /* = false */ -static const bool no_system_mem_limit; +static const int __maybe_unused sched_policy = KFD_SCHED_POLICY_HWS; +static const bool __maybe_unused debug_evictions; /* = false */ +static const bool __maybe_unused no_system_mem_limit; #endif extern int amdgpu_tmz; -- 2.25.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: Fix Arcturus fan speed reporting
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Kent Russell
Sent: Thursday, November 5, 2020 10:20 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/amdgpu: Fix Arcturus fan speed reporting
Arcturus doesn't have a fan. The assumption of "if the manual fan
control bit isn't set, it's on automatic mode" does not hold true if the
fan is missing, and results in exposing an invalid value for fan speed.
The SMU metrics table accurately reflects the lack of fan and will
return 0 for the fan speed. Trying to use the
smu_v11_0_get_fan_speed_rpm function will return invalid data, so just
stick with the SMU metrics for Arcturus
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index d96048e98237..4fd850e58004 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -1139,14 +1139,9 @@ static int arcturus_get_fan_speed_rpm(struct smu_context
*smu,
if (!speed)
return -EINVAL;
- switch (smu_v11_0_get_fan_control_mode(smu)) {
- case AMD_FAN_CTRL_AUTO:
- return arcturus_get_smu_metrics_data(smu,
-METRICS_CURR_FANSPEED,
-speed);
- default:
- return smu_v11_0_get_fan_speed_rpm(smu, speed);
- }
+ return arcturus_get_smu_metrics_data(smu,
+METRICS_CURR_FANSPEED,
+speed);
}
static int arcturus_get_fan_parameters(struct smu_context *smu)
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Calexander.deucher%40amd.com%7Cc266d21dcb5e4d84073808d8819e9820%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637401865460755885%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=O8kmXHVEGi01B7S0gk5MPafIEiuBC9v7catH%2FASo6iQ%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: Fix Arcturus fan speed reporting
Arcturus doesn't have a fan. The assumption of "if the manual fan
control bit isn't set, it's on automatic mode" does not hold true if the
fan is missing, and results in exposing an invalid value for fan speed.
The SMU metrics table accurately reflects the lack of fan and will
return 0 for the fan speed. Trying to use the
smu_v11_0_get_fan_speed_rpm function will return invalid data, so just
stick with the SMU metrics for Arcturus
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
index d96048e98237..4fd850e58004 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
@@ -1139,14 +1139,9 @@ static int arcturus_get_fan_speed_rpm(struct smu_context
*smu,
if (!speed)
return -EINVAL;
- switch (smu_v11_0_get_fan_control_mode(smu)) {
- case AMD_FAN_CTRL_AUTO:
- return arcturus_get_smu_metrics_data(smu,
-METRICS_CURR_FANSPEED,
-speed);
- default:
- return smu_v11_0_get_fan_speed_rpm(smu, speed);
- }
+ return arcturus_get_smu_metrics_data(smu,
+METRICS_CURR_FANSPEED,
+speed);
}
static int arcturus_get_fan_parameters(struct smu_context *smu)
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add ta firmware load for green-sardine
Reviewed-by: Alex Deucher
On Thu, Nov 5, 2020 at 8:27 AM wrote:
>
> From: Roman Li
>
> [Why]
> In preparation to enabling hdcp on green sardine.
>
> [How]
> Add green-sardine ta f/w loading in psp_v12
>
> Signed-off-by: Roman Li
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> index dff5c15b4858..c4828bd3264b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
> @@ -40,6 +40,7 @@
> MODULE_FIRMWARE("amdgpu/renoir_asd.bin");
> MODULE_FIRMWARE("amdgpu/renoir_ta.bin");
> MODULE_FIRMWARE("amdgpu/green_sardine_asd.bin");
> +MODULE_FIRMWARE("amdgpu/green_sardine_ta.bin");
>
> /* address block */
> #define smnMP1_FIRMWARE_FLAGS 0x3010024
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH] drm/amdgpu: add ta firmware load for green-sardine
From: Roman Li
[Why]
In preparation to enabling hdcp on green sardine.
[How]
Add green-sardine ta f/w loading in psp_v12
Signed-off-by: Roman Li
---
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
index dff5c15b4858..c4828bd3264b 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
@@ -40,6 +40,7 @@
MODULE_FIRMWARE("amdgpu/renoir_asd.bin");
MODULE_FIRMWARE("amdgpu/renoir_ta.bin");
MODULE_FIRMWARE("amdgpu/green_sardine_asd.bin");
+MODULE_FIRMWARE("amdgpu/green_sardine_ta.bin");
/* address block */
#define smnMP1_FIRMWARE_FLAGS 0x3010024
--
2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy from system memory and a
> >> pointer-increment function. Add both interfaces with documentation.
> >
> > (...)
> >> +/**
> >> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> >> + * @dst: The dma-buf mapping structure
> >> + * @src: The source buffer
> >> + * @len: The number of byte in src
> >> + *
> >> + * Copies data into a dma-buf mapping. The source buffer is in system
> >> + * memory. Depending on the buffer's location, the helper picks the
> >> correct
> >> + * method of accessing the memory.
> >> + */
> >> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const
> >> void *src, size_t len)
> >> +{
> >> + if (dst->is_iomem)
> >> + memcpy_toio(dst->vaddr_iomem, src, len);
> >> + else
> >> + memcpy(dst->vaddr, src, len);
> >> +}
> >
> > Are these going to be really big memcpy() operations?
>
> Individually, each could be a scanline, so a few KiB. (4 bytes *
> horizontal resolution). Updating a full framebuffer can sum up to
> several MiB.
>
> >
> > Some platforms have DMA offload engines that can perform memcpy(),They
> > could be
> > drivers/dma, include/linux/dmaengine.h
> > especially if the CPU doesn't really need to touch the contents
> > and flush caches etc.
> > An example exist in some MTD drivers that move large quantities of
> > data off flash memory like this:
> > drivers/mtd/nand/raw/cadence-nand-controller.c
> >
> > Notice that DMAengine and DMAbuf does not have much in common,
> > the names can be deceiving.
> >
> > The value of this varies with the system architecture. It is not just
> > a question about performance but also about power and the CPU
> > being able to do other stuff in parallel for large transfers. So *when*
> > to use this facility to accelerate memcpy() is a delicate question.
> >
> > What I'm after here is if these can be really big, do we want
> > (in the long run, not now) open up to the idea to slot in
> > hardware-accelerated memcpy() here?
>
> We currently use this functionality for the graphical framebuffer
> console that most DRM drivers provide. It's non-accelerated and slow,
> but this has not been much of a problem so far.
>
> Within DRM, we're more interested in removing console code from drivers
> and going for the generic implementation.
>
> Most of the graphics HW allocates framebuffers from video RAM, system
> memory or CMA pools and does not really need these memcpys. Only a few
> systems with small video RAM require a shadow buffer, which we flush
> into VRAM as needed. Those might benefit.
>
> OTOH, off-loading memcpys to hardware sounds reasonable if we can hide
> it from the DRM code. I think it all depends on how invasive that change
> would be.
I wouldn't, all the additional locks this would pull in sound like
nightmare. And when an oops happens, this might be the only thing that
manages to get the oops to the user.
Unless someone really starts caring about fbcon acceleration I really
wouldn't bother. Ok maybe it also matters for fbdev, but the problem is
that the page fault intercepting alone is already expensive, so the only
real solution if you care about performance in that case is to use kms
natively, and use a dirty rectangle flip (or the DIRTY syscall).
And in there drivers should (and do) use any dma engines they have to
upload the frames already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Hi
Am 05.11.20 um 11:07 schrieb Linus Walleij:
> Overall I like this, just an inline question:
>
> On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
>
>> To do framebuffer updates, one needs memcpy from system memory and a
>> pointer-increment function. Add both interfaces with documentation.
>
> (...)
>> +/**
>> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
>> + * @dst: The dma-buf mapping structure
>> + * @src: The source buffer
>> + * @len: The number of byte in src
>> + *
>> + * Copies data into a dma-buf mapping. The source buffer is in system
>> + * memory. Depending on the buffer's location, the helper picks the correct
>> + * method of accessing the memory.
>> + */
>> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const
>> void *src, size_t len)
>> +{
>> + if (dst->is_iomem)
>> + memcpy_toio(dst->vaddr_iomem, src, len);
>> + else
>> + memcpy(dst->vaddr, src, len);
>> +}
>
> Are these going to be really big memcpy() operations?
Individually, each could be a scanline, so a few KiB. (4 bytes *
horizontal resolution). Updating a full framebuffer can sum up to
several MiB.
>
> Some platforms have DMA offload engines that can perform memcpy(),They could
> be
> drivers/dma, include/linux/dmaengine.h
> especially if the CPU doesn't really need to touch the contents
> and flush caches etc.
> An example exist in some MTD drivers that move large quantities of
> data off flash memory like this:
> drivers/mtd/nand/raw/cadence-nand-controller.c
>
> Notice that DMAengine and DMAbuf does not have much in common,
> the names can be deceiving.
>
> The value of this varies with the system architecture. It is not just
> a question about performance but also about power and the CPU
> being able to do other stuff in parallel for large transfers. So *when*
> to use this facility to accelerate memcpy() is a delicate question.
>
> What I'm after here is if these can be really big, do we want
> (in the long run, not now) open up to the idea to slot in
> hardware-accelerated memcpy() here?
We currently use this functionality for the graphical framebuffer
console that most DRM drivers provide. It's non-accelerated and slow,
but this has not been much of a problem so far.
Within DRM, we're more interested in removing console code from drivers
and going for the generic implementation.
Most of the graphics HW allocates framebuffers from video RAM, system
memory or CMA pools and does not really need these memcpys. Only a few
systems with small video RAM require a shadow buffer, which we flush
into VRAM as needed. Those might benefit.
OTOH, off-loading memcpys to hardware sounds reasonable if we can hide
it from the DRM code. I think it all depends on how invasive that change
would be.
Best regards
Thomas
>
> Yours,
> Linus Walleij
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Overall I like this, just an inline question:
On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
(...)
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
> +}
Are these going to be really big memcpy() operations?
Some platforms have DMA offload engines that can perform memcpy(),
drivers/dma, include/linux/dmaengine.h
especially if the CPU doesn't really need to touch the contents
and flush caches etc.
An example exist in some MTD drivers that move large quantities of
data off flash memory like this:
drivers/mtd/nand/raw/cadence-nand-controller.c
Notice that DMAengine and DMAbuf does not have much in common,
the names can be deceiving.
The value of this varies with the system architecture. It is not just
a question about performance but also about power and the CPU
being able to do other stuff in parallel for large transfers. So *when*
to use this facility to accelerate memcpy() is a delicate question.
What I'm after here is if these can be really big, do we want
(in the long run, not now) open up to the idea to slot in
hardware-accelerated memcpy() here?
Yours,
Linus Walleij
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
