Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

staging: greybus: loopback: use gb_loopback_async_wait_all don't spin

Browse source 
Currently the greybus-loopback thread logic spins around waiting for
send_count == iteration_max which on real hardware doesn't make a
difference to us but in simulation is excruciatingly slow, anti-social and
bad manners. Use the existing gb_loopback_async_wait_all() function to gate
continuing when the send_count == iteration_max and go to sleep until
there's something worthwhile to-do.

Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Bryan O'Donoghue 2016-12-22 00:37:28 +00:00 committed by Greg Kroah-Hartman
parent af1550cce0
commit a072a72da9
1 changed files with 11 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
drivers/staging/greybus/loopback.c
View file

@ -1008,11 +1008,22 @@ static int gb_loopback_fn(void *data)
/* Optionally terminate */
if (gb->send_count == gb->iteration_max) {
mutex_unlock(&gb->mutex);
/* Wait for synchronous and asynchronus completion */
gb_loopback_async_wait_all(gb);
/* Mark complete unless user-space has poked us */
mutex_lock(&gb->mutex);
if (gb->iteration_count == gb->iteration_max) {
gb->type = 0;
gb->send_count = 0;
sysfs_notify(&gb->dev->kobj, NULL,
"iteration_count");
dev_dbg(&bundle->dev, "load test complete\n");
} else {
dev_dbg(&bundle->dev,
"continuing on with new test set\n");
}
mutex_unlock(&gb->mutex);
continue;