All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar
Date: Thu, 18 Sep 2014 11:59:53 +0200	[thread overview]
Message-ID: <201409181159.53234.marex@denx.de> (raw)
In-Reply-To: <541A93C5.8060702@atmel.com>

On Thursday, September 18, 2014 at 10:11:49 AM, Bo Shen wrote:
> Hi Marek,
> 
> On 09/18/2014 10:32 AM, Marek Vasut wrote:
> > On Thursday, September 18, 2014 at 03:34:18 AM, Bo Shen wrote:
> >> Hi Marek,
> >> 
> >> On 09/17/2014 07:16 PM, Marek Vasut wrote:
> >>> On Wednesday, September 17, 2014 at 12:28:57 PM, Bo Shen wrote:
> >>>> Hi Marek,
> >>>> 
> >>>> On 09/17/2014 06:10 PM, Marek Vasut wrote:
> >>>>> On Wednesday, September 17, 2014 at 09:43:56 AM, Bo Shen wrote:
> >>>>> 
> >>>>> +CC Lukasz, this is his turf.
> >>>>> 
> >>>>>> When download is ongoing, if the actual size of one transfer is
> >>>>>> not the same as BTYES_PER_DOT, which will cause the dot won't
> >>>>>> print anymore. Then it will let the user thinking it is stuck,
> >>>>>> actually it is transfering without dot printed.
> >>>>>> 
> >>>>>> So, improve the method to show the progress bar (print dot).
> >>>>>> 
> >>>>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> >>>>>> ---
> >>>>>> 
> >>>>>>     drivers/usb/gadget/f_fastboot.c | 7 +++++--
> >>>>>>     1 file changed, 5 insertions(+), 2 deletions(-)
> >>>>>> 
> >>>>>> diff --git a/drivers/usb/gadget/f_fastboot.c
> >>>>>> b/drivers/usb/gadget/f_fastboot.c index 7a1acb9..2f13bf0 100644
> >>>>>> --- a/drivers/usb/gadget/f_fastboot.c
> >>>>>> +++ b/drivers/usb/gadget/f_fastboot.c
> >>>>>> @@ -51,6 +51,7 @@ static inline struct f_fastboot
> >>>>>> *func_to_fastboot(struct usb_function *f) static struct
> >>>>>> f_fastboot *fastboot_func;
> >>>>>> 
> >>>>>>     static unsigned int download_size;
> >>>>>>     static unsigned int download_bytes;
> >>>>>> 
> >>>>>> +static unsigned int num_of_dot;
> >>>>>> 
> >>>>>>     static struct usb_endpoint_descriptor fs_ep_in = {
> >>>>>>     
> >>>>>>     	.bLength            = USB_DT_ENDPOINT_SIZE,
> >>>>>> 
> >>>>>> @@ -414,9 +415,10 @@ static void rx_handler_dl_image(struct
> >>>>>> usb_ep *ep, struct usb_request *req) req->length = ep->maxpacket;
> >>>>>> 
> >>>>>>     	}
> >>>>>> 
> >>>>>> -	if (download_bytes && !(download_bytes % BYTES_PER_DOT)) {
> >>>>>> +	if (download_bytes && ((download_bytes / BYTES_PER_DOT) >
> >>>>>> num_of_dot)) { +		num_of_dot = download_bytes / 
BYTES_PER_DOT;
> >>>>>> 
> >>>>>>     		putc('.');
> >>>>>> 
> >>>>>> -		if (!(download_bytes % (74 * BYTES_PER_DOT)))
> >>>>>> +		if (!(num_of_dot % 74))
> >>>>>> 
> >>>>>>     			putc('\n');
> >>>>>>     	
> >>>>>>     	}
> >>>>>>     	req->actual = 0;
> >>>>>> 
> >>>>>> @@ -431,6 +433,7 @@ static void cb_download(struct usb_ep *ep,
> >>>>>> struct usb_request *req) strsep(&cmd, ":");
> >>>>>> 
> >>>>>>     	download_size = simple_strtoul(cmd, NULL, 16);
> >>>>>>     	download_bytes = 0;
> >>>>>> 
> >>>>>> +	num_of_dot = 0;
> >>>>> 
> >>>>> Make it a 'download_total' and log the total amount of bytes
> >>>>> transferred please, that way it can be re-used for other purposes
> >>>>> in the future ; for example for printing how much data were
> >>>>> already transferred ;-)
> >>>> 
> >>>> The download_bytes record the total amount of bytes transferred.
> >>>> And the download_bytes will print after finishing transfer.
> >>> 
> >>> So why can this not be used to indicate the total progress ? Because
> >>> the transfeer speed is variating too much ?
> >> 
> >> As I described in the commit message. If the transfer length is not
> >> exactly the same as the request length, then the old method
> >> 
> >>     "download_bytes % BYTES_PER_DOT"
> >> 
> >> won't be 0 anymore, so for the following transfer, it won't print dot
> >> anymore.
> > 
> > And can you not reset the "download_bytes" for each transfer ?
> 
> No, I don't reset the "download_bytes" for each transfer. It reset the
> "download_bytes" before transfer start.
> The "download_bytes" is increase in rx_handler_dl_image function.

OK

> > Maybe we're not even aligned on what "transfer" means, so we might want
> > to sync on this word first. What does "transfer" mean in this case?
> 
> Transfer I mean here is a usb request, which trying to transfer
> EP_BUFFER_SIZE at one time.
> In my test case, sometime it transfer less than EP_BUFFER_SIZE in a usb
> request. So, it cause dot won't print the dot, and seems stuck. However,
> it will finish transfer after some time.

I see now. This code is really weird.

What would happen if the following condition is met in the code for k>0 ?
(download_bytes == download_size) AND (download_bytes = k * BYTES_PER_DOT)

I think the original code would happily print a dot after printing this output:
printf("\ndownloading of %d bytes finished\n", download_bytes);

Do you agree ? If yes, then I believe this code should go into the else branch 
only.

Also, you can probably avoid the counting variable if you do something like:

if (download_bytes / CONST != (download_bytes + transfer_size) / CONST) {
	print(dot);
	if (download_bytes / (74 * CONST) != ((download_bytes + transfer_size) / 
(74 * CONST))
		print(\n);
}

Surely, the code can be simplified . You would also need to be careful about 
this assignment at the top of the function : download_bytes += transfer_size;

What do you think ?

  reply	other threads:[~2014-09-18  9:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ABFEDD1A8D2AAF42A54E3C074D49DC729DB2AD9B@penmbx01>
2014-09-18  8:11 ` [U-Boot] FW: [PATCH] usb: gadget: fastboot: improve download progress bar Bo Shen
2014-09-18  9:59   ` Marek Vasut [this message]
2014-09-19  3:27     ` Bo Shen
2014-09-19  4:24       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201409181159.53234.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.