On 9/17/20 12:37 AM, Dmitry Osipenko wrote:
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.
My guess is that some very old code used fixed syncpoint numbers so
these were added to the reservation list. Let's reserve 26 and 27, that
should be simple enough since both would be "released" by the display
driver.
Mikko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
