On 2021-12-22 12:28:52, AngeloGioacchino Del Regno wrote: > Il 11/12/21 22:57, Marijn Suijten ha scritto: > > On 2021-12-12 00:49:09, Dmitry Baryshkov wrote: > >> On Sun, 12 Dec 2021 at 00:35, Marijn Suijten > >> <marijn.suijten@xxxxxxxxxxxxxx> wrote: > >>> [..] > >>> On this note, does it perhaps make more sense to call the "internal" > >>> _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going > >>> through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which > >>> seems solely intended to handle the wait_for_tx_complete callback? > >> > >> Either one would work. The main difference is the error message. Do > >> you want to see it here if the wait times out or not? > > > > I prefer calling _dpu_encoder_phys_cmd_wait_for_idle directly and > > optionally adding our own error message. IIRC DRM_ERROR prints source > > information such as the function this originated from, and that makes it > > impossible to distinguish between the wait_for_tx_complete callback or > > the invocation through dpu_encoder_phys_cmd_wait_for_commit_done anyway. > > > > - Marijn > > > > I wouldn't be happy to find myself in a situation in which I get strange > display slowness without any print to help me; for this reason, I find > having the print in place useful for debugging of both perf and fault. Same thought here, though dpu_encoder_phys_cmd_wait_for_tx_complete exists for the sole reason of printing a nice debug message, which I wouldn't want to be misused by dpu_encoder_phys_cmd_wait_for_commit_done punting its errors on wait_for_tx_complete - if that happens the first thing I'd do during debugging is assign individual messages to both, otherwise it is impossible to know which two functions is the cause: we might as well "duplicate" the error message right now and prevent such confusion from occurring in the first place? - Marijn > > Cheers, > - Angelo
