From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jayshri Dajiram Pawar <jpawar@cadence.com>
Cc: Roger Quadros <rogerq@ti.com>, Peter Chen <peter.chen@nxp.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"felipe.balbi@linux.intel.com" <felipe.balbi@linux.intel.com>,
"heikki.krogerus@linux.intel.com"
<heikki.krogerus@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jbergsagel@ti.com" <jbergsagel@ti.com>,
"nsekhar@ti.com" <nsekhar@ti.com>, "nm@ti.com" <nm@ti.com>,
Rahul Kumar <kurahul@cadence.com>,
Pawel Laszczak <pawell@cadence.com>,
Sanket Parmar <sparmar@cadence.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [RFC PATCH] usb: gadget: f_tcm: Added DMA32 flag while allocation of command buffer
Date: Mon, 25 Nov 2019 11:31:11 -0500 [thread overview]
Message-ID: <20191125163111.GB21800@char.us.oracle.com> (raw)
In-Reply-To: <MN2PR07MB6288E654268FBEB6DFC36F6FC1490@MN2PR07MB6288.namprd07.prod.outlook.com>
. massive snip..
> > > Why is swiotlb buffer getting full? How much is it on your system?
>
> On our system swiotlb max mapping size is 256KB.
> UASP receive data state tries to queue and map buffer of length 524288 (512KB), which is greater than 256KB that's why swiotlb buffer is getting full.
What is the reason for the UASP not being able to break the buffer in say two
256KB sg entries?
>
> > > Are you sure that dma_unmap is happening on requests that complete?
> > else we'll just keep hogging the swiotlb buffer.
>
> Yes, dma_unmap is happening on requests that complete.
>
> I could map buffer of length 512KB with IO_TLB_SEGSIZE changed to 256.
> With this max mapping size is increased to 256*2048 = 512KB.
If we go this route (which I rather dislike as this is a workaround, because
what if the next time there is 1MB buffer? Do we keep on increasing this?) - then
this should be dynamic and an option on the 'swiotlb' command line.
prev parent reply other threads:[~2019-11-25 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-13 10:24 [RFC PATCH] usb: gadget: f_tcm: Added DMA32 flag while allocation of command buffer Jayshri Pawar
2019-11-14 2:50 ` Peter Chen
2019-11-14 9:48 ` Roger Quadros
2019-11-15 10:14 ` Jayshri Dajiram Pawar
2019-11-15 11:11 ` Roger Quadros
2019-11-15 18:02 ` Konrad Rzeszutek Wilk
2019-11-22 11:55 ` Jayshri Dajiram Pawar
2019-11-25 16:31 ` Konrad Rzeszutek Wilk [this message]
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=20191125163111.GB21800@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jbergsagel@ti.com \
--cc=jpawar@cadence.com \
--cc=kurahul@cadence.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nm@ti.com \
--cc=nsekhar@ti.com \
--cc=pawell@cadence.com \
--cc=peter.chen@nxp.com \
--cc=rogerq@ti.com \
--cc=sparmar@cadence.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