On 2023-02-16 05:02:32, Dmitry Baryshkov wrote: > On Thu, 16 Feb 2023 at 01:02, Marijn Suijten > <marijn.suijten@xxxxxxxxxxxxxx> wrote: > > > > Random inspection of the SSPP code surfaced that the version field of > > dpu_scaler_blk was never assigned in the catalog, resulting in wrong > > codepaths to be taken within dpu_hw_setup_scaler3 based on a 0 version. > > Rectify this by reading an accurate value from a register (that is not > > equal to the values represented by DPU_SSPP_SCALER_QSEEDx enum > > variants) and deleting dead code around QSEED versioning. > > > > Future changes should likely get rid of the distinction between QSEED3 > > and up, as these are now purely determined from the register value. > > Furthermore implementations could look at the scaler subblk .id field > > rather than the SSPP feature bits, which currently hold redundant > > information. > > > > --- > > Marijn Suijten (3): > > drm/msm/dpu: Read previously-uninitialized SSPP scaler version from hw > > drm/msm/dpu: Drop unused get_scaler_ver callback from SSPP > > drm/msm/dpu: Drop unused qseed_type from catalog dpu_caps > > The cleanup looks good. However as you are on it, maybe you can also > add patch 4, dropping DPU_SSPP_SCALER_QSEED3LITE and > DPU_SSPP_SCALER_QSEED4 in favour of using QSEED3 for all these > scalers? I surely can! Do you mind if I rename it to QSEED3_AND_UP for clarity? How about the second question, dropping this redundant information from the SSPP feature flags and only looking at the scaler_blk.id? > As we are going to use scaler_version to distinguish between > them, it would be logical not to duplicate that bit of information > (not to mention all the possible troubles if scaler_version disagrees > with the sblk->scaler_blk.id). Note that we had a similar discussion for UBWC HW decoder version and it was decided to go the opposite route [1]. That may have been for technical reasons (unclocked register access), but it's an inconsistent approach to say the least. [1]: https://lore.kernel.org/linux-arm-msm/71f96910-e7b1-92f9-ae15-79bd1da40a0d@xxxxxxxxxxx/ - Marijn
