mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roman Bacik <rbacik@broadcom.com>
To: John Youn <John.Youn@synopsys.com>,
	Scott Branden <sbranden@broadcom.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>
Subject: RE: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
Date: Thu, 10 Sep 2015 02:35:54 +0000	[thread overview]
Message-ID: <D2C8DF24C22DB24BA948A8B0D097284002F277FF@SJEXCHMB05.corp.ad.broadcom.com> (raw)
In-Reply-To: <2B3535C5ECE8B5419E3ECBE30077290901DC35F89D@US01WEMBX2.internal.synopsys.com>

> -----Original Message-----
> From: John Youn [mailto:John.Youn@synopsys.com]
> Sent: September-09-15 7:25 PM
> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> usb@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode
> 
> On 9/9/2015 7:16 PM, Roman Bacik wrote:
> >> -----Original Message-----
> >> From: John Youn [mailto:John.Youn@synopsys.com]
> >> Sent: September-09-15 7:11 PM
> >> To: Roman Bacik; John Youn; Scott Branden; Greg Kroah-Hartman; linux-
> >> usb@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> >> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> >> isochronous mode
> >>
> >> On 9/9/2015 11:16 AM, Roman Bacik wrote:
> >>>> -----Original Message-----
> >>>> From: John Youn [mailto:John.Youn@synopsys.com]
> >>>> Sent: September-03-15 11:53 PM
> >>>> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux-
> >>>> usb@vger.kernel.org; Roman Bacik
> >>>> Cc: linux-kernel@vger.kernel.org; bcm-kernel-feedback-list
> >>>> Subject: Re: [PATCH v2 1/1] usb: dwc2: gadget: parity fix in
> >>>> isochronous mode
> >>>>
> >>>> On 8/31/2015 9:17 AM, Scott Branden wrote:
> >>>>> From: Roman Bacik <rbacik@broadcom.com>
> >>>>>
> >>>>> USB OTG driver in isochronous mode has to set the parity of the
> >>>>> receiving microframe. The parity is set to even by default. This
> >>>>> causes problems for an audio gadget, if the host starts
> >>>>> transmitting on odd
> >>>> microframes.
> >>>>>
> >>>>> This fix uses Incomplete Periodic Transfer interrupt to toggle
> >>>>> between even and odd parity until the Transfer Complete interrupt
> >>>>> is
> >> received.
> >>>>>
> >>>>> Signed-off-by: Roman Bacik <rbacik@broadcom.com>
> >>>>> Reviewed-by: Abhinav Ratna <aratna@broadcom.com>
> >>>>> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
> >>>>> Signed-off-by: Scott Branden <sbranden@broadcom.com>
> >>>>> ---
> >>>>>  drivers/usb/dwc2/core.h   |  1 +
> >>>>>  drivers/usb/dwc2/gadget.c | 51
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++-
> >>>>>  drivers/usb/dwc2/hw.h     |  1 +
> >>>>>  3 files changed, 52 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> >>>>> index 0ed87620..a5634fd 100644
> >>>>> --- a/drivers/usb/dwc2/core.h
> >>>>> +++ b/drivers/usb/dwc2/core.h
> >>>>> @@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
> >>>>>  	unsigned int            periodic:1;
> >>>>>  	unsigned int            isochronous:1;
> >>>>>  	unsigned int            send_zlp:1;
> >>>>> +	unsigned int            has_correct_parity:1;
> >>>>>
> >>>>>  	char                    name[10];
> >>>>>  };
> >>>>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> >>>>> index 4d47b7c..fac3e2f 100644
> >>>>> --- a/drivers/usb/dwc2/gadget.c
> >>>>> +++ b/drivers/usb/dwc2/gadget.c
> >>>>> @@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct
> >>>>> dwc2_hsotg
> >>>> *hsotg, unsigned int idx,
> >>>>>  		ints &= ~DXEPINT_XFERCOMPL;
> >>>>>
> >>>>>  	if (ints & DXEPINT_XFERCOMPL) {
> >>>>> +		hs_ep->has_correct_parity = 1;
> >>>>>  		if (hs_ep->isochronous && hs_ep->interval == 1) {
> >>>>>  			if (ctrl & DXEPCTL_EOFRNUM)
> >>>>>  				ctrl |= DXEPCTL_SETEVENFR;
> >>>>> @@ -2316,7 +2317,8 @@ void
> s3c_hsotg_core_init_disconnected(struct
> >>>> dwc2_hsotg *hsotg,
> >>>>>  		GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
> >>>>>  		GINTSTS_RESETDET | GINTSTS_ENUMDONE |
> >>>>>  		GINTSTS_OTGINT | GINTSTS_USBSUSP |
> >>>>> -		GINTSTS_WKUPINT,
> >>>>> +		GINTSTS_WKUPINT |
> >>>>> +		GINTSTS_INCOMPL_SOIN |
> GINTSTS_INCOMPL_SOOUT,
> >>>>>  		hsotg->regs + GINTMSK);
> >>>>>
> >>>>>  	if (using_dma(hsotg))
> >>>>> @@ -2581,6 +2583,52 @@ irq_retry:
> >>>>>  		s3c_hsotg_dump(hsotg);
> >>>>>  	}
> >>>>>
> >>>>> +	if (gintsts & GINTSTS_INCOMPL_SOIN) {
> >>>>> +		u32 idx, epctl_reg, ctrl;
> >>>>> +		struct s3c_hsotg_ep *hs_ep;
> >>>>> +
> >>>>> +		dev_dbg(hsotg->dev, "%s:
> GINTSTS_INCOMPL_SOIN\n",
> >>>> __func__);
> >>>>> +		for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> >>>>
> >>>> Valid endpoints are only up to hsotg->num_of_eps so this might
> >>>> crash on certain configurations.
> >>>>
> >>>> Also, have you tried to find the endpoint which caused the
> >>>> incomplete interrupt by reading the control registers as described in
> the databook?
> >>>>
> >>>
> >>> We are using procedure based on description from this source:
> >>>
> >>> Synopsys, Inc. SolvNet 527
> >>> DesignWare.com
> >>> 3.00a
> >>> April 2012
> >>> USB 2.0 Hi-Speed On-The-Go (OTG) Databook Isochronous Endpoints in
> >>> DWC_otg Slave Mode
> >>>
> >>> Synopsys databook is not in a public domain to quote the exact
> >>> paragraph
> >> here. You can find it in Chapter E, pp 526-527. There is no register
> >> in this databook, which would provide information about the source
> >> endpoint of the incomplete interrupt, as you have described.
> >>>
> >>> Please, provide an exact reference and possibly enough information
> >>> that
> >> we can turn it into a working code.
> >>>
> >>
> >> You can check the source of the interrupt by reading the DSTS and ep
> >> control registers as described in the databook page 526, last bullet,
> >> and 527 first bullet.
> >>
> >> John
> >>
> >
> > Yes, that is exactly what we are doing what is described in the last bullet of
> 526 and the first two bullets of page 527. So what is the problem?
> >
> 
> Maybe I missed it. Where exactly are you doing it like it says in these two
> paragraphs?
> 
> Quote:
> 
> GINTSTS.incompISOIN is a global interrupt. Therefore, when more than one
> isochronous endpoints is active, then the application must determine which
> isochronous IN endpoints have incomplete data.
> 
> To accomplish this, read DSTS and DIEPCTLn for all isochronous endpoints. If
> DSTS.SOFFN[0] =DIEPCTLn.EO_FrNum (Bit 16),then that endpoint has an
> incomplete transfer
> 
> John
> 
> 

That is the content of the two for loops. I will paste the code here again for your convenience:

> +	if (gintsts & GINTSTS_INCOMPL_SOIN) {
> +		u32 idx, epctl_reg, ctrl;
> +		struct s3c_hsotg_ep *hs_ep;
> +
> +		dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n",
> __func__);
> +		for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> +			hs_ep = hsotg->eps_in[idx];
> +
> +			if (!hs_ep->isochronous || hs_ep-
> >has_correct_parity)
> +				continue;
> +
> +			epctl_reg = DIEPCTL(idx);
> +			ctrl = readl(hsotg->regs + epctl_reg);
> +
> +			if (ctrl & DXEPCTL_EOFRNUM)
> +				ctrl |= DXEPCTL_SETEVENFR;
> +			else
> +				ctrl |= DXEPCTL_SETODDFR;
> +			writel(ctrl, hsotg->regs + epctl_reg);
> +		}
> +		writel(GINTSTS_INCOMPL_SOIN, hsotg->regs + GINTSTS);
> +	}
> +
> +	if (gintsts & GINTSTS_INCOMPL_SOOUT) {
> +		u32 idx, epctl_reg, ctrl;
> +		struct s3c_hsotg_ep *hs_ep;
> +
> +		dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOOUT\n",
> __func__);
> +		for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
> +			hs_ep = hsotg->eps_out[idx];
> +
> +			if (!hs_ep->isochronous || hs_ep-
> >has_correct_parity)
> +				continue;
> +
> +			epctl_reg = DOEPCTL(idx);
> +			ctrl = readl(hsotg->regs + epctl_reg);
> +
> +			if (ctrl & DXEPCTL_EOFRNUM)
> +				ctrl |= DXEPCTL_SETEVENFR;
> +			else
> +				ctrl |= DXEPCTL_SETODDFR;
> +			writel(ctrl, hsotg->regs + epctl_reg);
> +		}
> +		writel(GINTSTS_INCOMPL_SOOUT, hsotg->regs + GINTSTS);
> +	}
> +




  reply	other threads:[~2015-09-10  2:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 16:17 [PATCH v2 0/1] USB DWC2 " Scott Branden
2015-08-31 16:17 ` [PATCH v2 1/1] usb: dwc2: gadget: " Scott Branden
2015-09-03 18:47   ` Roman Bacik
2015-09-04  6:52   ` John Youn
2015-09-09 18:16     ` Roman Bacik
2015-09-10  2:10       ` John Youn
2015-09-10  2:16         ` Roman Bacik
2015-09-10  2:24           ` John Youn
2015-09-10  2:35             ` Roman Bacik [this message]
2015-09-10  2:59             ` Roman Bacik
2015-09-10 17:56             ` Roman Bacik
2015-09-10 19:08               ` John Youn
2015-09-10 19:45                 ` Roman Bacik
2015-09-10  2:24         ` Roman Bacik

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=D2C8DF24C22DB24BA948A8B0D097284002F277FF@SJEXCHMB05.corp.ad.broadcom.com \
    --to=rbacik@broadcom.com \
    --cc=John.Youn@synopsys.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sbranden@broadcom.com \
    /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

all inboxes | Powered by JetHome®