16.09.2020 23:43, Mikko Perttunen пишет: ... >> Please note that the sync point state actually needs to be completely >> reset at the sync point request-time because both downstream fastboot >> and upstream u-boot [1] are needlessly enabling display VBLANK interrupt >> that continuously increments sync point #26 during of kernel boot until >> display controller is reset. >> >> [1] >> https://github.com/u-boot/u-boot/blob/master/drivers/video/tegra.c#L155 >> >> Hence once sync point #26 is requested, it will have a dirty state. So >> far this doesn't have any visible effect because sync points aren't used >> much. >> > > Maybe we can instead reserve syncpoints that might be used by the boot > chain, and only allow allocating them once the display driver has acked > that the syncpoint will no longer be incremented? That way if the > display driver is disabled for some reason we'll still be fine. sounds good > Looking at the downstream driver, it (still, on new chips..) reserves > the following syncpoints: > > - 10 (AVP) > - 22 (3D) > - 26 (VBLANK0) > - 27 (VBLANK1) > > and says that this applies to T20, T30, T114 and T148. > > I suppose if you haven't observed this happening to other syncpoints > than 26, then reserving 26 would probably be enough. I only saw SP 26 being used by the DC, but perhaps that may vary from device to device and SP 27 could actually be used in a wild as well. I think the AVP SP should only relate to the AVP-firmware that upstream doesn't support, so we can ignore its reservation. I've no idea what may use the 3D SP. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
