Re: [PATCH v2 00/24] iommu: Refactor DMA domain strictness

Hi, On Thu, Jul 29, 2021 at 3:33 PM Doug Anderson wrote: > > I was definitely getting some inconsistencies in my tests where the > eMMC speeds were getting into a bad state, but I don't believe it's > related to your patch series. I think this was just me being an idiot. I forgot t

Re: [PATCH v2 00/24] iommu: Refactor DMA domain strictness

Hi, On Wed, Jul 28, 2021 at 8:59 AM Robin Murphy wrote: > > Hi all, > > Here's v2 where things start to look more realistic, hence the expanded > CC list. The patches are now based on the current iommu/core branch to > take John's iommu_set_dma_strict() cleanup into account. > > The series

Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC

Hi, On Tue, Jul 13, 2021 at 11:07 AM Robin Murphy wrote: > > On 2021-07-08 15:36, Doug Anderson wrote: > [...] > >> Or document for the users that want performance how to > >> change the setting, so that they can decide. > > > > Pushing this to the users

Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC

Hi, On Thu, Jul 8, 2021 at 1:09 AM Joerg Roedel wrote: > > On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote: > > a) Nothing is inherently broken with my current approach. > > > > b) My current approach doesn't make anybody terribly upset even if >

Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC

Hi, On Fri, Jun 25, 2021 at 7:42 AM Doug Anderson wrote: > > Hi, > > On Fri, Jun 25, 2021 at 6:19 AM Joerg Roedel wrote: > > > > Hi Douglas, > > > > On Thu, Jun 24, 2021 at 10:17:56AM -0700, Douglas Anderson wrote: > > > The goal of this pat

Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC

Hi, On Fri, Jun 25, 2021 at 6:19 AM Joerg Roedel wrote: > > Hi Douglas, > > On Thu, Jun 24, 2021 at 10:17:56AM -0700, Douglas Anderson wrote: > > The goal of this patch series is to get better SD/MMC performance on > > Qualcomm eMMC controllers and in generally nudge us forward on the > > path

Re: [PATCH v2 3/3] mmc: sdhci-msm: Request non-strict IOMMU mode

Hi, On Thu, Jun 24, 2021 at 10:18 AM Douglas Anderson wrote: > > The concept of IOMMUs being in strict vs. non-strict mode is a > pre-existing Linux concept. I've included a rough summary here to help > evaluate this patch. > > IOMMUs can be run in "strict" mode or in "non-strict" mode. The >

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

Hi, On Wed, Jun 23, 2021 at 10:29 AM Doug Anderson wrote: > > * Instead of putting the details in per-device nodes, maybe it makes > sense to accept that we should be specifying these things at the IOMMU > level? If specifying things at the device tree level then the > d

Re: [PATCH 6/6] mmc: sdhci-msm: Request non-strict IOMMU mode

Hi, On Thu, Jun 24, 2021 at 6:43 AM Greg KH wrote: > > On Mon, Jun 21, 2021 at 04:52:48PM -0700, Douglas Anderson wrote: > > IOMMUs can be run in "strict" mode or in "non-strict" mode. The > > quick-summary difference between the two is that in "strict" mode we > > wait until everything is

Re: [PATCH 3/6] PCI: Indicate that we want to force strict DMA for untrusted devices

Hi, On Thu, Jun 24, 2021 at 6:38 AM Greg KH wrote: > > On Mon, Jun 21, 2021 at 04:52:45PM -0700, Douglas Anderson wrote: > > At the moment the generic IOMMU framework reaches into the PCIe device > > to check the "untrusted" state and uses this information to figure out > > if it should be

Re: [PATCH 2/6] drivers: base: Add bits to struct device to control iommu strictness

Hi, On Thu, Jun 24, 2021 at 6:37 AM Greg KH wrote: > > On Mon, Jun 21, 2021 at 04:52:44PM -0700, Douglas Anderson wrote: > > How to control the "strictness" of an IOMMU is a bit of a mess right > > now. As far as I can tell, right now: > > * You can set the default to "non-strict" and some

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

Hi, On Tue, Jun 22, 2021 at 3:10 PM Robin Murphy wrote: > > On 2021-06-22 17:06, Doug Anderson wrote: > > Hi, > > > > On Tue, Jun 22, 2021 at 4:35 AM Robin Murphy wrote: > >> > >> Hi Doug, > >> > >> On 2021-06-22 00:52, Douglas An

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

Hi, On Tue, Jun 22, 2021 at 1:06 PM Saravana Kannan wrote: > > On Tue, Jun 22, 2021 at 1:02 PM Rob Herring wrote: > > > > On Tue, Jun 22, 2021 at 09:06:02AM -0700, Doug Anderson wrote: > > > Hi, > > > > > > On Tue, Jun 22, 2021 at 4:35 AM

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

Hi, On Tue, Jun 22, 2021 at 10:46 AM John Garry wrote: > > On 22/06/2021 00:52, Douglas Anderson wrote: > > > > This patch attempts to put forward a proposal for enabling non-strict > > DMA on a device-by-device basis. The patch series requests non-strict > > DMA for the Qualcomm SDHCI

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

Hi, On Tue, Jun 22, 2021 at 11:45 AM Rajat Jain wrote: > > On Mon, Jun 21, 2021 at 4:53 PM Douglas Anderson > wrote: > > > > In the patch ("drivers: base: Add bits to struct device to control > > iommu strictness") we add the ability for devices to tell us about > > their IOMMU strictness

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

Hi, On Tue, Jun 22, 2021 at 9:53 AM Doug Anderson wrote: > > Hi, > > On Mon, Jun 21, 2021 at 7:05 PM Lu Baolu wrote: > > > > On 6/22/21 7:52 AM, Douglas Anderson wrote: > > > @@ -1519,7 +1542,8 @@ static int iommu_get_def_domain_type(struct device >

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

Hi, On Mon, Jun 21, 2021 at 7:05 PM Lu Baolu wrote: > > On 6/22/21 7:52 AM, Douglas Anderson wrote: > > @@ -1519,7 +1542,8 @@ static int iommu_get_def_domain_type(struct device > > *dev) > > > > static int iommu_group_alloc_default_domain(struct bus_type *bus, > >

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

Hi, On Mon, Jun 21, 2021 at 7:56 PM Saravana Kannan wrote: > > On Mon, Jun 21, 2021 at 4:53 PM Douglas Anderson > wrote: > > > > In the patch ("drivers: base: Add bits to struct device to control > > iommu strictness") we add the ability for devices to tell us about > > their IOMMU strictness

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

Hi, On Tue, Jun 22, 2021 at 4:35 AM Robin Murphy wrote: > > Hi Doug, > > On 2021-06-22 00:52, Douglas Anderson wrote: > > > > This patch attempts to put forward a proposal for enabling non-strict > > DMA on a device-by-device basis. The patch series requests non-strict > > DMA for the Qualcomm

Re: [PATCHv2 2/3] iommu/io-pgtable: Optimize partial walk flush for large scatter-gather list

Hi, On Thu, Jun 17, 2021 at 7:51 PM Sai Prakash Ranjan wrote: > > Currently for iommu_unmap() of large scatter-gather list with page size > elements, the majority of time is spent in flushing of partial walks in > __arm_lpae_unmap() which is a VA based TLB invalidation invalidating >

Re: [PATCH v4 1/7] iommu: Move iotlb_sync_map out from __iommu_map

Hi, On Thu, Jan 7, 2021 at 4:31 AM Yong Wu wrote: > > @@ -2438,18 +2435,31 @@ static int __iommu_map(struct iommu_domain *domain, > unsigned long iova, > return ret; > } > > +static int _iommu_map(struct iommu_domain *domain, unsigned long iova, > + phys_addr_t

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

Hi, On Wed, Aug 26, 2020 at 8:01 AM Sai Prakash Ranjan wrote: > > On 2020-08-26 19:21, Robin Murphy wrote: > > On 2020-08-26 13:17, Sai Prakash Ranjan wrote: > >> On 2020-08-26 17:07, Robin Murphy wrote: > >>> On 2020-08-25 16:42, Sai Prakash Ranjan wrote: > Currently the non-strict or lazy

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

Hi, On Tue, Aug 25, 2020 at 3:54 PM Rob Clark wrote: > > On Tue, Aug 25, 2020 at 3:23 PM Doug Anderson wrote: > > > > Hi, > > > > On Tue, Aug 25, 2020 at 12:01 PM Sai Prakash Ranjan > > wrote: > > > > > > Hi, > >

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

Hi, On Tue, Aug 25, 2020 at 12:01 PM Sai Prakash Ranjan wrote: > > Hi, > > On 2020-08-25 21:40, Doug Anderson wrote: > > Hi, > > > > On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan > > wrote: > >> > >> Currently the non-strict

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

Hi, On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan wrote: > > Currently the non-strict or lazy mode of TLB invalidation can only be set > for all or no domains. This works well for development platforms where > setting to non-strict/lazy mode is fine for performance reasons but on >

Re: [PATCH 10/20] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU

Hi, On Wed, Aug 19, 2020 at 10:36 AM Rob Clark wrote: > > On Wed, Aug 19, 2020 at 10:03 AM Doug Anderson wrote: > > > > Hi, > > > > On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote: > > > > > > From: Jordan Crouse > > > > &g

Re: [PATCH 10/20] dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU

Hi, On Mon, Aug 17, 2020 at 3:03 PM Rob Clark wrote: > > From: Jordan Crouse > > Every Qcom Adreno GPU has an embedded SMMU for its own use. These > devices depend on unique features such as split pagetables, > different stall/halt requirements and other settings. Identify them > with a

Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string

Hi, On Mon, May 18, 2020 at 7:39 AM Will Deacon wrote: > > On Fri, May 15, 2020 at 12:05:39PM -0700, Doug Anderson wrote: > > On Fri, May 1, 2020 at 3:30 AM Sharat Masetty > > wrote: > > > > > > This patch simply adds a new compatible string for SC7

Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string

Hi, On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote: > > This patch simply adds a new compatible string for SC7180 platform. > > Signed-off-by: Sharat Masetty > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: [PATCHv2] iommu/arm-smmu: Make remove callback message more informative

Hi, On Thu, Apr 23, 2020 at 7:35 AM Doug Anderson wrote: > > Hi, > > On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan > wrote: > > > > Currently on reboot/shutdown, the following messages are > > displayed on the console as error messages before the &g

Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add A618 gpu dt blob

Hi, On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote: > > This patch adds the required dt nodes and properties > to enabled A618 GPU. > > Signed-off-by: Sharat Masetty > --- > * Remove GCC_DDRSS_GPU_AXI_CLK clock reference from gpu smmu node. > > arch/arm64/boot/dts/qcom/sc7180.dtsi | 102

Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string

Hi, On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote: > > This patch simply adds a new compatible string for SC7180 platform. > > Signed-off-by: Sharat Masetty > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Douglas

Re: [PATCHv2] iommu/arm-smmu: Make remove callback message more informative

Hi, On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan wrote: > > Currently on reboot/shutdown, the following messages are > displayed on the console as error messages before the > system reboots/shutdown as part of remove callback. > > On SC7180: > > arm-smmu 1500.iommu: removing device

Re: [PATCH] iommu/arm-smmu: Demote error messages to debug in shutdown callback

Hi, On Tue, Mar 31, 2020 at 12:53 AM Sai Prakash Ranjan wrote: > > Hi Will, > > On 2020-03-31 13:14, Will Deacon wrote: > > On Tue, Mar 31, 2020 at 01:06:11PM +0530, Sai Prakash Ranjan wrote: > >> On 2020-03-30 23:54, Doug Anderson wrote: > >> > On Sa

Re: [PATCH] iommu/arm-smmu: Demote error messages to debug in shutdown callback

Hi, On Sat, Mar 28, 2020 at 12:35 AM Sai Prakash Ranjan wrote: > > > Of course the fact that in practice we'll *always* see the warning > > because there's no way to tear down the default DMA domains, and even > > if all devices *have* been nicely quiesced there's no way to tell, is > >

Re: [PATCH v2] iommu/arm-smmu: Report USF more clearly

Hi, On Tue, Sep 17, 2019 at 7:45 AM Robin Murphy wrote: > > Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool > for smoking out inadequate firmware, the failure mode is non-obvious > and can be confusing for end users. Add some special-case reporting of > Unidentified Stream

Re: [PATCH] iommu/arm-smmu: Report USF more clearly

Hi, On Mon, Sep 16, 2019 at 11:00 AM Will Deacon wrote: > > On Fri, Sep 13, 2019 at 03:44:12PM -0700, Doug Anderson wrote: > > On Fri, Sep 13, 2019 at 4:48 AM Robin Murphy wrote: > > > > > > Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool &g

Re: [PATCH] iommu/arm-smmu: Report USF more clearly

Hi, On Fri, Sep 13, 2019 at 4:48 AM Robin Murphy wrote: > > Although CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT is a welcome tool > for smoking out inadequate firmware, the failure mode is non-obvious > and can be confusing for end users. Add some special-case reporting of > Unidentified Stream

Re: [PATCH] iommu/arm-smmu: Allow disabling bypass via kernel config

Hi, On Fri, Feb 15, 2019 at 2:37 PM Rob Clark wrote: > > On Thu, Feb 14, 2019 at 7:40 PM Doug Anderson wrote: > > > > Hi, > > > > On Thu, Feb 14, 2019 at 1:32 PM Robin Murphy wrote: > > > > > > Hi Doug, > > > > > > On 2019-02-

Re: [PATCH] iommu/arm-smmu: Allow disabling bypass via kernel config

Hi, On Thu, Feb 14, 2019 at 1:32 PM Robin Murphy wrote: > > Hi Doug, > > On 2019-02-14 8:44 pm, Douglas Anderson wrote: > > Right now the only way to disable the iommu bypass for the ARM SMMU is > > with the kernel command line parameter 'arm-smmu.disable_bypass'. > > > > In general kernel

Re: [PATCH 1/3] dts: arm64/sdm845: Add node for arm,mmu-500

Hi, On Thu, Jul 19, 2018 at 10:53 AM, Vivek Gautam wrote: > Add device node for arm,mmu-500 available on sdm845. > This MMU-500 with single TCU and multiple TBU architecture > is shared among all the peripherals except gpu on sdm845. > > Signed-off-by: Vivek Gautam > --- >

Re: [PATCH v4 3/8] iommu/rockchip: Fix allocation of bases array in driver probe

Hi, On Mon, Jun 20, 2016 at 9:34 PM, Tomasz Figa wrote: > From: Shunqian Zheng > > In .probe(), devm_kzalloc() is called with size == 0 and works only > by luck, due to internal behavior of the allocator and the fact > that the proper allocation size

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Hi, On Fri, Apr 8, 2016 at 10:30 AM, Will Deacon wrote: >> > Am I barking up the wrong tree? >> >> I don't think min_order can be negative. Certainly we could enter the >> loop with order == 0 and min_order == 0, though. > > ... and in that case, PageCompound will be false,

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Will, On Fri, Apr 8, 2016 at 6:07 AM, Will Deacon <will.dea...@arm.com> wrote: > On Tue, Apr 05, 2016 at 10:03:32AM -0700, Doug Anderson wrote: >> On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon <will.dea...@arm.com> wrote: >> > On Mon, Mar 28, 2016 at 0

Re: [PATCH v2 1/2] dma/iommu: Add pgsize_bitmap confirmation in __iommu_dma_alloc_pages

Will, On Tue, Mar 29, 2016 at 10:02 AM, Will Deacon wrote: > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote: >> Currently __iommu_dma_alloc_pages assumes that all the IOMMU support >> the granule of PAGE_SIZE. It call alloc_page to try allocating memory >> in the

Re: [PATCH] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support

Hi, On Thu, Mar 24, 2016 at 4:50 AM, Will Deacon wrote: >> > I have a slight snag with this, in that you don't consult the IOMMU >> > pgsize_bitmap at any point, and assume that it can map pages at the >> > same granularity as the CPU. The documentation for >> >

Re: [PATCH] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support

Will, On Mon, Mar 21, 2016 at 11:01 AM, Will Deacon wrote: > On Thu, Mar 03, 2016 at 02:54:26AM +0800, Yong Wu wrote: >> Sometimes it is not worth for the iommu allocating big chunks. >> Here we enable DMA_ATTR_ALLOC_SINGLE_PAGES which could help avoid to >> allocate big

Re: [PATCH] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support

Hi, On Wed, Mar 2, 2016 at 10:54 AM, Yong Wu wrote: > Sometimes it is not worth for the iommu allocating big chunks. > Here we enable DMA_ATTR_ALLOC_SINGLE_PAGES which could help avoid to > allocate big chunks while iommu allocating buffer. > > More information about this

Re: [PATCH 3/3] iommu/dma: Avoid unlikely high-order allocations

Robin, On Fri, Dec 18, 2015 at 9:01 AM, Robin Murphy wrote: > Doug reports that the equivalent page allocator on 32-bit ARM exhibits > particularly pathalogical behaviour under memory pressure when > fragmentation is high, where allocating a 4MB buffer takes tens of >

Re: [PATCH v12 30/31] ARM: dts: add System MMU nodes of exynos5250

Vikas, On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan sajjan.li...@gmail.com wrote: Hi shaik, +Doug, Abhilash, On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha shaik.am...@samsung.com wrote: From: Cho KyongHo pullip@samsung.com Signed-off-by: Cho KyongHo pullip@samsung.com