linux-kernel - Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGnW=BYMnOFTaMQJtLXZ9ckCEHs+gCOCQR0VQFfO4HP=SMHBDQ@mail.gmail.com>
Date:	Thu, 27 Aug 2015 13:11:30 +0530
From:	punnaiah choudary kalluri <punnaia@...inx.com>
To:	Peter Chen <peter.chen@...escale.com>
Cc:	sundeep subbaraya <sundeep.lkml@...il.com>,
	Nathan Sullivan <nathan.sullivan@...com>,
	Subbaraya Sundeep Bhatta <sbhatta@...inx.com>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"pawel.moll@....com" <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	"ijc+devicetree@...lion.org.uk" <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

Hi,

On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen <peter.chen@...escale.com> 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@...com> 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

>
> Peter
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/