RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

[Subbaraya Sundeep Bhatta]

Please ignore got the answer.

> -----Original Message-----
> From: Subbaraya Sundeep Bhatta
> Sent: Wednesday, September 23, 2015 12:29 PM
> To: 'Peter Chen'; Punnaiah Choudary Kalluri
> Cc: 'Nathan Sullivan'; 'sundeep subbaraya'; 'robh+dt@xxxxxxxxxx';
> 'pawel.moll@xxxxxxx'; 'Mark Rutland'; 'ijc+devicetree@xxxxxxxxxxxxxx'; 'Kumar
> Gala'; 'Greg Kroah-Hartman'; 'devicetree@xxxxxxxxxxxxxxx'; 'linux-
> kernel@xxxxxxxxxxxxxxx'; 'linux-usb@xxxxxxxxxxxxxxx'
> Subject: RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> 
> Hi Nathan and Peter,
> 
> Is this patch applied? Please let me know I have some other patches to send on
> top of this.
> 
> Thanks,
> Sundeep
> 
> > -----Original Message-----
> > From: Subbaraya Sundeep Bhatta
> > Sent: Tuesday, September 01, 2015 12:22 PM
> > To: 'Peter Chen'; Punnaiah Choudary Kalluri
> > Cc: Nathan Sullivan; sundeep subbaraya; robh+dt@xxxxxxxxxx;
> > pawel.moll@xxxxxxx; Mark Rutland; ijc+devicetree@xxxxxxxxxxxxxx; Kumar
> > Gala; Greg Kroah-Hartman; devicetree@xxxxxxxxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx
> > Subject: RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> >
> > Hi,
> >
> > > -----Original Message-----
> > > From: Peter Chen [mailto:peter.chen@xxxxxxxxxxxxx]
> > > Sent: Monday, August 31, 2015 7:59 AM
> > > To: Punnaiah Choudary Kalluri
> > > Cc: Nathan Sullivan; sundeep subbaraya; Subbaraya Sundeep Bhatta;
> > > robh+dt@xxxxxxxxxx; pawel.moll@xxxxxxx; Mark Rutland;
> > > ijc+devicetree@xxxxxxxxxxxxxx; Kumar Gala; Greg Kroah-Hartman;
> > > devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> > > usb@xxxxxxxxxxxxxxx
> > > Subject: Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform
> > > data
> > >
> > > On Mon, Aug 31, 2015 at 09:01:51AM +0530, punnaiah choudary kalluri
> > > wrote:
> > > > On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen
> > > <peter.chen@xxxxxxxxxxxxx> wrote:
> > > > > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote:
> > > > >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote:
> > > > >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote:
> > > > >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary
> > > kalluri wrote:
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen
> > > <peter.chen@xxxxxxxxxxxxx> wrote:
> > > > >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep
> > > subbaraya wrote:
> > > > >> > > > >> Hi,
> > > > >> > > > >>
> > > > >> > > > >>
> > > > >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan
> > > <nathan.sullivan@xxxxxx> wrote:
> > > > >> > > > >> > The Xilinx Zynq udc does not need the
> > > > >> > > > >> > CI_HDRC_DISABLE_STREAMING flag, unlike the default
> > > > >> > > > >> > platform data.  Add platform data specific to the Zynq udc.
> > > > >> > > > >> >
> > > > >> > > > >> > Based on a patch by the same name from the Xilinx
> > > > >> > > > >> > vendor
> > > tree.
> > > > >> > > > >>
> > > > >> > > > >> I am that Xilinx guy who sent this patch :). It is in
> > > > >> > > > >> Xilinx tree as temporary fix and I did not debug
> > > > >> > > > >> further why UDC works only when streaming is enabled.
> > > > >> > > > >> Probably this is right time to post my question here.
> > > > >> > > > >> I was expecting like:
> > > > >> > > > >> Streaming disabled - both low bandwidth and high
> > > > >> > > > >> bandwidth systems should work fine Streaming enabled -
> > > > >> > > > >> only for high bandwidth systems but this is not the
> > > > >> > > > >> case, Zynq UDC works only when Streaming is enabled.
> > > > >> > > > >> Please correct me if I am wrong.
> > > > >> > > > >
> > > > >> > > > > You are right, stream mode disabled should work at anytime.
> > > > >> > > > > It is so strange why zynq UDC only works when stream
> > > > >> > > > > mode is
> > > enabled.
> > > > >> > > >
> > > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS
> > > > >> > > > controllervDoc 2.20a,  this is what it says about SDIS
> > > > >> > > > (streaming mode disable option)
> > > > >> > > >
> > > > >> > > > Before activating this mode, the user must check if the
> > > > >> > > > TX latency buffers per endpoint are able to accommodate
> > > > >> > > > at least one entire maximum size packet. The RX buffer
> > > > >> > > > size must, at least, double the TX buffer size per
> > > > >> > > > endpoint. To optimize the stream disable performance,
> > > > >> > > > system bus burst must be set as high as possible.
> > > > >> > > > When the stream disable mode is used, the burst size
> > > > >> > > > (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a
> > > integer
> > > > >> > > > sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH
> > > > >> > > > for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If
> > > > >> > > > this is not respected the controller will not work
> > > > >> > > > properly in stream disable mode.
> > > > >> > > > The stream disable mode should just be used in situations
> > > > >> > > > where the available system bandwidth is low or the system
> > > > >> > > > bus access latency is high, in order to avoid underruns
> > > > >> > > > and overruns in the latency buffers. This works for all
> > > > >> > > > types of endpoints, except for ISO endpoints.
> > > > >> > > > Such a system can't ensure the real time support that the
> > > > >> > > > ISO endpoints require, so the ISO endpoints are not
> > > > >> > > > supported when the SDIS bit is set.
> > > > >> > > >
> > > > >> > > > Definitely we need to root cause why disable streaming
> > > > >> > > > mode is not working for zynq but from controller spec
> > > > >> > > > point of view it is possible that controller not work
> > > > >> > > > properly in stream disable mode.
> > > > >> > > >
> > > > >> > > > Regards,
> > > > >> > > > Punnaiah
> > > > >> > > >
> > > > >> > >
> > > > >> > > Maybe the burst size isn't set correctly by default?  It
> > > > >> > > does say the controller won't work correctly with stream
> > > > >> > > disable set and an invalid burst size.  Looks like TX and
> > > > >> > > RX burst both default
> > > to 16, per the Zynq manual.
> > > > >> > >
> > > > >> > > With the stream disable bit set, the behvior we see on our
> > > > >> > > hardware is that priming just stops, with an outstanding
> > > > >> > > transfer in memory marked active in the status field by the
> > > > >> > > controller.  This happens at random, even when doing single
> > > > >> > > transfers at a time like with g_ether set to have a queue
> > > > >> > > size of 1.  With SDIS clear everything works great.  Given
> > > > >> > > that the Zynq
> > > is not bandwidth constrained, it seems like SDIS clear should be the default.
> > > > >> > >
> > > > >> >
> > > > >> > I suspect the possible reason is the tx buffer for each
> > > > >> > endpoint is small (<=512 bytes), so it can't copy one packet
> > > > >> > (assume max packet size for bulk) to tx buffer, then the
> > > > >> > prime can't be
> > finished.
> > > > >> >
> > > > >> > Would you help to dump the registers HWTXBUF ($BASE + 0x10)
> > > > >> > and DCCPARAMS ($BASE + 124)?
> > > > >> >
> > > > >> > tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) /
> > > DCCPARAMS.DEN) *
> > > > >> > (DWORD_PER_BYTES)
> > > > >> >
> > > > >> > DWORD_PER_BYTES is 4
> > > > >> >
> > > > >> > --
> > > > >> >
> > > > >> > Best Regards,
> > > > >> > Peter Chen
> > > > >>
> > > > >> HWTXBUF is 0x80060A10, DCCPARAMS is 0xE0003124.
> > > > >
> > > > > Are you sure you read correct address? Your DCCPARAMS means it
> > > > > is host capable, but not device capable.
> > > >
> > > > HWTXBUF is 0x8060A10
> > > > DCCPARAMS is 0x0000018C
> > > >
> > > > VUSB_HS_TX_ADD - 0xA
> > > > DEN - 0xC
> > > >
> > > > From the above formula tx buffer size is 341.33 bytes.
> > > >
> > > >
> > >
> > > ok, so your platform can't use stream mode disabled.
> >
> > This is patch can be applied then. Thank you all.
> >
> > Sundeep
> > >
> > > --
> > >
> > > Best Regards,
> > > Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/