On Mon, Apr 11, 2022 at 12:25:36PM +0530, Rohit Agarwal wrote:
> Hello,
>
> This series adds devicetree nodes for SDX65. It adds
> reserved memory nodes, SDHCI, smmu and tcsr mutex support.
>
Please CC me to all SDX65 related patches as I'd like to review them.
Thanks,
Mani
> Thanks,
> Rohit.
On Mon, Apr 11, 2022 at 12:25:37PM +0530, Rohit Agarwal wrote:
> Add reserved memory nodes to the SDX65 dtsi as defined by
> the memory map.
>
> Signed-off-by: Rohit Agarwal
> ---
> arch/arm/boot/dts/qcom-sdx65-mtp.dts | 21 +
> arch/arm/boot/dts/qcom-sdx65.dtsi| 45
> ++
On Mon, Apr 11, 2022 at 12:25:39PM +0530, Rohit Agarwal wrote:
> Add devicetree support for SDHCI controller found in Qualcomm SDX65
> platform. The SDHCI controller is based on the MSM SDHCI v5 IP.
>
> Signed-off-by: Rohit Agarwal
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> arch
On Mon, Apr 11, 2022 at 12:25:41PM +0530, Rohit Agarwal wrote:
> Add a node for the ARM SMMU found in the SDX65.
>
> Signed-off-by: Rohit Agarwal
> ---
> arch/arm/boot/dts/qcom-sdx65.dtsi | 40
> +++
> 1 file changed, 40 insertions(+)
>
> diff --git a/arch/a
On Mon, Apr 11, 2022 at 12:25:42PM +0530, Rohit Agarwal wrote:
> Add TCSR Mutex node to support Qualcomm Hardware Mutex block
> on SDX65 platform.
>
> Signed-off-by: Rohit Agarwal
Reviewed-by: Manivannan Sadhasivam
Thanks,
Mani
> ---
> arch/arm/boot/dts/qcom-sdx65.dtsi | 6 ++
> 1 file c
Add a node for the ARM SMMU found in the SDX65.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index 632ac78..24
The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
document the compatible with "qcom,sdhci-msm-v5" as the fallback.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bi
Hello,
This series adds devicetree nodes for SDX65. It adds
reserved memory nodes, SDHCI, smmu and tcsr mutex support.
Thanks,
Rohit.
Rohit Agarwal (7):
ARM: dts: qcom: sdx65: Add reserved memory nodes
dt-bindings: mmc: sdhci-msm: Document the SDX65 compatible
ARM: dts: qcom: sdx65: Add su
Add devicetree binding for Qualcomm SDX65 SMMU.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/iommu/arm,smmu.yam
Add TCSR Mutex node to support Qualcomm Hardware Mutex block
on SDX65 platform.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index 2481769..5c28c
Add smem node to support shared memory manager on SDX65 platform.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index 5c28c94..b0eec91 100644
---
Add reserved memory nodes to the SDX65 dtsi as defined by
the memory map.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65-mtp.dts | 21 +
arch/arm/boot/dts/qcom-sdx65.dtsi| 45
2 files changed, 66 insertions(+)
diff --git a/
Add devicetree support for SDHCI controller found in Qualcomm SDX65
platform. The SDHCI controller is based on the MSM SDHCI v5 IP.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.d
Add smem node to support shared memory manager on SDX65 platform.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index 210e55c..8fef644 100644
---
Hello,
This series adds devicetree nodes for SDX65. It adds reserved memory
nodes, SDHCI, smmu and tcsr mutex support.
Changes from v1:
- Addressed Mani's Comments and made necessary.
- Rebased on top of v5.18-rc2.
Thanks,
Rohit.
Rohit Agarwal (7):
ARM: dts: qcom: sdx65: Add reserved memor
Add devicetree support for SDHCI controller found in Qualcomm SDX65
platform. The SDHCI controller is based on the MSM SDHCI v5 IP.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.d
Add reserved memory nodes to the SDX65 dtsi as defined by
the memory map.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65-mtp.dts | 21 +
arch/arm/boot/dts/qcom-sdx65.dtsi| 45
2 files changed, 66 insertions(+)
diff --git a/
Add TCSR Mutex node to support Qualcomm Hardware Mutex block
on SDX65 platform.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index f50a8a4..210e5
Add a node for the ARM SMMU found in the SDX65.
Signed-off-by: Rohit Agarwal
---
arch/arm/boot/dts/qcom-sdx65.dtsi | 40 +++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-sdx65.dtsi
b/arch/arm/boot/dts/qcom-sdx65.dtsi
index 77bca58..f5
The SDHCI controller on SDX65 is based on MSM SDHCI v5 IP. Hence,
document the compatible with "qcom,sdhci-msm-v5" as the fallback.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bi
Add devicetree binding for Qualcomm SDX65 SMMU.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/iommu/arm,smmu.yam
On 2022-04-10 11:59, Oded Gabbay wrote:
On Tue, Apr 5, 2022 at 4:46 PM Robin Murphy wrote:
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Replace iommu_present() with a more appropriate c
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
v2: Rebase on habanalabs-next
drivers/misc/habanalabs
Refactor the confusing logic to make it both clearer and more robust. If
the host1x parent device does have an IOMMU domain then iommu_present()
is redundantly true, while otherwise for the 32-bit DMA mask case it
still doesn't say whether the IOMMU driver actually knows about the DRM
device or not
Hi, Fenghua
I got an issue when testing nginx with 5.18-rc1/2 on aarch64 system,
After debugging I found it is caused by this patchset.
In the test, when accessing https, crypto driver will be used with sva feature,
and nginx is testing multi-threads.
Test cmd:
sudo sbin/nginx
lynx https://l
On 4/11/22 07:00, Zhangfei Gao wrote:
> with this patchset, each time after sbin/nginx, ioasid is freed
> immediately. lynx test will alloc the same ioasid=1.
That doesn't seem right. Isn't 'sbin/nginx' still running when lynx
runs? How can they get the same ioasid?
This sounds like a refcount
On Fri, Apr 08, 2022 at 08:05:38AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY
> > and
> > IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
> >
> > Curren
On Fri, Apr 08, 2022 at 09:47:57AM -0600, Alex Williamson wrote:
> > Ultimately VFIO plumbs the result of enforce_cache_coherency() back into
> > the x86 platform code through kvm_arch_register_noncoherent_dma() which
> > controls if the WBINVD instruction is available in the guest. No other
> > a
On Sat, Apr 09, 2022 at 09:30:06PM +0800, Lu Baolu wrote:
> The dmar_insert_one_dev_info() returns the pass-in domain on success and
> NULL on failure. This doesn't make much sense. Change it to an integer.
Looks sensibel. Why not also merge it with domain_add_dev_info while
you're at it?
___
On 4/11/22 07:20, zhangfei@foxmail.com wrote:
>> Is there nothing before this call trace? Usually there will be at least
>> some warning text.
> I added dump_stack() in ioasid_free.
Hold on a sec, though...
What's the *problem* here? Did something break or are you just saying
that something
On 2022/4/11 下午10:10, Dave Hansen wrote:
On 4/11/22 07:00, Zhangfei Gao wrote:
with this patchset, each time after sbin/nginx, ioasid is freed
immediately. lynx test will alloc the same ioasid=1.
That doesn't seem right. Isn't 'sbin/nginx' still running when lynx
runs? How can they get the
On 2022/4/11 下午10:36, Dave Hansen wrote:
On 4/11/22 07:20, zhangfei@foxmail.com wrote:
Is there nothing before this call trace? Usually there will be at least
some warning text.
I added dump_stack() in ioasid_free.
Hold on a sec, though...
What's the *problem* here? Did something brea
On 4/11/22 07:44, zhangfei@foxmail.com wrote:
> On 2022/4/11 下午10:36, Dave Hansen wrote:
>> On 4/11/22 07:20, zhangfei@foxmail.com wrote:
Is there nothing before this call trace? Usually there will be at least
some warning text.
>>> I added dump_stack() in ioasid_free.
>> Hold o
On 2022/4/11 下午10:52, Dave Hansen wrote:
On 4/11/22 07:44, zhangfei@foxmail.com wrote:
On 2022/4/11 下午10:36, Dave Hansen wrote:
On 4/11/22 07:20, zhangfei@foxmail.com wrote:
Is there nothing before this call trace? Usually there will be at least
some warning text.
I added dump_stac
While the comment was correct that this flag was intended to convey the
block no-snoop support in the IOMMU, it has become widely implemented and
used to mean the IOMMU supports IOMMU_CACHE as a map flag. Only the Intel
driver was different.
Now that the Intel driver is using enforce_cache_coheren
IOMMU_CACHE means "normal DMA to this iommu_domain's IOVA should be cache
coherent" and is used by the DMA API. The definition allows for special
non-coherent DMA to exist - ie processing of the no-snoop flag in PCIe
TLPs - so long as this behavior is opt-in by the device driver.
The flag is mainl
PCIe defines a 'no-snoop' bit in each the TLP which is usually implemented
by a platform as bypassing elements in the DMA coherent CPU cache
hierarchy. A driver can command a device to set this bit on some of its
transactions as a micro-optimization.
However, the driver is now responsible to synch
This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY and
IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
Currently only Intel and AMD IOMMUs are known to support this
feature. They both implement it as an IOPTE bit, that when set, will cause
PCIe TLPs to that IOVA wi
IOMMU_CACHE means that normal DMAs do not require any additional coherency
mechanism and is the basic uAPI that VFIO exposes to userspace. For
instance VFIO applications like DPDK will not work if additional coherency
operations are required.
Therefore check IOMMU_CAP_CACHE_COHERENCY like vdpa & u
On 07/04/2022 13:58, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
Endpoint(RCiEP) device, providing the capability to dynamically monitor and
tune the PCIe traffic, and trace the TLP headers.
Add the driver for the device to enable the trace func
On 07/04/2022 13:58, Yicong Yang wrote:
From: Qi Liu
'perf record' and 'perf report --dump-raw-trace' supported in this
patch.
Example usage:
Output will contain raw PTT data and its textual representation, such
as:
0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE size: 0x40 offset: 0
ref: 0xa5d
On Wed, Apr 06, 2022 at 10:27:00AM +0100, Brian Starkey wrote:
> Hi Robin,
>
> On Tue, Apr 05, 2022 at 03:11:18PM +0100, Robin Murphy wrote:
> > iommu_get_domain_for_dev() is already perfectly happy to return NULL
> > if the given device has no IOMMU. Drop the unnecessary check.
> >
> > Signed-of
Even though the IOVA API never actually needed it, iova.h is still
carrying an include of dma-mapping.h, now solely for the sake of not
breaking tegra-drm. Fix that properly.
Signed-off-by: Robin Murphy
---
v2: Apparently nvdec.c needs one now too.
drivers/gpu/drm/tegra/dc.c| 1 +
drivers/
> From: Robin Murphy
> Sent: Friday, April 8, 2022 6:12 PM
>
> On 2022-04-08 10:08, Tian, Kevin wrote:
> >> From: Jason Gunthorpe
> >> Sent: Friday, April 8, 2022 3:08 AM
> >> On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> >>> On 2022-04-07 18:43, Jason Gunthorpe wrote:
> O
> From: Robin Murphy
> Sent: Saturday, April 9, 2022 1:45 AM
>
> >
> > So, I suppose VFIO would want to attach/detatch on every vfio_device
> > individually and it would iterate over the group instead of doing a
> > list_first_entry() like above. This would not be hard to do in VFIO.
>
> It feel
> From: Lu Baolu
> Sent: Sunday, April 10, 2022 6:25 PM
>
> Some features require that a single device must be immutably isolated,
> even when hot plug is supported.
This reads confusing, as hotplug cannot be allowed in a singleton group.
What you actually meant suppose to be:
"Enabling certai
Hi Kevin,
Thanks for your time.
On 2022/4/12 11:15, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, April 10, 2022 6:25 PM
Some features require that a single device must be immutably isolated,
even when hot plug is supported.
This reads confusing, as hotplug cannot be allowed in a singleto
On 2022/4/11 22:26, Christoph Hellwig wrote:
On Sat, Apr 09, 2022 at 09:30:06PM +0800, Lu Baolu wrote:
The dmar_insert_one_dev_info() returns the pass-in domain on success and
NULL on failure. This doesn't make much sense. Change it to an integer.
Looks sensibel. Why not also merge it with do
On Wed, Apr 06, 2022 at 08:25:32PM -0400, Konrad Rzeszutek Wilk wrote:
> > diff --git a/arch/powerpc/platforms/pseries/svm.c
> > b/arch/powerpc/platforms/pseries/svm.c
> > index c5228f4969eb2..3b4045d508ec8 100644
> > --- a/arch/powerpc/platforms/pseries/svm.c
> > +++ b/arch/powerpc/platforms/pser
Hi Baolu,
On 2022/4/12 13:08, Lu Baolu wrote:
Hi Kevin,
Thanks for your time.
On 2022/4/12 11:15, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, April 10, 2022 6:25 PM
Some features require that a single device must be immutably isolated,
even when hot plug is supported.
This reads confu
> From: Lu Baolu
> Sent: Sunday, April 10, 2022 6:25 PM
>
> Use below data structures for SVA implementation in the IOMMU core:
>
> - struct iommu_sva_ioas
> Represent the I/O address space shared with an application CPU address
> space. This structure has a 1:1 relationship with an mm_struc
> From: Lu Baolu
> Sent: Sunday, April 10, 2022 6:25 PM
>
> Use below data structures for SVA implementation in the IOMMU core:
>
> - struct iommu_sva_ioas
> Represent the I/O address space shared with an application CPU address
> space. This structure has a 1:1 relationship with an mm_struc
52 matches
Mail list logo
