Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC layer.
As a bonus I've converted various drivers to the proper scatterlist
helpers so that at least in theory they are ready for chained
scatterlists.
All the changes are compile tested only as I don't have any of the
hardware, so a careful review would be appreciated.
Changes since v1:
- fix a missing kunmap_atomic in mvsdio
- fix a stray whitespace in s3cmci
- add new sg_kmap_atomic and sg_kunmap_atomic helpers
- set the DMA and block layer dma boundary
- use pointer arithmetics to reduce the amount of changes in
various drivers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

* Christoph Hellwig <hch@lst.de> [190212 07:27]:
> Instead of setting up a kernel pointer to track the current PIO address,
> track the offset in the current page, and do an atomic kmap for the page
> while doing the actual PIO operations.
I'm currently having issues booting my test devices (770 and n8x0)
with this MMC controller so I can't test these patches currently.
Aaro, can you please test when you have a chance?
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Tue, 12 Feb 2019 at 08:25, Christoph Hellwig <hch@lst.de> wrote:
>
> Hi everyone,
>
> this series converts the remaining MMC host drivers to properly kmap the
> scatterlist entries it does PIO operations on, and then goes on to
> remove the usage of block layer bounce buffering (which I plan to remove
> eventually) from the MMC layer.
>
> As a bonus I've converted various drivers to the proper scatterlist
> helpers so that at least in theory they are ready for chained
> scatterlists.
>
> All the changes are compile tested only as I don't have any of the
> hardware, so a careful review would be appreciated.
>
> Changes since v1:
> - fix a missing kunmap_atomic in mvsdio
> - fix a stray whitespace in s3cmci
> - add new sg_kmap_atomic and sg_kunmap_atomic helpers
> - set the DMA and block layer dma boundary
> - use pointer arithmetics to reduce the amount of changes in
> various drivers
>
This looks good to me, however the lack of feedback/tests worries me a
bit. So, unless you think it's a bad idea, I intend to apply this when
v5.1 rc1 is out, which allows a lengthy test period in linux-next.
Make sense?
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Mon, Feb 25, 2019 at 02:54:13PM +0100, Ulf Hansson wrote:
> This looks good to me, however the lack of feedback/tests worries me a
> bit. So, unless you think it's a bad idea, I intend to apply this when
> v5.1 rc1 is out, which allows a lengthy test period in linux-next.
Please don't rush to merge this. Based on a talk to some folks I
have an idea for a sg iterator that can hide the kmapping from
the drivers, which should allow for some less scary driver code and
clean this up a bit further.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

On Fri, 8 Mar 2019 at 10:18, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Feb 25, 2019 at 02:54:13PM +0100, Ulf Hansson wrote:
> > This looks good to me, however the lack of feedback/tests worries me a
> > bit. So, unless you think it's a bad idea, I intend to apply this when
> > v5.1 rc1 is out, which allows a lengthy test period in linux-next.
>
> Please don't rush to merge this. Based on a talk to some folks I
> have an idea for a sg iterator that can hide the kmapping from
> the drivers, which should allow for some less scary driver code and
> clean this up a bit further.
Okay, I see. Thanks for letting me know!
Kind regards
Uffe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel