All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Majewski <lukma@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/7] usb: rockchip: fix command failed on host side due to missing data
Date: Tue, 3 Jul 2018 23:24:34 +0200	[thread overview]
Message-ID: <20180703232434.69c85aa0@jawa> (raw)
In-Reply-To: <1530644652-12537-2-git-send-email-alberto@amarulasolutions.com>

Hi Alberto,

> Two consecutive rockusb_tx_write without waiting for request complete
> do results in transfer reset of first request and thus no or
> incomplete data transfer. This because rockusb_tx_write do use just
> une request to keep serialization.
> 
> So calls like:
> rockusb_tx_write_str(emmc_id);
> rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length, CSW_GOOD);
> 
> was succeeding only when DEBUG was defined because the time spent
> printing debug info was enough for request to complete.

Serialization by printf..... 

> 
> This patch add a way to postpone sending csw after first
> rockusb_tx_write is completed (indeed inside rockusb_complete) fixing
> execution of: $ rkdeveloptool rfi
> when DEBUG is not defined.
> 
> Signed-off-by: Alberto Panizzo <alberto@amarulasolutions.com>
> ---
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h |  1 +
>  drivers/usb/gadget/f_rockusb.c                 | 37
> ++++++++++++++++++++++---- 2 files changed, 33 insertions(+), 5
> deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> b/arch/arm/include/asm/arch-rockchip/f_rockusb.h index
> 0b62771..f5cad8e 100644 ---
> a/arch/arm/include/asm/arch-rockchip/f_rockusb.h +++
> b/arch/arm/include/asm/arch-rockchip/f_rockusb.h @@ -124,6 +124,7 @@
> struct f_rockusb { int reboot_flag;
>  	void *buf;
>  	void *buf_head;
> +	struct bulk_cs_wrap *next_csw;
>  };
>  
>  /* init rockusb device, tell rockusb which device you want to
> read/write*/ diff --git a/drivers/usb/gadget/f_rockusb.c
> b/drivers/usb/gadget/f_rockusb.c index b8833d0..a39ad51 100644
> --- a/drivers/usb/gadget/f_rockusb.c
> +++ b/drivers/usb/gadget/f_rockusb.c
> @@ -97,6 +97,7 @@ static struct usb_gadget_strings *rkusb_strings[] =
> { 
>  static struct f_rockusb *rockusb_func;
>  static void rx_handler_command(struct usb_ep *ep, struct usb_request
> *req); +static int rockusb_tx_write(const char *buffer, unsigned int
> buffer_size); static int rockusb_tx_write_csw(u32 tag, int residue,
> u8 status, int size); 
>  struct f_rockusb *get_rkusb(void)
> @@ -136,11 +137,22 @@ struct usb_endpoint_descriptor *hs)
>  
>  static void rockusb_complete(struct usb_ep *ep, struct usb_request
> *req) {
> +	struct f_rockusb *f_rkusb = get_rkusb();
>  	int status = req->status;
>  
> -	if (!status)
> -		return;
> -	debug("status: %d ep '%s' trans: %d\n", status, ep->name,
> req->actual);
> +	if (status)
> +		debug("status: %d ep '%s' trans: %d\n",
> +		      status, ep->name, req->actual);
> +
> +	/* Send Command Status on previous transfer complete */
> +	if (f_rkusb->next_csw) {
		     ^^^^^^^^ - isn't this a bit misleading? We send
		     the status for the previous transfer.

> +#ifdef DEBUG
> +		printcsw((char *)f_rkusb->next_csw);
> +#endif
> +		rockusb_tx_write((char *)f_rkusb->next_csw,
> +				 USB_BULK_CS_WRAP_LEN);
> +	}
> +	f_rkusb->next_csw = NULL;
>  }
>  
>  /* config the rockusb device*/
> @@ -388,6 +400,21 @@ static int rockusb_tx_write_csw(u32 tag, int
> residue, u8 status, int size) return rockusb_tx_write((char *)csw,
> size); }
>  
> +struct bulk_cs_wrap g_next_csw;

You have added the pointer to struct bulk_cs_wrap_g to struct
f_rockusb, and here we do have global definition.

Two issues with cache; alignment and padding.

Maybe it would be better to allocate it and store pointer int struct
f_rockusb ?

> +static void rockusb_tx_write_csw_on_complete(u32 tag, int residue,
> u8 status) +{
> +	struct f_rockusb *f_rkusb = get_rkusb();
> +
> +	g_next_csw.signature = cpu_to_le32(USB_BULK_CS_SIG);
> +	g_next_csw.tag = tag;
> +	g_next_csw.residue = cpu_to_be32(residue);
> +	g_next_csw.status = status;
> +#ifdef DEBUG
> +	printcsw((char *)&g_next_csw);
> +#endif
> +	f_rkusb->next_csw = &g_next_csw;
> +}
> +
>  static unsigned int rx_bytes_expected(struct usb_ep *ep)
>  {
>  	struct f_rockusb *f_rkusb = get_rkusb();
> @@ -501,8 +528,8 @@ static void cb_read_storage_id(struct usb_ep *ep,
> struct usb_request *req) printf("read storage id\n");
>  	memcpy((char *)cbw, req->buf, USB_BULK_CB_WRAP_LEN);
>  	rockusb_tx_write_str(emmc_id);
> -	rockusb_tx_write_csw(cbw->tag, cbw->data_transfer_length,
> CSW_GOOD,
> -			     USB_BULK_CS_WRAP_LEN);
> +	rockusb_tx_write_csw_on_complete(cbw->tag,
> cbw->data_transfer_length,
> +					 CSW_GOOD);

It seems like you are preparing the content of the csw structure to be
ready when the completion is called. Am I right?

What I'm concerned about - with your patch we do have two functions
with almost the same code - namely rockusb_tx_write_csw() and
rockusb_tx_write_csw_on_complete(). 

Would it be possible to unify (reuse) the code?

One more remark - shouldn't we set content of g_next_csw in the
rockusb_complete() ?

>  }
>  
>  static void cb_write_lba(struct usb_ep *ep, struct usb_request *req)




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180703/ad42e197/attachment.sig>

  reply	other threads:[~2018-07-03 21:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03 19:02 [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 1/7] usb: rockchip: fix command failed on host side due to missing data Alberto Panizzo
2018-07-03 21:24   ` Lukasz Majewski [this message]
2018-07-04 10:11     ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 2/7] usb: rockchip: implement skeleton for K_FW_GET_CHIP_VER command Alberto Panizzo
2018-07-03 21:33   ` Lukasz Majewski
2018-07-04 13:27     ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 3/7] rockchip: rk3288: implement reading chip version from bootrom code Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 4/7] usb: rockchip: implement K_FW_LBA_READ_10 command Alberto Panizzo
2018-07-03 21:42   ` Lukasz Majewski
2018-07-04 13:36     ` Alberto Panizzo
2018-07-05  1:19   ` Kever Yang
2018-07-05  8:52     ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 5/7] usb: rockchip: implement K_FW_LBA_ERASE_10 command Alberto Panizzo
2018-07-03 21:47   ` Lukasz Majewski
2018-07-03 19:02 ` [U-Boot] [PATCH 6/7] usb: rockchip: be quiet on serial port while transferring data Alberto Panizzo
2018-07-03 21:49   ` Lukasz Majewski
2018-07-04 13:44     ` Alberto Panizzo
2018-07-03 19:02 ` [U-Boot] [PATCH 7/7] usb: rockchip: boost up write speed from 4MB/s to 15MB/s Alberto Panizzo
2018-07-05  1:15 ` [U-Boot] [PATCH 0/7] Improve rockusb support in U-Boot Kever Yang
2018-07-05  8:39   ` Alberto Panizzo
2018-07-05  9:07     ` Lukasz Majewski

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=20180703232434.69c85aa0@jawa \
    --to=lukma@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.