Vikas,
On Sun, Apr 27, 2014 at 10:39 AM, Vikas Sajjan wrote:
> Hi shaik,
>
> +Doug, Abhilash,
>
> On Sun, Apr 27, 2014 at 1:08 PM, Shaik Ameer Basha
> wrote:
>> From: Cho KyongHo
>>
>> Signed-off-by: Cho KyongHo
>> ---
>> arch/arm/boot/dts/exynos5250.dtsi | 270
>> +
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 comman
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-
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
> > certainly
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
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 wi
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 Anderson
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
>
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
>
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 a/Documentation
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 SC7180
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 Fa
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
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 Fa
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 chunks while iommu alloca
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
>> > DMA_ATTR_ALLOC_SINGLE_PAGES seems
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 last time. Fortunately t
Will,
On Fri, Apr 8, 2016 at 6:07 AM, Will Deacon 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 wrote:
>> > On Mon, Mar 28, 2016 at 02:32:11PM +0800, Yong Wu wrote:
>> >> @@ -213,13
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, and we'll call split_
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 is small. Let's use proper value for
> calcul
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 compatib
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
> > >
> > >
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
> productio
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 or lazy
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,
> > >
> > >
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
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 paddr
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
> page-by-page
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 SD
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 r
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,
> >
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
>
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 requi
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 controller
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
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 Ande
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 device
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 runnin
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 flushe
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
> device-t
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
> qui
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 of
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 patch
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
> >
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
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 remiai
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.
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
> seconds and the number of ca
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 attribute, please check
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
> ---
> arch/arm64/boot/dts/q
Hi,
On Fri, Aug 10, 2018 at 3:18 PM, Doug Anderson wrote:
> 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
51 matches
Mail list logo
