On 22/06/2022 15:32, Christoph Hellwig wrote:
> On Wed, Jun 22, 2022 at 03:29:52PM +0100, Steven Price wrote:
>> The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
>> make the swiotlb_init interface more useful") but the declaration was
>> left in
The variable (and enum) was removed in commit c6af2aa9ffc9 ("swiotlb:
make the swiotlb_init interface more useful") but the declaration was
left in swiotlb.h. Tidy up by removing the declaration as well.
Signed-off-by: Steven Price
---
include/linux/swiotlb.h | 2 --
1 file changed, 2
On 15/06/2022 11:10, Shameer Kolothum wrote:
> Hi
>
> v12 --> v13
> -No changes. Rebased to 5.19-rc1.
> -Picked up tags received from Laurentiu, Hanjun and Will. Thanks!.
You've already got my Tested-by tags, but just to confirm I gave this a
spin and it works fine.
Thanks,
Steve
>
>
On 15/06/2022 11:57, Robin Murphy wrote:
> On 2022-06-15 10:53, Steven Price wrote:
>> On 18/04/2022 01:49, Lu Baolu wrote:
>>> Multiple devices may be placed in the same IOMMU group because they
>>> cannot be isolated from each other. These devices must either be
>&g
On 18/04/2022 01:49, Lu Baolu wrote:
> Multiple devices may be placed in the same IOMMU group because they
> cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture.
>
> This adds dma ownership management in iommu core
please
> give it a try at your end as well.
I'm back in the office and given it a spin, it's all good:
Tested-by: Steven Price
Thanks,
Steve
>
> As mentioned in v10, this now has a dependency on the ACPICA header patch
> here[1].
>
> Please take a look and let me know.
>
On 20/04/2022 17:48, Shameer Kolothum wrote:
> Hi
>
> v9 --> v10
> - Dropped patch #1 ("Add temporary RMR node flag definitions") since
>the ACPICA header updates patch is now in the mailing list[1]
> - Based on the suggestion from Christoph, introduced a
>resv_region_free_fw_data()
RMR).
I'm not sure if that matters but I thought it worth pointing out as it's
not currently spelt out that the RMR descriptor's content is currently
actually ignored.
Anyway, FWIW:
Tested-by: Steven Price
Steve
On 04/04/2022 13:41, Shameer Kolothum wrote:
> Hi
>
> v8 --> v9
>
uno platform with a modified
firmware supporting the newer spec (thanks Sami!). Everything works, so
feel free to add my:
Tested-by: Steven Price
(Note that I haven't tested the smmu-v3 support)
Thanks,
Steve
> Thanks,
> Shameer
> [0] https://developer.arm.com/documentation/den0049/ed/
&g
On 01/10/2021 15:34, Boris Brezillon wrote:
> This lets the driver reduce shareability domain of the MMU mapping,
> which can in turn reduce access time and save power on cache-coherent
> systems.
>
> Signed-off-by: Boris Brezillon
This seems reasonable to me - it matches the kbase
rotection flags (READ/WRITE/...)
> * @type: Type of the reserved region
> + * @rmr: ACPI IORT RMR specific data
NIT: This will provoke a kernel-doc warning as the field name in the
structure is 'fw_data' not 'rmr' ('rmr being a field of the anonymous
union).
I've also retested this
enable/reset SMMU during probe().
>
> Signed-off-by: Jon Nettleton
> Signed-off-by: Steven Price
> Signed-off-by: Shameer Kolothum
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 48 +++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drive
is is to
>> keep any ongoing traffic associated with these devices alive
>> when we enable/reset SMMU during probe().
>>
>> Signed-off-by: Jon Nettleton
>> Signed-off-by: Steven Price
>> Signed-off-by: Shameer Kolothum
>> ---
>> drivers/iommu/arm/ar
on SMMUv2, but not added the
> Tested-by yet because of the above changes.
I've retested with this series (Juno with SMMU in front of display
controller and EFI framebuffer), and it still works, so:
Tested-by: Steven Price
Thanks,
Steve
>
> v3 -->v4
> -Included the SMMU
gt;
> Sanity tested on a HiSilicon D06. Further testing and feedback is greatly
> appreciated.
With the updated SMMUv2 support this works fine on my Juno with EFIFB
(and corresponding patches to the firmware to expose the ACPI tables).
Feel free to add
Tested-by: Steven Price
Thanks,
Ste
On 20/04/2021 09:27, Shameer Kolothum wrote:
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them. This is to
keep any ongoing traffic associated with these devices alive
when we enable/reset SMMU during
On 26/04/2021 17:37, Claire Chang wrote:
On Fri, Apr 23, 2021 at 7:34 PM Steven Price wrote:
[...]
But even then if it's not and we have the situation where debugfs==NULL
then the debugfs_create_dir() here will cause a subsequent attempt in
swiotlb_create_debugfs() to fail (directory already
On 22/04/2021 09:14, Claire Chang wrote:
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Signed-off-by: Claire Chang
---
include/linux/device.h | 4 +++
include/linux/swiotlb.h | 3 +-
kernel/dma/swiotlb.c| 80
On 14/12/2020 12:33, Robin Murphy wrote:
On 2020-12-14 10:55, Shameerali Kolothum Thodi wrote:
Hi Steve,
-Original Message-
From: Steven Price [mailto:steven.pr...@arm.com]
Sent: 10 December 2020 10:26
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux
bin Murphy
LGTM
Reviewed-by: Steven Price
---
Reviewing the Mediatek TLB optimisation patches just left me thinking
"why do we even have this?"... Panfrost folks, this has zero functional
impact to you, merely wants an ack for straying outside drivers/iommu.
Robin.
drivers/gpu
On 06/11/2020 16:17, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Steven Price [mailto:steven.pr...@arm.com]
Sent: 06 November 2020 15:22
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux-foundation.org; de
On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote:
Hi Steve,
-Original Message-
From: Steven Price [mailto:steven.pr...@arm.com]
Sent: 28 October 2020 16:44
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux
On 27/10/2020 11:26, Shameer Kolothum wrote:
The series adds support to IORT RMR nodes specified in IORT
Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
ranges that are used by endpoints and require a unity mapping
in SMMU.
Hi Shameer,
I've also been taking a look at RMR,
shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does
indeed get coherent pagetable walks working nicely for the coherent
T620 in the Arm Juno SoC.
Reviewed-by: Steven Price
Tested-by: Neil
On 05/10/2020 09:39, Boris Brezillon wrote:
On Mon, 5 Oct 2020 09:34:06 +0100
Steven Price wrote:
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According
On 05/10/2020 09:15, Boris Brezillon wrote:
Hi Robin, Neil,
On Wed, 16 Sep 2020 10:26:43 +0200
Neil Armstrong wrote:
Hi Robin,
On 16/09/2020 01:51, Robin Murphy wrote:
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now
On 17/09/2020 11:51, Tomeu Vizoso wrote:
On 9/17/20 12:38 PM, Steven Price wrote:
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach,
even if it's
clearly the cleaner.
That's
On 16/09/2020 18:46, Rob Herring wrote:
On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig
wrote:
So I get a performance regression with the dma-coherent approach, even if it's
clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
Coherency may not be free.
still need to ensure that
the GPU uses the appropriate cacheable outer-shareable attributes in
order to generate the requisite snoop signals, and that CPU mappings
don't create a mismatch by using a non-cacheable type either.
Signed-off-by: Robin Murphy
LGTM
Reviewed-by: Steven Price
---
drive
on dma-mapping wrappers operating
directly on the struct sg_table objects and adjust references to the
nents and orig_nents respectively.
Signed-off-by: Marek Szyprowski
The change looks good to me:
Reviewed-by: Steven Price
Although I would have appreciated the commit message being modified to
ing:
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Even better would be the wrappers you mention in the cover letter! ;)
Reviewed-by: Steven Price
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v2 00/21] DRM: fix struct sg_table nents
vs. orig
On 25/10/2019 19:08, Robin Murphy wrote:
> TTBR1 values have so far been redundant since no users implement any
> support for split address spaces. Crucially, though, one of the main
> reasons for wanting to do so is to be able to manage each half entirely
> independently, e.g. context-switching
noop signals for outer shareable accesses. As such,
> setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable
> walks working nicely.
>
> Making data accesses coherent seems to be more of a challenge...
>
> Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
Note the t
> Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
Steve
> ---
> drivers/iommu/io-pgtable-arm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 9e35cd991f06..77f41c9
VMSA format.
>
> Signed-off-by: Robin Murphy
The Midgard MMU "uses concepts" from LPAE but really isn't LPAE, so this
seems like a good tidy up.
Reviewed-by: Steven Price
Steve
> ---
> drivers/iommu/io-pgtable-arm.c | 53 +-
> 1 file cha
On 15/04/2019 10:18, Daniel Vetter wrote:
> On Fri, Apr 05, 2019 at 05:42:33PM +0100, Steven Price wrote:
>> On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>>> acronym once ever and have it as a "??"), I'm not sure how to respond to
>>> that... We don't kn
On 09/04/2019 17:15, Rob Herring wrote:
> On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso
> wrote:
>>
>> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>>>
>>> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>>>
>>>> On 01/04/2019
On 08/04/2019 22:04, Rob Herring wrote:
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>
>> On 01/04/2019 08:47, Rob Herring wrote:
>>> This adds the initial driver for panfrost which supports Arm Mali
>>> Midgard and Bifrost family of GPUs. Currently, o
On 05/04/2019 11:36, Steven Price wrote:
> On 05/04/2019 10:51, Robin Murphy wrote:
>> Hi Steve,
>>
>> On 05/04/2019 10:42, Steven Price wrote:
>>> First let me say congratulations to everyone working on Panfrost - it's
>>> an impressive achievement!
On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
>> I'm also somewhat surprised that you don't need loads of other
>> properties from the GPU - in particular knowing the number of shader
>> cores is useful for allocating the right amount of memory for TLS (and
>> can't be obtained purely from the
On 05/04/2019 10:51, Robin Murphy wrote:
> Hi Steve,
>
> On 05/04/2019 10:42, Steven Price wrote:
>> First let me say congratulations to everyone working on Panfrost - it's
>> an impressive achievement!
>>
>> Full disclosure: I used to work on the Mali kbase
difference between this and JS_CONFIG_START_MMU.
-8<--
>From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Thu, 4 Apr 2019 15:53:17 +0100
Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE
Midgard/Bifrost GPUs re
42 matches
Mail list logo
