Re: [RFC 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 6377 bytes --]


Hi,

Wesley Cheng <wcheng@codeaurora.org> writes:
> Some devices have USB compositions which may require multiple endpoints
> that support EP bursting.  HW defined TX FIFO sizes may not always be
> sufficient for these compositions.  By utilizing flexible TX FIFO
> allocation, this allows for endpoints to request the required FIFO depth to
> achieve higher bandwidth.  With some higher bMaxBurst configurations, using
> a larger TX FIFO size results in better TX throughput.

This needs to be carefully thought out as it can introduce situations
where gadget drivers that worked previously stop working.

> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4c171a8..e815c13 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -675,6 +675,7 @@ struct dwc3_event_buffer {
>   *		isochronous START TRANSFER command failure workaround
>   * @start_cmd_status: the status of testing START TRANSFER command with
>   *		combo_num = 'b00
> + * @fifo_depth: allocated TXFIFO depth
>   */
>  struct dwc3_ep {
>  	struct usb_ep		endpoint;
> @@ -718,6 +719,7 @@ struct dwc3_ep {
>  	u8			resource_index;
>  	u32			frame_number;
>  	u32			interval;
> +	int			fifo_depth;
>  
>  	char			name[20];
>  
> @@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
>   * 	1	- utmi_l1_suspend_n
>   * @is_fpga: true when we are using the FPGA board
>   * @pending_events: true when we have pending IRQs to be handled
> + * @needs_fifo_resize: not all users might want fifo resizing, flag it
>   * @pullups_connected: true when Run/Stop bit is set
>   * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
>   * @three_stage_setup: set if we perform a three phase setup
> @@ -1044,6 +1047,7 @@ struct dwc3_scratchpad_array {
>   * @dis_metastability_quirk: set to disable metastability quirk.
>   * @imod_interval: set the interrupt moderation interval in 250ns
>   *                 increments or 0 to disable.
> + * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
>   */
>  struct dwc3 {
>  	struct work_struct	drd_work;
> @@ -1204,6 +1208,7 @@ struct dwc3 {
>  	unsigned		is_utmi_l1_suspend:1;
>  	unsigned		is_fpga:1;
>  	unsigned		pending_events:1;
> +	unsigned		needs_fifo_resize:1;

Instead of passing a flag, this could be detected in runtime during ->udc_start()

> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 6dee4da..7ee2302 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -611,6 +612,43 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct usb_ctrlrequest *ctrl)
>  		return -EINVAL;
>  
>  	case USB_STATE_ADDRESS:

are you sure it's safe to fiddle with TX FIFO allocation at SetAddress()
time?

> +		/*
> +		 * If tx-fifo-resize flag is not set for the controller, then
> +		 * do not clear existing allocated TXFIFO since we do not
> +		 * allocate it again in dwc3_gadget_resize_tx_fifos
> +		 */
> +		if (dwc->needs_fifo_resize) {
> +			/* Read ep0IN related TXFIFO size */
> +			dep = dwc->eps[1];
> +			size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
> +			if (dwc3_is_usb31(dwc))
> +				dep->fifo_depth = DWC31_GTXFIFOSIZ_TXFDEP(size);
> +			else
> +				dep->fifo_depth = DWC3_GTXFIFOSIZ_TXFDEP(size);
> +
> +			dwc->last_fifo_depth = dep->fifo_depth;
> +			/* Clear existing TXFIFO for all IN eps except ep0 */
> +			for (num = 3; num < min_t(int, dwc->num_eps,
> +				DWC3_ENDPOINTS_NUM); num += 2) {
> +				dep = dwc->eps[num];
> +				/* Don't change TXFRAMNUM on usb31 version */
> +				size = dwc3_is_usb31(dwc) ?
> +					dwc3_readl(dwc->regs,
> +						   DWC3_GTXFIFOSIZ(num >> 1)) &
> +						   DWC31_GTXFIFOSIZ_TXFRAMNUM :
> +						   0;
> +
> +				dwc3_writel(dwc->regs,
> +					    DWC3_GTXFIFOSIZ(num >> 1),
> +					    size);
> +				dep->fifo_depth = 0;
> +
> +				dev_dbg(dwc->dev, "%s(): %s fifo_depth:%x\n",
> +					__func__, dep->name,
> +					dep->fifo_depth);

no dev_dbg() calls in this driver, please.

> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 00746c2..6baca05 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -540,6 +540,97 @@ static int dwc3_gadget_start_config(struct dwc3_ep *dep)
>  	return 0;
>  }
>  
> +/*
> + * dwc3_gadget_resize_tx_fifos - reallocate fifo spaces for current use-case
> + * @dwc: pointer to our context structure
> + *
> + * This function will a best effort FIFO allocation in order
> + * to improve FIFO usage and throughput, while still allowing
> + * us to enable as many endpoints as possible.
> + *
> + * Keep in mind that this operation will be highly dependent
> + * on the configured size for RAM1 - which contains TxFifo -,
> + * the amount of endpoints enabled on coreConsultant tool, and
> + * the width of the Master Bus.
> + *
> + * In the ideal world, we would always be able to satisfy the
> + * following equation:
> + *
> + * ((512 + 2 * MDWIDTH-Bytes) + (Number of IN Endpoints - 1) * \
> + * (3 * (1024 + MDWIDTH-Bytes) + MDWIDTH-Bytes)) / MDWIDTH-Bytes
> + *
> + * Unfortunately, due to many variables that's not always the case.
> + */
> +static int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc, struct dwc3_ep *dep)
> +{
> +	int fifo_size, mdwidth, max_packet = 1024;
> +	int tmp, mult = 1, fifo_0_start, ram1_depth;
> +
> +	if (!dwc->needs_fifo_resize)
> +		return 0;
> +
> +	/* resize IN endpoints excepts ep0 */

typo: excepts

> +	if (!usb_endpoint_dir_in(dep->endpoint.desc) || dep->number <= 1)
> +		return 0;
> +
> +	/* Don't resize already resized IN endpoint */
> +	if (dep->fifo_depth) {
> +		dev_dbg(dwc->dev, "%s fifo_depth:%d is already set\n",
> +					dep->endpoint.name, dep->fifo_depth);

no dev_dbg()

> @@ -620,6 +711,10 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action)
>  	int			ret;
>  
>  	if (!(dep->flags & DWC3_EP_ENABLED)) {
> +		ret = dwc3_gadget_resize_tx_fifos(dwc, dep);

technically, you're no resizing a single FIFO. In any case, what happens
when you run out of space midway through the resizing? You already
accepted the gadget driver, you're already bound to it, then you resize
the FIFOs and things start to fall apart. How do we handle that?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]