public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks
Date: Sat, 04 Jun 2016 00:51:45 +0200	[thread overview]
Message-ID: <57520A01.6060402@denx.de> (raw)
In-Reply-To: <1464843409-18690-1-git-send-email-rajesh.bhagat@nxp.com>

On 06/02/2016 06:56 AM, Rajesh Bhagat wrote:
> Implements the logic to calculate the optimal usb maximum trasfer blocks
> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
> of EHCI and other USB protocols respectively.
> 
> It defines USB_MIN_XFER_BLK/USB_MAX_XFER_BLK trasfer blocks that should
> be checked for success starting from minimum to maximum, and rest of the
> read/write are performed with that optimal value. It tries to increase/
> decrease the blocks in follwing scenarios:
> 
> 1.decrease blocks: when read/write for a particular number of blocks
> fails.
> 2. increase blocks: when read/write for a particular number of blocks
> pass and amount left to trasfer is greater than current number of
> blocks.
> 
> Currently changes are done for EHCI where min = 4096 and max = 65535
> is taken. And for other cases code is left unchanged by keeping min
> = max = 20.
> 
> Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
> Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
> ---
>  common/usb_storage.c | 71 +++++++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 59 insertions(+), 12 deletions(-)
> 
> diff --git a/common/usb_storage.c b/common/usb_storage.c
> index 7e6e52d..eee8f4c 100644
> --- a/common/usb_storage.c
> +++ b/common/usb_storage.c
> @@ -106,10 +106,13 @@ struct us_data {
>   * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands are
>   * limited to 65535 blocks.
>   */
> +#define USB_MIN_XFER_BLK	4095
>  #define USB_MAX_XFER_BLK	65535
>  #else
> +#define USB_MIN_XFER_BLK	20
>  #define USB_MAX_XFER_BLK	20
>  #endif
> +#define USB_CUR_XFER_BLK(n)	(n >= 0 ? ((1 << (12 + (n))) - 1) : 0)

Can this be ever called with n < 0 ? You should make this into a
function to get typechecking on it too.

>  #ifndef CONFIG_BLK
>  static struct us_data usb_stor[USB_MAX_STOR_DEV];
> @@ -1117,11 +1120,13 @@ static unsigned long usb_stor_read(struct blk_desc *block_dev, lbaint_t blknr,
>  	unsigned short smallblks;
>  	struct usb_device *udev;
>  	struct us_data *ss;
> -	int retry;
> +	int retry, pos = 0;
> +	bool retry_flag = false;
>  	ccb *srb = &usb_ccb;
>  #ifdef CONFIG_BLK
>  	struct blk_desc *block_dev;
>  #endif
> +	unsigned short usb_cur_xfer_blk = USB_CUR_XFER_BLK(pos);

How will this behave if you keep alternating between two block_dev
devices ? It will always start looking for the best possible transfer
length from scratch, right ? That's not great ...

>  	if (blkcnt == 0)
>  		return 0;
> @@ -1153,26 +1158,46 @@ static unsigned long usb_stor_read(struct blk_desc *block_dev, lbaint_t blknr,
>  		/* XXX need some comment here */
>  		retry = 2;
>  		srb->pdata = (unsigned char *)buf_addr;
> -		if (blks > USB_MAX_XFER_BLK)
> -			smallblks = USB_MAX_XFER_BLK;
> +		if (blks > usb_cur_xfer_blk)
> +			smallblks = usb_cur_xfer_blk;
>  		else
>  			smallblks = (unsigned short) blks;
>  retry_it:
> -		if (smallblks == USB_MAX_XFER_BLK)
> +		debug("usb_read: retry #%d, usb_cur_xfer_blk %hu, smallblks %hu\n",
> +		      retry, usb_cur_xfer_blk, smallblks);
> +		if (smallblks == usb_cur_xfer_blk)
>  			usb_show_progress();
>  		srb->datalen = block_dev->blksz * smallblks;
>  		srb->pdata = (unsigned char *)buf_addr;
>  		if (usb_read_10(srb, ss, start, smallblks)) {
>  			debug("Read ERROR\n");
>  			usb_request_sense(srb, ss);
> -			if (retry--)
> +			if (retry--) {
> +				/* decrease the usb_cur_xfer_blk */
> +				unsigned short size = USB_CUR_XFER_BLK(pos - 1);
> +				if (size >= USB_MIN_XFER_BLK) {
> +					smallblks = size;
> +					usb_cur_xfer_blk = smallblks;
> +					pos--;
> +				}
> +				retry_flag = true;
>  				goto retry_it;

What is the reason for having the same code twice in this patch ? Just
pull the identical stuff into a function.

> +			}
>  			blkcnt -= blks;
>  			break;
>  		}
>  		start += smallblks;
>  		blks -= smallblks;
>  		buf_addr += srb->datalen;
> +
> +		/* try to increase the usb_cur_xfer_blk */
> +		if (!retry_flag) {
> +			unsigned short size = USB_CUR_XFER_BLK(pos + 1);
> +			if (size <= blks && size <= USB_MAX_XFER_BLK) {
> +				usb_cur_xfer_blk = size;
> +				pos++;
> +			}
> +		}
>  	} while (blks != 0);
>  	ss->flags &= ~USB_READY;
>  
> @@ -1181,7 +1206,7 @@ retry_it:
>  	      start, smallblks, buf_addr);
>  
>  	usb_disable_asynch(0); /* asynch transfer allowed */
> -	if (blkcnt >= USB_MAX_XFER_BLK)
> +	if (blkcnt >= usb_cur_xfer_blk)
>  		debug("\n");
>  	return blkcnt;
>  }
> @@ -1199,11 +1224,13 @@ static unsigned long usb_stor_write(struct blk_desc *block_dev, lbaint_t blknr,
>  	unsigned short smallblks;
>  	struct usb_device *udev;
>  	struct us_data *ss;
> -	int retry;
> +	int retry, pos = 0;
> +	bool retry_flag = false;
>  	ccb *srb = &usb_ccb;
>  #ifdef CONFIG_BLK
>  	struct blk_desc *block_dev;
>  #endif
> +	unsigned short usb_cur_xfer_blk = USB_CUR_XFER_BLK(pos);
>  
>  	if (blkcnt == 0)
>  		return 0;
> @@ -1239,26 +1266,46 @@ static unsigned long usb_stor_write(struct blk_desc *block_dev, lbaint_t blknr,
>  		 */
>  		retry = 2;
>  		srb->pdata = (unsigned char *)buf_addr;
> -		if (blks > USB_MAX_XFER_BLK)
> -			smallblks = USB_MAX_XFER_BLK;
> +		if (blks > usb_cur_xfer_blk)
> +			smallblks = usb_cur_xfer_blk;
>  		else
>  			smallblks = (unsigned short) blks;
>  retry_it:
> -		if (smallblks == USB_MAX_XFER_BLK)
> +		debug("usb_write: retry #%d, usb_cur_xfer_blk %hu, smallblks %hu\n",
> +		      retry, usb_cur_xfer_blk, smallblks);
> +		if (smallblks == usb_cur_xfer_blk)
>  			usb_show_progress();
>  		srb->datalen = block_dev->blksz * smallblks;
>  		srb->pdata = (unsigned char *)buf_addr;
>  		if (usb_write_10(srb, ss, start, smallblks)) {
>  			debug("Write ERROR\n");
>  			usb_request_sense(srb, ss);
> -			if (retry--)
> +			if (retry--) {
> +				/* decrease the usb_cur_xfer_blk */
> +				unsigned short size = USB_CUR_XFER_BLK(pos - 1);
> +				if (size >= USB_MIN_XFER_BLK) {
> +					smallblks = size;
> +					usb_cur_xfer_blk = smallblks;
> +					pos--;
> +				}
> +				retry_flag = true;
>  				goto retry_it;
> +			}
>  			blkcnt -= blks;
>  			break;
>  		}
>  		start += smallblks;
>  		blks -= smallblks;
>  		buf_addr += srb->datalen;
> +
> +		/* try to increase the usb_cur_xfer_blk */
> +		if (!retry_flag) {
> +			unsigned short size = USB_CUR_XFER_BLK(pos + 1);
> +			if (size <= blks && size <= USB_MAX_XFER_BLK) {
> +				usb_cur_xfer_blk = size;
> +				pos++;
> +			}
> +		}
>  	} while (blks != 0);
>  	ss->flags &= ~USB_READY;
>  
> @@ -1266,7 +1313,7 @@ retry_it:
>  	      PRIxPTR "\n", start, smallblks, buf_addr);
>  
>  	usb_disable_asynch(0); /* asynch transfer allowed */
> -	if (blkcnt >= USB_MAX_XFER_BLK)
> +	if (blkcnt >= usb_cur_xfer_blk)
>  		debug("\n");
>  	return blkcnt;
>  
> 


-- 
Best regards,
Marek Vasut

  reply	other threads:[~2016-06-03 22:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02  4:56 [U-Boot] [PATCH v2] common: usb_storage : Implement logic to calculate optimal usb maximum trasfer blocks Rajesh Bhagat
2016-06-03 22:51 ` Marek Vasut [this message]
2016-06-06  4:19   ` Rajesh Bhagat
2016-06-06 13:19     ` 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=57520A01.6060402@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox