All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@intel.com>
To: chunfeng yun <chunfeng.yun@mediatek.com>,
	Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Felipe Balbi <balbi@ti.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Roger Quadros <rogerq@ti.com>,
	linux-usb@vger.kernel.org, linux-mediatek@lists.infradead.org,
	John Crispin <blogic@openwrt.org>,
	Daniel Kurtz <djkurtz@chromium.org>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller
Date: Mon, 19 Oct 2015 14:25:49 +0300	[thread overview]
Message-ID: <5624D33D.5090807@intel.com> (raw)
In-Reply-To: <1445131519.17024.10.camel@mhfsdcap03>

>>
>> So basically we are trying to use as many microframes as possible with as few packets
>> per microframe as possible.
>>
>> Did I understand this correctly?
> Yes, you are right.
>
>> How will devices react if they expect to get 16 packets every 16th microframe,
>> but they get one packet every microframe instead?
> I think that the synchronous endpoint must specify its period by
> bInterval, but can't specify how data should be transfered during the
> period by the host, and it just only receives data passively. So the
> device can receive data correctly in the case(bInterval is 5).
>
> quote from usb3_r1.0 section4.4.8 Isochronous Transfers:
> "The host can request data from the device or send data to the device at
> any time during the service interval for a particular endpoint on that
> device"
>

As I understand the 4.4.8 section it just means the device can't assume a fixed
time interval between transfers, meaning that the host can use the last microframe
in one esit and the first microframe in the next esit, but still only use 1 microframe
per esit.

Section 8.12.6.1 describes how a 11 packet isoc transfer is allowed to be split
to 1 burst of 11 packets, 2 burst (8 + 3),  3 burst (4+4+3) 6 bursts (2+2+2+2+2+1) or
11 bursts of 1. These are however all within the same microframe. Splitting the
transfer into several microframes in a esit kind of makes the whole interval concept pointless.

-Mathias



  

WARNING: multiple messages have this Message-ID (diff)
From: mathias.nyman@intel.com (Mathias Nyman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller
Date: Mon, 19 Oct 2015 14:25:49 +0300	[thread overview]
Message-ID: <5624D33D.5090807@intel.com> (raw)
In-Reply-To: <1445131519.17024.10.camel@mhfsdcap03>

>>
>> So basically we are trying to use as many microframes as possible with as few packets
>> per microframe as possible.
>>
>> Did I understand this correctly?
> Yes, you are right.
>
>> How will devices react if they expect to get 16 packets every 16th microframe,
>> but they get one packet every microframe instead?
> I think that the synchronous endpoint must specify its period by
> bInterval, but can't specify how data should be transfered during the
> period by the host, and it just only receives data passively. So the
> device can receive data correctly in the case(bInterval is 5).
>
> quote from usb3_r1.0 section4.4.8 Isochronous Transfers:
> "The host can request data from the device or send data to the device at
> any time during the service interval for a particular endpoint on that
> device"
>

As I understand the 4.4.8 section it just means the device can't assume a fixed
time interval between transfers, meaning that the host can use the last microframe
in one esit and the first microframe in the next esit, but still only use 1 microframe
per esit.

Section 8.12.6.1 describes how a 11 packet isoc transfer is allowed to be split
to 1 burst of 11 packets, 2 burst (8 + 3),  3 burst (4+4+3) 6 bursts (2+2+2+2+2+1) or
11 bursts of 1. These are however all within the same microframe. Splitting the
transfer into several microframes in a esit kind of makes the whole interval concept pointless.

-Mathias



  

  reply	other threads:[~2015-10-19 11:25 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29  3:01 [PATCH v9 0/5] Mediatek xHCI support Chunfeng Yun
2015-09-29  3:01 ` Chunfeng Yun
2015-09-29  3:01 ` Chunfeng Yun
2015-09-29  3:01 ` [PATCH v9 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
     [not found]   ` <1443495698-32233-3-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-09-29 14:49     ` Sergei Shtylyov
2015-09-29 14:49       ` Sergei Shtylyov
2015-09-29 14:49       ` Sergei Shtylyov
2015-10-08 11:37       ` chunfeng yun
2015-10-08 11:37         ` chunfeng yun
2015-10-08 11:37         ` chunfeng yun
2015-09-29  3:01 ` [PATCH v9 3/5] phy: add usb3.0 phy driver for mt65xx SoCs Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
     [not found]   ` <1443495698-32233-4-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-10-06 14:20     ` Kishon Vijay Abraham I
2015-10-06 14:20       ` Kishon Vijay Abraham I
2015-10-06 14:20       ` Kishon Vijay Abraham I
2015-10-08 11:45       ` chunfeng yun
2015-10-08 11:45         ` chunfeng yun
2015-10-08 11:45         ` chunfeng yun
2015-09-29  3:01 ` [PATCH v9 4/5] xhci: mediatek: support MTK xHCI host controller Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
2015-09-29  3:01   ` Chunfeng Yun
     [not found]   ` <1443495698-32233-5-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-10-01 11:44     ` Daniel Thompson
2015-10-01 11:44       ` Daniel Thompson
2015-10-01 11:44       ` Daniel Thompson
2015-10-08 12:05       ` chunfeng yun
2015-10-08 12:05         ` chunfeng yun
2015-10-08 12:05         ` chunfeng yun
2015-10-08 12:28         ` Daniel Thompson
2015-10-08 12:28           ` Daniel Thompson
     [not found]           ` <5616616D.3080205-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-10-08 13:05             ` Mathias Nyman
2015-10-08 13:05               ` Mathias Nyman
2015-10-08 13:05               ` Mathias Nyman
2015-10-08 14:42               ` chunfeng yun
2015-10-08 14:42                 ` chunfeng yun
2015-10-08 14:42                 ` chunfeng yun
2015-10-08 14:38             ` chunfeng yun
2015-10-08 14:38               ` chunfeng yun
2015-10-08 14:38               ` chunfeng yun
2015-10-15 14:46   ` Mathias Nyman
2015-10-15 14:46     ` Mathias Nyman
     [not found]     ` <561FBC40.7020100-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2015-10-18  1:25       ` chunfeng yun
2015-10-18  1:25         ` chunfeng yun
2015-10-18  1:25         ` chunfeng yun
2015-10-19 11:25         ` Mathias Nyman [this message]
2015-10-19 11:25           ` Mathias Nyman
     [not found]           ` <5624D33D.5090807-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2015-10-20  6:29             ` chunfeng yun
2015-10-20  6:29               ` chunfeng yun
2015-10-20  6:29               ` chunfeng yun
2015-10-20  8:25               ` Mathias Nyman
2015-10-20  8:25                 ` Mathias Nyman
     [not found] ` <1443495698-32233-1-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-09-29  3:01   ` [PATCH v9 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs Chunfeng Yun
2015-09-29  3:01     ` Chunfeng Yun
2015-09-29  3:01     ` Chunfeng Yun
     [not found]     ` <1443495698-32233-2-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2015-09-29 14:43       ` Sergei Shtylyov
2015-09-29 14:43         ` Sergei Shtylyov
2015-09-29 14:43         ` Sergei Shtylyov
     [not found]         ` <560AA37E.2090106-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2015-10-08 11:27           ` chunfeng yun
2015-10-08 11:27             ` chunfeng yun
2015-10-08 11:27             ` chunfeng yun
2015-09-29  3:01   ` [PATCH v9 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173 Chunfeng Yun
2015-09-29  3:01     ` Chunfeng Yun
2015-09-29  3:01     ` Chunfeng Yun

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=5624D33D.5090807@intel.com \
    --to=mathias.nyman@intel.com \
    --cc=balbi@ti.com \
    --cc=blogic@openwrt.org \
    --cc=chunfeng.yun@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=djkurtz@chromium.org \
    --cc=galak@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=matthias.bgg@gmail.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rogerq@ti.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sergei.shtylyov@cogentembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.