Re: [PATCH v4 3/3] iommu/tegra-smmu: Add PCI support

2020-10-05 Thread Nicolin Chen
On Mon, Oct 05, 2020 at 12:04:19PM +0200, Thierry Reding wrote: > > +err_bus_set: __maybe_unused; > > + bus_set_iommu(_bus_type, NULL); > > +err_unregister: > > + iommu_device_unregister(>iommu); > > +err_sysfs: > > + iommu_device_sysfs_remove(>iommu); > > Can you please switch to label

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Nicolin Chen
On Mon, Oct 05, 2020 at 11:57:54AM +0200, Thierry Reding wrote: > On Fri, Oct 02, 2020 at 11:58:29AM -0700, Nicolin Chen wrote: > > On Fri, Oct 02, 2020 at 06:02:18PM +0300, Dmitry Osipenko wrote: > > > 02.10.2020 09:08, Nicolin Chen пишет: > > > > static int tegra_smmu_of_xlate(struct device

Re: [PATCH v5 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Nicolin Chen
On Mon, Oct 05, 2020 at 12:56:38PM +0200, Thierry Reding wrote: > On Mon, Oct 05, 2020 at 11:41:08AM +0300, Dmitry Osipenko wrote: > > 05.10.2020 00:57, Nicolin Chen пишет: > > > On Sat, Oct 03, 2020 at 05:06:42PM +0300, Dmitry Osipenko wrote: > > >> 03.10.2020 09:59, Nicolin Chen пишет: > > >>>

Re: clean up the DMA mapping headers

2020-10-05 Thread Christoph Hellwig
I've pulled this into the dma-mapping for-next tree now. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 01/24] dt-bindings: iommu: mediatek: Convert IOMMU to DT schema

2020-10-05 Thread Yong Wu
On Fri, 2020-10-02 at 13:07 +0200, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 03:06:24PM +0800, Yong Wu wrote: > > Convert MediaTek IOMMU to DT schema. > > > > Signed-off-by: Yong Wu > > --- > > .../bindings/iommu/mediatek,iommu.txt | 103 > >

Re: [PATCH v3 06/24] dt-bindings: mediatek: Add binding for mt8192 IOMMU

2020-10-05 Thread Yong Wu
Hi Krzysztof, On Fri, 2020-10-02 at 13:10 +0200, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 03:06:29PM +0800, Yong Wu wrote: > > This patch adds decriptions for mt8192 IOMMU and SMI. > > > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation > > table format. The

Re: [PATCH v3 02/24] dt-bindings: memory: mediatek: Convert SMI to DT schema

2020-10-05 Thread Yong Wu
On Fri, 2020-10-02 at 13:08 +0200, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 03:06:25PM +0800, Yong Wu wrote: > > Convert MediaTek SMI to DT schema. > > > > Signed-off-by: Yong Wu > > --- > > .../mediatek,smi-common.txt | 49 - > >

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Thierry Reding
On Fri, Oct 02, 2020 at 04:55:34AM +0300, Dmitry Osipenko wrote: > 02.10.2020 04:07, Nicolin Chen пишет: > > On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote: > > If we can't come to an agreement on globalizing mc pointer, would > > it be possible to pass tegra_mc_driver

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Thierry Reding
On Thu, Oct 01, 2020 at 11:33:38PM +0300, Dmitry Osipenko wrote: > 01.10.2020 14:04, Nicolin Chen пишет: > > On Thu, Oct 01, 2020 at 12:23:16PM +0200, Thierry Reding wrote: > > > > >> It looks to me like the only reason why you need this new > > global API is > >> because PCI devices

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-10-05 Thread Boris Brezillon
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 to a

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-10-05 Thread Steven Price
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 to a

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Thierry Reding
On Mon, Oct 05, 2020 at 12:38:20PM +0300, Dmitry Osipenko wrote: > 05.10.2020 12:16, Thierry Reding пишет: > ... > >> I think you meant regmap in regards to protecting IO accesses, but this > >> is not what regmap is about if IO accesses are atomic by nature. > > > > Then why is there

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Dmitry Osipenko
05.10.2020 12:53, Thierry Reding пишет: > On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote: >> 02.10.2020 17:22, Dmitry Osipenko пишет: static int tegra_smmu_of_xlate(struct device *dev, struct of_phandle_args *args) { + struct

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-10-05 Thread Boris Brezillon
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 that Panfrost knows > > how to

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Dmitry Osipenko
05.10.2020 10:13, Thierry Reding пишет: ... > Have you also seen that sun50i-iommu does look up the SMMU from a > phandle using of_find_device_by_node()? So I think you've shown yourself > that even "modern" drivers avoid global pointers and look up via > phandle. I have no problem with the

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Thierry Reding
On Thu, Oct 01, 2020 at 10:04:30PM +0300, Dmitry Osipenko wrote: > ... > >> There are dozens variants of the panels and system could easily have > >> more than one panel, hence a direct lookup by phandle is a natural > >> choice for the panels. > > > > Not really, there's typically only just one

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Fri, Oct 02, 2020 at 05:22:41PM +0300, Dmitry Osipenko wrote: > 02.10.2020 09:08, Nicolin Chen пишет: > > static int tegra_smmu_of_xlate(struct device *dev, > >struct of_phandle_args *args) > > { > > + struct platform_device *iommu_pdev =

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote: > 02.10.2020 17:22, Dmitry Osipenko пишет: > >> static int tegra_smmu_of_xlate(struct device *dev, > >> struct of_phandle_args *args) > >> { > >> + struct platform_device *iommu_pdev =

Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API

2020-10-05 Thread Christoph Hellwig
On Fri, Oct 02, 2020 at 05:50:40PM +, Tomasz Figa wrote: > Hi Christoph, > > On Wed, Sep 30, 2020 at 06:09:17PM +0200, Christoph Hellwig wrote: > > Add a new API that returns a virtually non-contigous array of pages > > and dma address. This API is only implemented for dma-iommu and will > >

Re: [PATCH 3/3] arm64: dts: meson: Describe G12b GPU as coherent

2020-10-05 Thread Steven Price
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

Re: [PATCH v5 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Dmitry Osipenko
05.10.2020 00:57, Nicolin Chen пишет: > On Sat, Oct 03, 2020 at 05:06:42PM +0300, Dmitry Osipenko wrote: >> 03.10.2020 09:59, Nicolin Chen пишет: >>> static int tegra_smmu_of_xlate(struct device *dev, >>>struct of_phandle_args *args) >>> { >>> + struct

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Thierry Reding
On Mon, Oct 05, 2020 at 11:14:27AM +0300, Dmitry Osipenko wrote: > 05.10.2020 10:13, Thierry Reding пишет: > ... > > Have you also seen that sun50i-iommu does look up the SMMU from a > > phandle using of_find_device_by_node()? So I think you've shown yourself > > that even "modern" drivers avoid

Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev

2020-10-05 Thread Dmitry Osipenko
05.10.2020 12:16, Thierry Reding пишет: ... >> I think you meant regmap in regards to protecting IO accesses, but this >> is not what regmap is about if IO accesses are atomic by nature. > > Then why is there regmap-mmio? To protect programming sequences for example, actually that's the only

Re: [PATCH v4 3/3] iommu/tegra-smmu: Add PCI support

2020-10-05 Thread Thierry Reding
On Thu, Oct 01, 2020 at 11:08:07PM -0700, Nicolin Chen wrote: > This patch simply adds support for PCI devices. > > Signed-off-by: Nicolin Chen > --- > > Changelog > v3->v4 > * Dropped !iommu_present() check > * Added CONFIG_PCI check in the exit path > v2->v3 > * Replaced ternary

Re: [RFC 0/3] iommu: Reserved regions for IOVAs beyond dma_mask and iommu aperture

2020-10-05 Thread Lorenzo Pieralisi
[+Christoph] On Tue, Sep 29, 2020 at 12:18:49PM -0600, Alex Williamson wrote: > On Tue, 29 Sep 2020 09:18:22 +0200 > Auger Eric wrote: > > > Hi all, > > > > [also correcting some outdated email addresses + adding Lorenzo in cc] > > > > On 9/29/20 12:42 AM, Alex Williamson wrote: > > > On Mon,

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Fri, Oct 02, 2020 at 12:53:28PM -0700, Nicolin Chen wrote: > On Fri, Oct 02, 2020 at 05:58:29PM +0300, Dmitry Osipenko wrote: > > 02.10.2020 17:22, Dmitry Osipenko пишет: > > > 02.10.2020 09:08, Nicolin Chen пишет: > > >> -static void tegra_smmu_release_device(struct device *dev) > > >> -{ > >

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Fri, Oct 02, 2020 at 11:58:29AM -0700, Nicolin Chen wrote: > On Fri, Oct 02, 2020 at 06:02:18PM +0300, Dmitry Osipenko wrote: > > 02.10.2020 09:08, Nicolin Chen пишет: > > > static int tegra_smmu_of_xlate(struct device *dev, > > > struct of_phandle_args *args) > > > {

Re: [PATCH v3 14/14] iommu/amd: Adopt IO page table framework

2020-10-05 Thread Jonathan Cameron
On Sun, 4 Oct 2020 01:45:49 + Suravee Suthikulpanit wrote: > Switch to using IO page table framework for AMD IOMMU v1 page table. > > Signed-off-by: Suravee Suthikulpanit One minor thing inline. > --- > drivers/iommu/amd/iommu.c | 26 ++ > 1 file changed, 26

Re: [PATCH v5 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Mon, Oct 05, 2020 at 11:41:08AM +0300, Dmitry Osipenko wrote: > 05.10.2020 00:57, Nicolin Chen пишет: > > On Sat, Oct 03, 2020 at 05:06:42PM +0300, Dmitry Osipenko wrote: > >> 03.10.2020 09:59, Nicolin Chen пишет: > >>> static int tegra_smmu_of_xlate(struct device *dev, > >>>

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Dmitry Osipenko
05.10.2020 14:15, Thierry Reding пишет: > On Mon, Oct 05, 2020 at 01:36:55PM +0300, Dmitry Osipenko wrote: >> 05.10.2020 12:53, Thierry Reding пишет: >>> On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote: 02.10.2020 17:22, Dmitry Osipenko пишет: >> static int

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Mon, Oct 05, 2020 at 01:36:55PM +0300, Dmitry Osipenko wrote: > 05.10.2020 12:53, Thierry Reding пишет: > > On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote: > >> 02.10.2020 17:22, Dmitry Osipenko пишет: > static int tegra_smmu_of_xlate(struct device *dev, >

Re: [PATCH] cma: decrease CMA_ALIGNMENT lower limit to 2

2020-10-05 Thread Christoph Hellwig
Thanks, applied to dma-mapping for-next. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC 0/3] iommu: Reserved regions for IOVAs beyond dma_mask and iommu aperture

2020-10-05 Thread Christoph Hellwig
On Mon, Oct 05, 2020 at 11:44:10AM +0100, Lorenzo Pieralisi wrote: > > I see that there are both OF and ACPI hooks in pci_dma_configure() and > > both modify dev->dma_mask, which is what pci-sysfs is exposing here, > > but I'm not convinced this even does what it's intended to do. The > > driver

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-10-05 Thread Thierry Reding
On Mon, Oct 05, 2020 at 04:28:53PM +0300, Dmitry Osipenko wrote: > 05.10.2020 14:15, Thierry Reding пишет: > > On Mon, Oct 05, 2020 at 01:36:55PM +0300, Dmitry Osipenko wrote: > >> 05.10.2020 12:53, Thierry Reding пишет: > >>> On Fri, Oct 02, 2020 at 05:50:08PM +0300, Dmitry Osipenko wrote: >

Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE

2020-10-05 Thread Boris Brezillon
On Tue, 22 Sep 2020 15:16:48 +0100 Robin Murphy wrote: > Midgard GPUs have ACE-Lite master interfaces which allows systems to > integrate them in an I/O-coherent manner. It seems that from the GPU's > viewpoint, the rest of the system is its outer shareable domain, and so > even when snoop

[PATCH AUTOSEL 5.8 12/12] iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb()

2020-10-05 Thread Sasha Levin
From: Lu Baolu [ Upstream commit 1a3f2fd7fc4e8f24510830e265de2ffb8e3300d2 ] Lock(>lock) without disabling irq causes lockdep warnings. [ 12.703950] [ 12.703962] WARNING: possible irq lock inversion dependency detected [ 12.703975]

[PATCH AUTOSEL 5.4 4/4] iommu/vt-d: Fix lockdep splat in iommu_flush_dev_iotlb()

2020-10-05 Thread Sasha Levin
From: Lu Baolu [ Upstream commit 1a3f2fd7fc4e8f24510830e265de2ffb8e3300d2 ] Lock(>lock) without disabling irq causes lockdep warnings. [ 12.703950] [ 12.703962] WARNING: possible irq lock inversion dependency detected [ 12.703975]

Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE

2020-10-05 Thread Steven Price
On 05/10/2020 15:50, Boris Brezillon wrote: On Tue, 22 Sep 2020 15:16:48 +0100 Robin Murphy wrote: Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer

[PATCH 0/13] Fix per-domain IRQ affinity, allow >255 CPUs on x86 without IRQ remapping

2020-10-05 Thread David Woodhouse
Linux currently refuses to use >255 CPUs on x86 unless it has interrupt remapping. This is a bit gratuitous because it could use those extra CPUs just fine; it just can't target external interrupts at them. The only problem is that our generic IRQ domain code cann't cope with the concept of

[PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-05 Thread David Woodhouse
From: David Woodhouse When interrupt remapping isn't enabled, only the first 255 CPUs can receive external interrupts. Set the appropriate max affinity for the IOAPIC and MSI IRQ domains accordingly. This also fixes the case where interrupt remapping is enabled but some devices are not within

[PATCH 06/13] genirq: Add default_affinity argument to __irq_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse It already takes an array of affinities for each individual irq being allocated but that's awkward to allocate and populate in the case where they're all the same and inherited from the irqdomain, so pass the default in separately as a simple cpumask. Signed-off-by: David

[PATCH 03/13] x86/ioapic: Handle Extended Destination ID field in RTE

2020-10-05 Thread David Woodhouse
From: David Woodhouse The IOAPIC Redirection Table Entries contain an 8-bit Extended Destination ID field which maps to bits 11-4 of the MSI address. The lowest bit is used to indicate remappable format, when interrupt remapping is in use. A hypervisor can use the other 7 bits to permit guests

[PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit

2020-10-05 Thread David Woodhouse
From: David Woodhouse The Intel IOMMU has an MSI-like configuration for its interrupt, but it isn't really MSI. So it gets to abuse the high 32 bits of the address, and puts the high 24 bits of the extended APIC ID there. This isn't something that can be used in the general case for real MSIs,

[PATCH 09/13] x86/irq: Add x86_non_ir_cpumask

2020-10-05 Thread David Woodhouse
From: David Woodhouse This is the mask of CPUs to which IRQs can be delivered without interrupt remapping. Signed-off-by: David Woodhouse --- arch/x86/include/asm/mpspec.h | 1 + arch/x86/kernel/apic/apic.c| 12 arch/x86/kernel/apic/io_apic.c | 2 ++ 3 files changed, 15

[PATCH 01/13] x86/apic: Use x2apic in guest kernels even with unusable CPUs.

2020-10-05 Thread David Woodhouse
From: David Woodhouse If the BIOS has enabled x2apic mode, then leave it enabled and don't fall back to xapic just because some CPUs can't be targeted. Previously, if there are CPUs with APIC IDs > 255, the kernel will disable x2apic and fall back to xapic. And then not use the additional CPUs

[PATCH 11/13] x86/smp: Allow more than 255 CPUs even without interrupt remapping

2020-10-05 Thread David Woodhouse
From: David Woodhouse Now that external interrupt affinity can be limited to the range of CPUs that can be reached through legacy IOAPIC RTEs and MSI, it is possible to use additional CPUs. Signed-off-by: David Woodhouse --- arch/x86/kernel/apic/apic.c | 2 -- 1 file changed, 2 deletions(-)

[PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse This is the maximum possible set of CPUs which can be used. Use it to calculate the default affinity requested from __irq_alloc_descs() by first attempting to find the intersection with irq_default_affinity, or falling back to using just the max_affinity if the intersection

[PATCH 08/13] genirq: Add irq_domain_set_affinity()

2020-10-05 Thread David Woodhouse
From: David Woodhouse This allows a maximal affinity to be set, for IRQ domains which cannot target all CPUs in the system. Signed-off-by: David Woodhouse --- include/linux/irqdomain.h | 4 kernel/irq/irqdomain.c| 28 ++-- kernel/irq/manage.c | 19

[PATCH 04/13] x86/apic: Support 15 bits of APIC ID in IOAPIC/MSI where available

2020-10-05 Thread David Woodhouse
From: David Woodhouse Some hypervisors can allow the guest to use the Extended Destination ID field in the IOAPIC RTE and MSI address to address up to 32768 CPUs. Signed-off-by: David Woodhouse --- arch/x86/include/asm/mpspec.h | 1 + arch/x86/include/asm/x86_init.h | 2 ++

[PATCH 12/13] iommu/irq_remapping: Kill most of hyperv-iommu.c now it's redundant

2020-10-05 Thread David Woodhouse
From: David Woodhouse It took me a while to realise that this "IRQ remapping" driver exists not to actually remap interrupts, but to return -EINVAL if anyone ever tries to set the affinity to a set of CPUs which can't be reached *without* remapping. Having fixed the core IRQ domain code to

[PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-05 Thread David Woodhouse
From: David Woodhouse This allows the host to indicate that IOAPIC and MSI emulation supports 15-bit destination IDs, allowing up to 32Ki CPUs without remapping. Signed-off-by: David Woodhouse --- Documentation/virt/kvm/cpuid.rst | 4 arch/x86/include/uapi/asm/kvm_para.h | 1 +

[PATCH 05/13] genirq: Prepare for default affinity to be passed to __irq_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse Instead of plugging in irq_default_affinity at the lowest level in desc_smp_init() if the caller didn't specify an affinity for this specific IRQ in its array, allow the default affinity to be passed down from __irq_alloc_descs() instead. This is in preparation for irq

Re: [PATCH v2 1/3] iommu/io-pgtable-arm: Support coherency for Mali LPAE

2020-10-05 Thread Boris Brezillon
On Mon, 5 Oct 2020 16:16:32 +0100 Steven Price wrote: > On 05/10/2020 15:50, Boris Brezillon wrote: > > On Tue, 22 Sep 2020 15:16:48 +0100 > > Robin Murphy wrote: > > > >> Midgard GPUs have ACE-Lite master interfaces which allows systems to > >> integrate them in an I/O-coherent manner. It