Hi Vineet, > -----Original Message----- > From: Vineet Gupta [mailto:vgupta@xxxxxxxxxxxx] > Sent: Thursday, November 03, 2016 8:04 PM > To: Alexey Brodkin <Alexey.Brodkin@xxxxxxxxxxxx>; linux-snps-arc@xxxxxxxxxxxxxxxxxxx > Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-arch@xxxxxxxxxxxxxxx; Vineet Gupta <Vineet.Gupta1@xxxxxxxxxxxx>; Marek Szyprowski > <m.szyprowski@xxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2] arc: Implement arch-specific dma_map_ops.mmap > > On 11/03/2016 08:06 AM, Alexey Brodkin wrote: > > We used to use generic implementation of dma_map_ops.mmap which is > > dma_common_mmap() but that only worked for simpler cached mappings when > > vaddr = paddr. > > > > If a driver requests uncached DMA buffer kernel maps it to virtual > > address so that MMU gets involved and page uncached status takes into > > account. In that case usage of dma_common_mmap() lead to mapping of > > vaddr to vaddr for user-space which is obviously wrong. For more detals > > please refer to verbose explanation here [1]. > > > > So here we implement our own version of mmap() which always deals > > with dma_addr and maps underlying memory to user-space properly > > (note that DMA buffer mapped to user-space is always uncached > > because there's no way to properly manage cache from user-space). > > > > [1] https://lkml.org/lkml/2016/10/26/973 > > > > Signed-off-by: Alexey Brodkin <abrodkin@xxxxxxxxxxxx> > > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx> > > Cc: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > > Cc: Vineet Gupta <vgupta@xxxxxxxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > I've added a stable 4.5+, since ARC didn't use dma ops until 4.5-rc1. Again I was hitting a strange problem when sending patch via "git send-email" to address "<stable@xxxxxxxxxxxxxxx> # 3.3.x". Mail server complains on wrong email. Thus I settled to just mention stable@xxxxxxxxxxxxxxx. Anyways, thanks for doing that! -Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
