linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: chunfeng.yun@mediatek.com (chunfeng yun)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 4/5] xhci: mediatek: support MTK xHCI host controller
Date: Wed, 19 Aug 2015 19:21:13 +0800	[thread overview]
Message-ID: <1439983273.11157.1.camel@mhfsdcap03> (raw)
In-Reply-To: <55D1F8B7.9060306@linux.intel.com>

Hi
On Mon, 2015-08-17 at 18:07 +0300, Mathias Nyman wrote:
> Hi
> 
> On 07.08.2015 15:30, Chunfeng Yun wrote:
> > MTK xhci host controller defines some extra SW scheduling
> > parameters for HW to minimize the scheduling effort for
> > synchronous and interrupt endpoints. The parameters are
> > put into reseved DWs of slot context and endpoint context
> >
> >
> 
> ...
> 
> > + * The TD size is the number of max packet sized packets remaining in the TD
> > + * (including this TRB), right shifted by 10.
> > + * It must fit in bits 21:17, so it can't be bigger than 31.
> > + */
> > +u32 xhci_mtk_td_remainder_quirk(unsigned int td_running_total,
> > +	unsigned trb_buffer_length, struct urb *urb)
> > +{
> > +	u32 max = 31;
> > +	int remainder, td_packet_count, packet_transferred;
> > +	unsigned int td_transfer_size = urb->transfer_buffer_length;
> > +	unsigned int maxp;
> > +
> > +	maxp = GET_MAX_PACKET(usb_endpoint_maxp(&urb->ep->desc));
> > +
> > +	/* 0 for the last TRB */
> > +	if (td_running_total + trb_buffer_length == td_transfer_size)
> > +		return 0;
> > +
> > +	packet_transferred = td_running_total / maxp;
> > +	td_packet_count = DIV_ROUND_UP(td_transfer_size, maxp);
> > +	remainder = td_packet_count - packet_transferred;
> > +
> > +	if (remainder > max)
> > +		return max << 17;
> > +	else
> > +		return remainder << 17;
> > +}
> 
> I started looking at this xhci_mtk_td_remainder() function, one
> of the places this patch touches the existing xhci code.
> 
> The remainder functions in xhci are already bit too messy, and
> adding one more function which does almost the same thing makes
> it even messier.
> 
> For example queuing a bulk transfer will end up like this:
> 
> >   		/* Set the TRB length, TD size, and interrupter fields. */
> >   		if (xhci->hci_version < 0x100) {
> > -			remainder = xhci_td_remainder(
> > +			if (xhci->quirks & XHCI_MTK_HOST) {
> > +				remainder = xhci_mtk_td_remainder_quirk(
> > +					running_total, trb_buff_len, urb);
> > +			} else {
> > +				remainder = xhci_td_remainder(
> >   					urb->transfer_buffer_length -
> >   					running_total);
> > +			}
> >   		} else {
> >   			remainder = xhci_v1_0_td_remainder(running_total,
> >   					trb_buff_len, total_packet_count, urb,
> 
> and similar for isoc and control transfers.
> 
> I'll see if I can simplify the existing remainder calculations into one function, then it should
> be enough to just add something like this into it:
> 
> if (xhci->quirks & XHCI_MTK_HOST)
> 	trb_buff_len = 0;
>   	
> This way we can skip all the extra hassle that comes with a new exported quirk function
> 
> Is the Mediatek xhci really a xHCI 0.96 or older controller? (hci_version < 0x100)
> Not a xHCI 1.0 or 1.1 ?
> 
It is xHCI 0.96, but add some feature of xHCI 1.0

Thanks a lot

> -Mathias

  reply	other threads:[~2015-08-19 11:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 12:30 Mediatek xHCI support Chunfeng Yun
2015-08-07 12:30 ` [PATCH v5 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs Chunfeng Yun
2015-08-07 12:30 ` [PATCH v5 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller Chunfeng Yun
2015-08-07 12:30 ` [PATCH v5 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs Chunfeng Yun
2015-08-17  5:29   ` Kishon Vijay Abraham I
2015-08-19 11:29     ` chunfeng yun
2015-08-07 12:30 ` [PATCH v5 4/5] xhci: mediatek: support MTK xHCI host controller Chunfeng Yun
2015-08-17 15:07   ` Mathias Nyman
2015-08-19 11:21     ` chunfeng yun [this message]
2015-08-07 12:30 ` [PATCH v5 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173 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=1439983273.11157.1.camel@mhfsdcap03 \
    --to=chunfeng.yun@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).