linux-kernel - RE: [PATCH V11 3/5] i2c: tegra: Add DMA support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BYAPR12MB33987640AE0D0C76ADB42BF1C26F0@BYAPR12MB3398.namprd12.prod.outlook.com>
Date:   Wed, 6 Feb 2019 19:56:34 +0000
From:   Sowjanya Komatineni <skomatineni@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>,
        Thierry Reding <thierry.reding@...il.com>
CC:     Jonathan Hunter <jonathanh@...dia.com>,
        Mantravadi Karthik <mkarthik@...dia.com>,
        Shardar Mohammed <smohammed@...dia.com>,
        Timo Alho <talho@...dia.com>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>
Subject: RE: [PATCH V11 3/5] i2c: tegra: Add DMA support


> >>> Oh, another important moment is that physically contiguous dma_buf 
> >>> allocation isn't guaranteed by the DMA API. This may become a 
> >>> problem for T186+ that can transfer up to 64K. We need to enforce 
> >>> the contiguous-allocation requirement by using
> >>> dma_alloc_attrs(DMA_ATTR_FORCE_CONTIGUOUS) instead of the 
> >>> dma_alloc_coherent(), please see my other comment below.
> >>
> >> Actually I don't think that's necessary here. 
> >> DMA_ATTR_FORCE_CONTIGUOUS only seems relevant if you've got an IOMMU 
> >> attached to the device to make sure the physical memory is also contiguous.
> >>
> >> See this extract from Documentation/DMA-attributes.txt:
> >>
> >> | DMA_ATTR_FORCE_CONTIGUOUS
> >> | -------------------------
> >> | 
> >> | By default DMA-mapping subsystem is allowed to assemble the buffer 
> >> | allocated by dma_alloc_attrs() function from individual pages if it 
> >> | can be mapped as contiguous chunk into device dma address space. By 
> >> | specifying this attribute the allocated buffer is forced to be 
> >> | contiguous also in physical memory.
> >>
> >> We don't have an IOMMU attached to I2C or APBDMA, so this can't 
> >> happen and even if we had an IOMMU attached, all we care about is the 
> >> device's DMA address space, which means IOVA space, and that would 
> >> still be guaranteed to be contiguous, according to the above.
> > 
> > Yes, but doesn't T186+ have IOMMU support for the DMA controller?
> > 
>
> Ah, sorry I probably skimmed way too quickly thorough the message. Hmm.. well, seems I was wrong.
>
> Sowjanya, after all looks like it should be fine to use the default dma_alloc_coherent() helper. Please put it back in v14.

Latest V14 uses dma_alloc_coherent along with below fixes.
- Fixed fifo trig level to do register write with constructed value from scratch as flush is done prior to that and no other bits other than trig level. So writing value direct is simpler
- Fixed to account DVC offset for FIFO register during dma slave config source and destination addresses
- Also in 5th patch in series, updated to use interface timing flag in hw feature as tegra114 and prior doesn’t support interface timing register so allowing programming of timing register only for later tegra chips. Tegra114 and prior uses fixed TLOW and THIGH which are part of hw feature already.

Hopefully all fixes are in. Tested by forcing DMA only and PIO Only and also DMA/PIO back-to-back.

sowjanya