On Mon, Feb 24, 2014 at 04:03:15PM +0800, Neil Zhang wrote:
> There is an issue with the add dTD tripwire semaphore (ATDTW bit in
> USBCMD register) that can cause the controller to ignore a dTD that is
> added to a primed endpoint. When this happens, the software can read
> the tripwire bit and the status bit at '1' even though the endpoint
> is unprimed.
>
> After executing a dTD, the device controller endpoint state machine
> executes a final read of the dTD terminate bit to check if the
> application added a dTD to the linked list at the last moment. This read
> is done in the finpkt_read_latest_next_td (44) state. After the read is
> performed, if the terminate bit is still set, the state machine moves to
> unprime the endpoint. The decision to unprime the endpoint is done in
> the checkqh_decision (59) state, based on the value of the terminate bit.
>
> Before reaching the checkqh_decision state, the state machine traverses
> the writeqhtd_status (57), writeqh_status (56), and release_prime_mask
> (42) states. As shown in the waveform, the ep_addtd_tripwire_clr signal
> is not set to clear the tripwire bit in these states.
>
> Signed-off-by: Neil Zhang <zhan...@marvell.com>
> ---
> drivers/usb/gadget/mv_udc_core.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/usb/gadget/mv_udc_core.c
> b/drivers/usb/gadget/mv_udc_core.c
> index a620cff..8df8606 100644
> --- a/drivers/usb/gadget/mv_udc_core.c
> +++ b/drivers/usb/gadget/mv_udc_core.c
> @@ -196,7 +196,27 @@ static int process_ep_req(struct mv_udc *udc, int index,
> while (readl(&udc->op_regs->epstatus) & bit_pos)
> udelay(1);
> break;
> + } else {
> + if (!(readl(&udc->op_regs->epstatus) & bit_pos)) {
> + /* The DMA engine thinks there is no more dTD */
> + curr_dqh->next_dtd_ptr = curr_dtd->dtd_next
> + & EP_QUEUE_HEAD_NEXT_POINTER_MASK;
> +
> + /* clear active and halt bit */
> + curr_dqh->size_ioc_int_sts &=
> + ~(DTD_STATUS_ACTIVE
> + | DTD_STATUS_HALTED);
> +
> + /* Do prime again */
> + wmb();
> + writel(bit_pos, &udc->op_regs->epprime);
> + while (readl(&udc->op_regs->epprime) & bit_pos)
> + cpu_relax();
> +
> + break;
> + }
> }
> +
> udelay(1);
> }
>
Is it a chipidea IP issue? Any errate number for this issue?
Does we need it for chipidea driver?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
