From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
Sinclair Yeh <syeh@vmware.com>,
linux-rdma@vger.kernel.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Jian Xu Zheng <jian.xu.zheng@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Bingbu Cao <bingbu.cao@intel.com>, Yong Zhi <yong.zhi@intel.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Christoph Hellwig <hch@lst.de>,
Tian Shu Qiu <tian.shu.qiu@intel.com>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Date: Mon, 14 Jan 2019 10:48:56 +0100 [thread overview]
Message-ID: <20190114094856.GB29604@lst.de> (raw)
In-Reply-To: <20190110234218.GM6890@ziepe.ca>
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > Changes since the RFC:
> > - Rework vmwgfx too [CH]
> > - Use a distinct type for the DMA page iterator [CH]
> > - Do not have a #ifdef [CH]
>
> ChristophH: Will you ack?
This looks generally fine.
>
> Are you still OK with the vmwgfx reworking, or should we go back to
> the original version that didn't have the type safety so this driver
> can be left broken?
I think the map method in vmgfx that just does virt_to_phys is
pretty broken. Thomas, can you check if you see any performance
difference with just doing the proper dma mapping, as that gets the
driver out of interface abuse land?
While we're at it I think we need to merge my series in this area
for 5.0, because without that the driver is already broken. Where
should we merge it?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@lst.de>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Imre Deak <imre.deak@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
linux-media@vger.kernel.org, Yong Zhi <yong.zhi@intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Bingbu Cao <bingbu.cao@intel.com>,
Tian Shu Qiu <tian.shu.qiu@intel.com>,
Jian Xu Zheng <jian.xu.zheng@intel.com>,
Sinclair Yeh <syeh@vmware.com>,
Thomas Hellstrom <thellstrom@vmware.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
Date: Mon, 14 Jan 2019 10:48:56 +0100 [thread overview]
Message-ID: <20190114094856.GB29604@lst.de> (raw)
In-Reply-To: <20190110234218.GM6890@ziepe.ca>
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > Changes since the RFC:
> > - Rework vmwgfx too [CH]
> > - Use a distinct type for the DMA page iterator [CH]
> > - Do not have a #ifdef [CH]
>
> ChristophH: Will you ack?
This looks generally fine.
>
> Are you still OK with the vmwgfx reworking, or should we go back to
> the original version that didn't have the type safety so this driver
> can be left broken?
I think the map method in vmgfx that just does virt_to_phys is
pretty broken. Thomas, can you check if you see any performance
difference with just doing the proper dma mapping, as that gets the
driver out of interface abuse land?
While we're at it I think we need to merge my series in this area
for 5.0, because without that the driver is already broken. Where
should we merge it?
next prev parent reply other threads:[~2019-01-14 9:48 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-04 22:35 [PATCH] lib/scatterlist: Provide a DMA page iterator Jason Gunthorpe
2019-01-05 2:37 ` kbuild test robot
2019-01-05 2:37 ` kbuild test robot
2019-01-05 3:21 ` Jason Gunthorpe
2019-01-10 23:42 ` Jason Gunthorpe
2019-01-14 9:48 ` Christoph Hellwig [this message]
2019-01-14 9:48 ` Christoph Hellwig
2019-01-15 14:17 ` Thomas Hellstrom
2019-01-15 14:17 ` Thomas Hellstrom
2019-01-15 14:24 ` Christian König
2019-01-15 14:24 ` Christian König
2019-01-15 15:20 ` hch
2019-01-15 18:03 ` Thomas Hellstrom
2019-01-15 18:03 ` Thomas Hellstrom
2019-01-15 18:31 ` hch
2019-01-15 18:31 ` hch
2019-01-15 19:13 ` Koenig, Christian
2019-01-15 19:13 ` Koenig, Christian
2019-01-15 20:58 ` hch
2019-01-16 7:09 ` Thomas Hellstrom
2019-01-16 7:09 ` Thomas Hellstrom
2019-01-16 7:28 ` Koenig, Christian
2019-01-16 7:28 ` Koenig, Christian
2019-01-16 10:14 ` Daniel Vetter
2019-01-16 10:14 ` Daniel Vetter
2019-01-16 16:06 ` hch
2019-01-16 16:36 ` Daniel Stone
2019-01-16 16:36 ` Daniel Stone
2019-01-15 21:25 ` Jason Gunthorpe
2019-01-16 10:40 ` Christian König
2019-01-16 10:40 ` Christian König
2019-01-16 16:11 ` hch
2019-01-16 16:11 ` hch
2019-01-16 17:24 ` Jason Gunthorpe
2019-01-17 9:30 ` hch
2019-01-17 10:47 ` Thomas Hellstrom
2019-01-17 10:47 ` Thomas Hellstrom
2019-01-17 15:54 ` Jason Gunthorpe
2019-01-12 18:27 ` Shiraz Saleem
2019-01-12 18:27 ` Shiraz Saleem
2019-01-12 18:37 ` Jason Gunthorpe
2019-01-12 19:03 ` Shiraz Saleem
2019-01-12 19:03 ` Shiraz Saleem
2019-01-14 9:46 ` Christoph Hellwig
2019-01-14 22:16 ` Jason Gunthorpe
2019-01-16 17:32 ` Shiraz Saleem
2019-02-07 23:23 ` Sakari Ailus
2019-02-07 23:23 ` Sakari Ailus
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=20190114094856.GB29604@lst.de \
--to=hch@lst.de \
--cc=bingbu.cao@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jgg@ziepe.ca \
--cc=jian.xu.zheng@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=shiraz.saleem@intel.com \
--cc=syeh@vmware.com \
--cc=thellstrom@vmware.com \
--cc=tian.shu.qiu@intel.com \
--cc=yong.zhi@intel.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.