| Message ID | 20240826111022.41db1e95@canb.auug.org.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | linux-next: manual merge of the amdgpu tree with the drm-misc tree | expand |
Hi all, On Mon, 26 Aug 2024 11:10:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Today's linux-next merge of the amdgpu tree got a conflict in: > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > > between commits: > > 537ef0f88897 ("drm/amd/display: use new vblank enable policy for DCN35+") > e45b6716de4b ("drm/amd/display: use a more lax vblank enable policy for DCN35+") > 58a261bfc967 ("drm/amd/display: use a more lax vblank enable policy for older ASICs") > > from the drm-misc tree and commit: > > 7fb363c57522 ("drm/amd/display: Let drm_crtc_vblank_on/off manage interrupts") > > from the amdgpu tree. > > I fixed it up (I think - see below) and can carry the fix as necessary. > This is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. > > > diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 34872eb4fc84,7d999e352df3..000000000000 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@@ -8229,66 -8248,12 +8242,35 @@@ static int amdgpu_dm_encoder_init(struc > > static void manage_dm_interrupts(struct amdgpu_device *adev, > struct amdgpu_crtc *acrtc, > - bool enable) > + struct dm_crtc_state *acrtc_state) > { > - /* > - * We have no guarantee that the frontend index maps to the same > - * backend index - some even map to more than one. > - * > - * TODO: Use a different interrupt or check DC itself for the mapping. > - */ > - int irq_type = > - amdgpu_display_crtc_idx_to_irq_type( > - adev, > - acrtc->crtc_id); > - if (enable) > - drm_crtc_vblank_on(&acrtc->base); > - else > + struct drm_vblank_crtc_config config = {0}; > + struct dc_crtc_timing *timing; > + int offdelay; > + > + if (acrtc_state) { > + if (amdgpu_ip_version(adev, DCE_HWIP, 0) < > + IP_VERSION(3, 5, 0) || > + acrtc_state->stream->link->psr_settings.psr_version < > + DC_PSR_VERSION_UNSUPPORTED) { > + timing = &acrtc_state->stream->timing; > + > + /* at least 2 frames */ > + offdelay = DIV64_U64_ROUND_UP((u64)20 * > + timing->v_total * > + timing->h_total, > + timing->pix_clk_100hz); > + > + config.offdelay_ms = offdelay ?: 30; > + } else { > + config.disable_immediate = true; > + } > + > + drm_crtc_vblank_on_config(&acrtc->base, > + &config); > - > - amdgpu_irq_get( > - adev, > - &adev->pageflip_irq, > - irq_type); > - #if defined(CONFIG_DRM_AMD_SECURE_DISPLAY) > - amdgpu_irq_get( > - adev, > - &adev->vline0_irq, > - irq_type); > - #endif > + } else { > - #if defined(CONFIG_DRM_AMD_SECURE_DISPLAY) > - amdgpu_irq_put( > - adev, > - &adev->vline0_irq, > - irq_type); > - #endif > - amdgpu_irq_put( > - adev, > - &adev->pageflip_irq, > - irq_type); > drm_crtc_vblank_off(&acrtc->base); > + } > } > > static void dm_update_pflip_irq_state(struct amdgpu_device *adev, This is now a conflict between the drm-misc tree and the drm tree.
diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 34872eb4fc84,7d999e352df3..000000000000 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Hi all, Today's linux-next merge of the amdgpu tree got a conflict in: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c between commits: 537ef0f88897 ("drm/amd/display: use new vblank enable policy for DCN35+") e45b6716de4b ("drm/amd/display: use a more lax vblank enable policy for DCN35+") 58a261bfc967 ("drm/amd/display: use a more lax vblank enable policy for older ASICs") from the drm-misc tree and commit: 7fb363c57522 ("drm/amd/display: Let drm_crtc_vblank_on/off manage interrupts") from the amdgpu tree. I fixed it up (I think - see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.