On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote: > 02.04.2021 00:19, Michał Mirosław пишет: > > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote: > >> On 3/23/21 12:16 PM, Thierry Reding wrote: > >>> On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote: > >>>> Show the number of pending waiters in the debugfs status file. > >>>> This is useful for testing to verify that waiters do not leak > >>>> or accumulate incorrectly. > >>>> > >>>> Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx> > >>>> --- > >>>> drivers/gpu/host1x/debug.c | 14 +++++++++++--- > >>>> 1 file changed, 11 insertions(+), 3 deletions(-) > >>>> > >>>> diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c > >>>> index 1b4997bda1c7..8a14880c61bb 100644 > >>>> --- a/drivers/gpu/host1x/debug.c > >>>> +++ b/drivers/gpu/host1x/debug.c > >>>> @@ -69,6 +69,7 @@ static int show_channel(struct host1x_channel *ch, void *data, bool show_fifo) > >>>> static void show_syncpts(struct host1x *m, struct output *o) > >>>> { > >>>> + struct list_head *pos; > >>>> unsigned int i; > >>>> host1x_debug_output(o, "---- syncpts ----\n"); > >>>> @@ -76,12 +77,19 @@ static void show_syncpts(struct host1x *m, struct output *o) > >>>> for (i = 0; i < host1x_syncpt_nb_pts(m); i++) { > >>>> u32 max = host1x_syncpt_read_max(m->syncpt + i); > >>>> u32 min = host1x_syncpt_load(m->syncpt + i); > >>>> + unsigned int waiters = 0; > >>>> - if (!min && !max) > >>>> + spin_lock(&m->syncpt[i].intr.lock); > >>>> + list_for_each(pos, &m->syncpt[i].intr.wait_head) > >>>> + waiters++; > >>>> + spin_unlock(&m->syncpt[i].intr.lock); > >>> > >>> Would it make sense to keep a running count so that we don't have to > >>> compute it here? > >> > >> Considering this is just a debug facility, I think I prefer not adding a new > >> field just for it. > > > > This looks like IRQ-disabled region, so unless only root can trigger > > this code, maybe the additional field could save a potential headache? > > How many waiters can there be in the worst case? > > The host1x's IRQ handler runs in a workqueue, so it should be okay. Why, then, this uses a spinlock (and it has 'intr' in its name)? Best Regards Michał Mirosław