Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Yisheng, On 4/11/2018 6:52 AM, Yisheng Xie wrote: Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: Hi Vivek, On 2018/3/28 12:37, Vivek Gautam wrote:

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

Hi Tomasz, On 2018/4/10 21:14, Tomasz Figa wrote: > Hi Yisheng, > > Sorry, I think we missed your question here. > > On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: > >> Hi Vivek, > >> On 2018/3/28 12:37, Vivek Gautam wrote: >>> Hi Yisheng >>> >>> >>> On 3/28/2018

Re: [PATCH v3 2/2] drivers: remove force dma flag from buses

On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

On Fri, Mar 30, 2018 at 01:24:44PM +0530, Nipun Gupta wrote: > It is bus specific aspect to map a given device on the bus and > relevant firmware description of its DMA configuration. > So, this change introduces 'dma_configure' as bus callback > giving flexibility to busses for implementing its

Re: [PATCH 03/37] iommu/sva: Manage process address spaces

On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote: > +static void io_mm_detach_all_locked(struct iommu_bond *bond) > +{ > + while (!io_mm_detach_locked(bond)); > +} > + I don't remember if I mentioned this before or not but I think this loop needs a little bit relaxation with yield and maybe

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote: > In the first one, the machine appears to have enough RAM that most of it is > beyond the device's 36-bit DMA mask, thus it's fairly likely for the > initial direct alloc to come back with something unsuitable. But we should try a

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

On 10/04/18 18:07, Takashi Iwai wrote: On Tue, 10 Apr 2018 19:06:15 +0200, Christoph Hellwig wrote: On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote: The code refactoring by commit 0176adb00406 ("swiotlb: refactor coherent buffer allocation") made swiotlb_alloc_buffer() almost

[PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

The code refactoring by commit 0176adb00406 ("swiotlb: refactor coherent buffer allocation") made swiotlb_alloc_buffer() almost always failing due to a thinko: namely, the function evaluates the dma_coherent_ok() call incorrectly and dealing as if it's invalid. This ends up with weird errors like

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

On Tue, 10 Apr 2018 19:06:15 +0200, Christoph Hellwig wrote: > > On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote: > > The code refactoring by commit 0176adb00406 ("swiotlb: refactor > > coherent buffer allocation") made swiotlb_alloc_buffer() almost always > > failing due to a

Re: [PATCH] swiotlb: Fix unexpected swiotlb_alloc_coherent() failures

On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote: > The code refactoring by commit 0176adb00406 ("swiotlb: refactor > coherent buffer allocation") made swiotlb_alloc_buffer() almost always > failing due to a thinko: namely, the function evaluates the > dma_coherent_ok() call

Re: [PATCH v9 5/5] iommu/arm-smmu: Add support for qcom, smmu-v2 variant

Hi Yisheng, Sorry, I think we missed your question here. On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote: > Hi Vivek, > On 2018/3/28 12:37, Vivek Gautam wrote: > > Hi Yisheng > > > > > > On 3/28/2018 6:54 AM, Yisheng Xie wrote: > >> Hi Vivek, > >> > >> On 2018/3/13

Re: [PATCH 2/2] iommu/rockchip: make clock handling optional

On 10/04/18 10:26, Heiko Stuebner wrote: iommu clocks are optional, so the driver should not fail if they are not present. Instead just set the number of clocks to 0, which the clk-blk APIs can handle just fine. Fixes: f2e3a5f557ad ("iommu/rockchip: Control clocks needed to access the IOMMU")

Re: [PATCH 1/2] dt-bindings: iommu/rockchip: Make clock properties optional

On 10/04/18 10:26, Heiko Stuebner wrote: Rockchip IOMMUs are used without explicit clock handling for 4 years now, so we should keep compatibility with old devicetrees if possible. Therefore make iommu clocks optional. Do we need to touch the binding itself? Obviously the driver has to treat

[PATCH 1/2] dt-bindings: iommu/rockchip: Make clock properties optional

Rockchip IOMMUs are used without explicit clock handling for 4 years now, so we should keep compatibility with old devicetrees if possible. Therefore make iommu clocks optional. Fixes: 8fa9eb39c614 ("dt-bindings: iommu/rockchip: Add clock property") Signed-off-by: Heiko Stuebner

[PATCH 0/2] iommu/rockchip: fix clock handling to not break old dts

The newly added clock handling makes iommu clocks required, thus breaking devicetrees from the last 4 years. This series fixes the binding and driver to work without clocks being present, like it did before and should therefore probably go in as fix on top of the clock-handling patch. Heiko

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

Hi Christoph, On Mon, Apr 09, 2018 at 10:52:51AM -0700, Christoph Hellwig wrote: > On Mon, Apr 09, 2018 at 06:59:08PM +0200, Jacopo Mondi wrote: > > I'm still a bit puzzled on what happens if dma_mmap_from_dev_coherent() > > fails. > > Does a dma_mmap_from_dev_coherent() failure guarantee anyhow