Re: [PATCH v2 01/10] memory: tegra: Implement SID override programming

2021-04-26 Thread Thierry Reding
On Mon, Apr 26, 2021 at 10:28:43AM +0200, Krzysztof Kozlowski wrote: > On 20/04/2021 19:26, Thierry Reding wrote: > > From: Thierry Reding > > > > Instead of programming all SID overrides during early boot, perform the > > operation on-demand after the SMMU tr

Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook

2021-04-26 Thread Thierry Reding
On Sat, Apr 24, 2021 at 11:27:10PM +0300, Dmitry Osipenko wrote: > 23.04.2021 18:23, Dmitry Osipenko пишет: > > 23.04.2021 18:01, Guillaume Tucker пишет: > >> On 02/04/2021 15:40, Dmitry Osipenko wrote: > >>> 01.04.2021 11:55, Nicolin Chen пишет: > On Mon, Mar 29, 2021 at 02:32:56AM +0300,

[PATCH v2 5/5] iommu/tegra-smmu: Support managed domains

2021-04-23 Thread Thierry Reding
From: Navneet Kumar Allow creating identity and DMA API compatible IOMMU domains. When creating a DMA API compatible domain, make sure to also create the required cookie. Signed-off-by: Navneet Kumar Signed-off-by: Thierry Reding --- drivers/iommu/tegra-smmu.c | 47

[PATCH v2 4/5] iommu/tegra-smmu: Add support for reserved regions

2021-04-23 Thread Thierry Reding
From: Thierry Reding The Tegra DRM driver currently uses the IOMMU API explicitly. This means that it has fine-grained control over when exactly the translation through the IOMMU is enabled. This currently happens after the driver probes, so the driver is in a DMA quiesced state when the IOMMU

[PATCH v2 3/5] iommu: dma: Use of_iommu_get_resv_regions()

2021-04-23 Thread Thierry Reding
From: Thierry Reding For device tree nodes, use the standard of_iommu_get_resv_regions() implementation to obtain the reserved memory regions associated with a device. Cc: Rob Herring Cc: Frank Rowand Cc: devicet...@vger.kernel.org Signed-off-by: Thierry Reding --- drivers/iommu/dma-iommu.c

[PATCH v2 2/5] iommu: Implement of_iommu_get_resv_regions()

2021-04-23 Thread Thierry Reding
From: Thierry Reding This is an implementation that IOMMU drivers can use to obtain reserved memory regions from a device tree node. It uses the reserved-memory DT bindings to find the regions associated with a given device. If these regions are marked accordingly, identity mappings

[PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier

2021-04-23 Thread Thierry Reding
From: Thierry Reding Reserved memory region phandle references can be accompanied by a specifier that provides additional information about how that specific reference should be treated. One use-case is to mark a memory region as needing an identity mapping in the system's IOMMU for the device

[PATCH v2 0/5] iommu: Support identity mappings of reserved-memory regions

2021-04-23 Thread Thierry Reding
From: Thierry Reding Hi, this is an updated proposal to solve the problem of passing memory regions that are actively being accessed during boot. The particular use-case that I need this for is when the bootloader has set up the display controller to scan out a boot splash screen. During boot

[PATCH v2 09/10] arm64: tegra: Enable SMMU support on Tegra194

2021-04-20 Thread Thierry Reding
From: Thierry Reding Add the device tree node for the dual-SMMU found on Tegra194 and hook up peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC. Signed-off-by: Thierry Reding --- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86 1 file changed, 86 insertions

[PATCH v2 10/10] arm64: tegra: Enable SMMU support for display on Tegra194

2021-04-20 Thread Thierry Reding
From: Thierry Reding The display controllers are attached to a separate ARM SMMU instance that is dedicated to servicing isochronous memory clients. Add this ISO instance of the ARM SMMU to device tree and attach all four display controllers to it. Signed-off-by: Thierry Reding --- arch/arm64

[PATCH v2 08/10] arm64: tegra: Hook up memory controller to SMMU on Tegra186

2021-04-20 Thread Thierry Reding
From: Thierry Reding On Tegra186 and later, the memory controller needs to be programmed in coordination with any of the ARM SMMU instances to configure the stream ID used for each memory client. To support this, add a phandle reference to the memory controller to the SMMU device tree node

[PATCH v2 07/10] arm64: tegra: Use correct compatible string for Tegra186 SMMU

2021-04-20 Thread Thierry Reding
From: Thierry Reding The SMMU found on Tegra186 requires interoperation with the memory controller in order to program stream ID overrides. The generic ARM SMMU 500 compatible is therefore inaccurate. Replace it with a more correct, SoC-specific compatible string. Signed-off-by: Thierry Reding

[PATCH v2 06/10] iommu/arm-smmu: Use Tegra implementation on Tegra186

2021-04-20 Thread Thierry Reding
From: Thierry Reding Tegra186 requires the same SID override programming as Tegra194 in order to seamlessly transition from the firmware framebuffer to the Linux framebuffer, so the Tegra implementation needs to be used on Tegra186 devices as well. Signed-off-by: Thierry Reding --- drivers

[PATCH v2 05/10] iommu/arm-smmu: tegra: Implement SID override programming

2021-04-20 Thread Thierry Reding
From: Thierry Reding The secure firmware keeps some SID override registers set as passthrough in order to allow devices such as the display controller to operate with no knowledge of SMMU translations until an operating system driver takes over. This is needed in order to seamlessly transition

[PATCH v2 04/10] iommu/arm-smmu: tegra: Detect number of instances at runtime

2021-04-20 Thread Thierry Reding
From: Thierry Reding Parse the reg property in device tree and detect the number of instances represented by a device tree node. This is subsequently needed in order to support single-instance SMMUs with the Tegra implementation because additional programming is needed to properly configure

[PATCH v2 03/10] iommu/arm-smmu: Implement ->probe_finalize()

2021-04-20 Thread Thierry Reding
From: Thierry Reding Implement a ->probe_finalize() callback that can be used by vendor implementations to perform extra programming necessary after devices have been attached to the SMMU. Signed-off-by: Thierry Reding --- Changes in v2: -remove unnecessarily paranoid check --- drivers/io

[PATCH v2 02/10] dt-bindings: arm-smmu: Add Tegra186 compatible string

2021-04-20 Thread Thierry Reding
From: Thierry Reding The ARM SMMU instantiations found on Tegra186 and later need inter- operation with the memory controller in order to correctly program stream ID overrides. Furthermore, on Tegra194 multiple instances of the SMMU can gang up to achieve higher throughput. In order to do

[PATCH v2 01/10] memory: tegra: Implement SID override programming

2021-04-20 Thread Thierry Reding
From: Thierry Reding Instead of programming all SID overrides during early boot, perform the operation on-demand after the SMMU translations have been set up for a device. This reuses data from device tree to match memory clients for a device and programs the SID specified in device tree, which

[PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults

2021-04-20 Thread Thierry Reding
From: Thierry Reding Hi, this is a set of patches that is the result of earlier discussions regarding early identity mappings that are needed to avoid SMMU faults during early boot. The goal here is to avoid early identity mappings altogether and instead postpone the need for the identity

Re: [PATCH v1 1/2] iommu/tegra-smmu: Defer attachment of display clients

2021-04-08 Thread Thierry Reding
On Thu, Apr 08, 2021 at 02:42:42AM -0700, Nicolin Chen wrote: > On Mon, Mar 29, 2021 at 02:32:55AM +0300, Dmitry Osipenko wrote: > > All consumer-grade Android and Chromebook devices show a splash screen > > on boot and then display is left enabled when kernel is booted. This > > behaviour is

Re: [PATCH v1 1/2] iommu/tegra-smmu: Defer attachment of display clients

2021-04-08 Thread Thierry Reding
On Mon, Mar 29, 2021 at 02:32:55AM +0300, Dmitry Osipenko wrote: > All consumer-grade Android and Chromebook devices show a splash screen > on boot and then display is left enabled when kernel is booted. This > behaviour is unacceptable in a case of implicit IOMMU domains to which > devices are

Re: [PATCH 0/9] arm64: tegra: Prevent early SMMU faults

2021-03-26 Thread Thierry Reding
On Fri, Mar 26, 2021 at 06:29:28PM +0300, Dmitry Osipenko wrote: > 25.03.2021 16:03, Thierry Reding пишет: > > From: Thierry Reding > > > > Hi, > > > > this is a set of patches that is the result of earlier discussions > > regarding early identity mappin

Re: [PATCH 1/9] memory: tegra: Move internal data structures into separate header

2021-03-25 Thread Thierry Reding
On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote: > 25.03.2021 16:03, Thierry Reding пишет: > > From: Thierry Reding > > > > From Tegra20 through Tegra210, either the GART or SMMU drivers need > > access to the internals of the memory controller driver b

Re: [PATCH 3/9] memory: tegra: Implement SID override programming

2021-03-25 Thread Thierry Reding
On Thu, Mar 25, 2021 at 02:27:10PM +, Robin Murphy wrote: > On 2021-03-25 13:03, Thierry Reding wrote: > > From: Thierry Reding > > > > Instead of programming all SID overrides during early boot, perform the > > operation on-demand after the SMMU tr

[PATCH 6/9] iommu/arm-smmu: tegra: Implement SID override programming

2021-03-25 Thread Thierry Reding
From: Thierry Reding The secure firmware keeps some SID override registers set as passthrough in order to allow devices such as the display controller to operate with no knowledge of SMMU translations until an operating system driver takes over. This is needed in order to seamlessly transition

[PATCH 5/9] iommu/arm-smmu: tegra: Detect number of instances at runtime

2021-03-25 Thread Thierry Reding
From: Thierry Reding Parse the reg property in device tree and detect the number of instances represented by a device tree node. This is subsequently needed in order to support single-instance SMMUs with the Tegra implementation because additional programming is needed to properly configure

[PATCH 4/9] iommu/arm-smmu: Implement ->probe_finalize()

2021-03-25 Thread Thierry Reding
From: Thierry Reding Implement a ->probe_finalize() callback that can be used by vendor implementations to perform extra programming necessary after devices have been attached to the SMMU. Signed-off-by: Thierry Reding --- drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 + driv

[PATCH 2/9] memory: tegra: Add memory client IDs to tables

2021-03-25 Thread Thierry Reding
From: Thierry Reding The memory client IDs will subsequently be used to program override SIDs for the given clients depending on the device tree configuration. Signed-off-by: Thierry Reding --- drivers/memory/tegra/tegra186.c | 206 1 file changed, 206

[PATCH 3/9] memory: tegra: Implement SID override programming

2021-03-25 Thread Thierry Reding
From: Thierry Reding Instead of programming all SID overrides during early boot, perform the operation on-demand after the SMMU translations have been set up for a device. This reuses data from device tree to match memory clients for a device and programs the SID specified in device tree, which

[PATCH 9/9] arm64: tegra: Enable SMMU support on Tegra194

2021-03-25 Thread Thierry Reding
From: Thierry Reding Add the device tree node for the dual-SMMU found on Tegra194 and hook up peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC. Signed-off-by: Thierry Reding --- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86 1 file changed, 86 insertions

[PATCH 8/9] arm64: tegra: Hook up memory controller to SMMU on Tegra186

2021-03-25 Thread Thierry Reding
From: Thierry Reding On Tegra186 and later, the memory controller needs to be programmed in coordination with any of the ARM SMMU instances to configure the stream ID used for each memory client. To support this, add a phandle reference to the memory controller to the SMMU device tree node

[PATCH 7/9] iommu/arm-smmu: Use Tegra implementation on Tegra186

2021-03-25 Thread Thierry Reding
From: Thierry Reding Tegra186 requires the same SID override programming as Tegra194 in order to seamlessly transition from the firmware framebuffer to the Linux framebuffer, so the Tegra implementation needs to be used on Tegra186 devices as well. Signed-off-by: Thierry Reding --- drivers

[PATCH 1/9] memory: tegra: Move internal data structures into separate header

2021-03-25 Thread Thierry Reding
From: Thierry Reding >From Tegra20 through Tegra210, either the GART or SMMU drivers need access to the internals of the memory controller driver because they are tightly coupled (in fact, the GART and SMMU are part of the memory controller). On later chips, a separate hardware block impleme

[PATCH 0/9] arm64: tegra: Prevent early SMMU faults

2021-03-25 Thread Thierry Reding
From: Thierry Reding Hi, this is a set of patches that is the result of earlier discussions regarding early identity mappings that are needed to avoid SMMU faults during early boot. The goal here is to avoid early identity mappings altogether and instead postpone the need for the identity

Re: [PATCH v5] iommu/tegra-smmu: Add pagetable mappings to debugfs

2021-03-16 Thread Thierry Reding
On Mon, Mar 15, 2021 at 01:36:31PM -0700, Nicolin Chen wrote: > This patch dumps all active mapping entries from pagetable > to a debugfs directory named "mappings". > > Attaching an example: > > SWGROUP: hc > ASID: 0 > reg: 0x250 > PTB_ASID: 0xe0080004 > as->pd_dma: 0x80004000 > { >

Re: [PATCH] iommu/tegra-smmu: Fix mc errors on tegra124-nyan

2021-03-03 Thread Thierry Reding
mmu_probe_device()") > Reported-by: Guillaume Tucker > Signed-off-by: Nicolin Chen > --- > > Guillaume, would you please give a "Tested-by" to this change? Thanks! > > drivers/iommu/tegra-smmu.c | 72 +- > 1 file change

Re: next/master bisection: baseline.login on r8a77960-ulcb

2021-02-25 Thread Thierry Reding
On Thu, Feb 25, 2021 at 11:14:57AM +, Robin Murphy wrote: > On 2021-02-25 11:09, Thierry Reding wrote: > > On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote: > > > Hi Christoph and all, > > > > > > On 23.02.21 10:56, Guillaum

Re: next/master bisection: baseline.login on r8a77960-ulcb

2021-02-25 Thread Thierry Reding
On Wed, Feb 24, 2021 at 10:39:42PM +0100, Heiko Thiery wrote: > Hi Christoph and all, > > On 23.02.21 10:56, Guillaume Tucker wrote: > > Hi Christoph, > > > > Please see the bisection report below about a boot failure on > > r8a77960-ulcb on next-20210222. > > > > Reports aren't automatically

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-12-18 Thread Thierry Reding
On Fri, Dec 18, 2020 at 04:15:45PM -0600, Rob Herring wrote: > On Thu, Dec 17, 2020 at 9:00 AM Thierry Reding > wrote: > > > > On Tue, Nov 10, 2020 at 08:33:09PM +0100, Thierry Reding wrote: > > > On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote: > &g

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-12-17 Thread Thierry Reding
On Tue, Nov 10, 2020 at 08:33:09PM +0100, Thierry Reding wrote: > On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote: > > On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote: > > > On 2020-11-05 16:43, Thierry Reding wrote: > > > > On Thu, Se

Re: [PATCH RESEND 5/5] iommu/tegra-smmu: Add PCI support

2020-11-20 Thread Thierry Reding
+-- > 1 file changed, 25 insertions(+), 10 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH RESEND 4/5] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

2020-11-20 Thread Thierry Reding
1 > tegra-vic 5434.vic: Adding to iommu group 2 > nouveau 5700.gpu: Adding to iommu group 3 > > Note that dmesg log above is testing with IOMMU_DOMAIN_UNMANAGED. > > Reviewed-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko > Signed-off-by: Nicolin Chen > ---

Re: [PATCH RESEND 3/5] iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev

2020-11-20 Thread Thierry Reding
olin Chen > --- > drivers/iommu/tegra-smmu.c | 56 -- > 1 file changed, 23 insertions(+), 33 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ iommu mailing list iommu@lists

[PATCH] Revert "firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module"

2020-11-19 Thread Thierry Reding
From: Thierry Reding Commit d0511b5496c0 ("firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module") causes the ARM SMMU driver to be built as a loadable module when using the Aarch64 default configuration. This in turn causes problems because if the loada

Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-11-17 Thread Thierry Reding
On Mon, Nov 16, 2020 at 11:48:39AM -0800, John Stultz wrote: > On Mon, Nov 16, 2020 at 8:36 AM Will Deacon wrote: > > On Mon, Nov 16, 2020 at 04:59:36PM +0100, Thierry Reding wrote: > > > On Fri, Nov 06, 2020 at 04:27:10AM +, John Stultz wrote: > > > Unfortu

Re: [PATCH v6 3/3] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

2020-11-16 Thread Thierry Reding
On Fri, Nov 06, 2020 at 04:27:10AM +, John Stultz wrote: > Allow the qcom_scm driver to be loadable as a permenent module. > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > ensure that drivers that call into the qcom_scm driver are > also built as modules. While not ideal in

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-10 Thread Thierry Reding
On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote: > On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote: > > On 2020-11-05 16:43, Thierry Reding wrote: > > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote: > > > > On Tue, Se

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-06 Thread Thierry Reding
On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote: > On 2020-11-05 16:43, Thierry Reding wrote: > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote: > > > On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote: > > > > On Mon, Sep 14,

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-05 Thread Thierry Reding
On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote: > On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote: > > On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote: > > > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote: > >

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-05 Thread Thierry Reding
On Fri, Sep 25, 2020 at 04:21:17PM +0300, Dmitry Osipenko wrote: > 25.09.2020 15:39, Robin Murphy пишет: > ... > >> IIRC, in the past Robin Murphy was suggesting to read out hardware state > >> early during kernel boot in order to find what regions are in use by > >> hardware. > > > > I doubt I

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-05 Thread Thierry Reding
On Fri, Sep 25, 2020 at 01:39:07PM +0100, Robin Murphy wrote: > On 2020-09-24 17:23, Dmitry Osipenko wrote: > > 24.09.2020 17:01, Thierry Reding пишет: > > > On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote: > > > > 04.09.2020 15:59, Thierry Reding

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-11-05 Thread Thierry Reding
On Thu, Sep 24, 2020 at 07:23:34PM +0300, Dmitry Osipenko wrote: > 24.09.2020 17:01, Thierry Reding пишет: > > On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote: > >> 04.09.2020 15:59, Thierry Reding пишет: > >>> From: Thierry Reding > >>> &

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

2020-10-09 Thread Thierry Reding
On Thu, Oct 08, 2020 at 02:12:10PM -0700, Nicolin Chen wrote: > On Thu, Oct 08, 2020 at 11:53:43AM +0200, Thierry Reding wrote: > > On Mon, Oct 05, 2020 at 06:05:46PM -0700, Nicolin Chen wrote: > > > On Mon, Oct 05, 2020 at 11:57:54AM +0200, Thierry Reding wrote: > > > &

Re: [PATCH v4 2/2] iommu/tegra-smmu: Expand mutex protection range

2020-10-08 Thread Thierry Reding
gt;v4: > * Fixed typo "Expend" => "Expand" > v2->v3: > * Renamed label "err_unlock" to "unlock" > v1->v2: > * N/A > > drivers/iommu/tegra-smmu.c | 34 +++++- > 1 file changed,

Re: [PATCH v4 1/2] iommu/tegra-smmu: Unwrap tegra_smmu_group_get

2020-10-08 Thread Thierry Reding
; > Changelog > v2->v4: > * N/A > v1->v2: > * Changed type of swgroup to "unsigned int", following Thierry's >commnets. > > drivers/iommu/tegra-smmu.c | 19 --- > 1 file changed, 4 insertions(+), 15 deletions(-) Acked-by: Thierry Reding

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

2020-10-08 Thread Thierry Reding
On Mon, Oct 05, 2020 at 06:05:46PM -0700, Nicolin Chen wrote: > 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: > > >

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:08P

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

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 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. > > >

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: [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 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 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 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 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 eve

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 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 > > g

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

2020-10-01 Thread Thierry Reding
On Wed, Sep 30, 2020 at 01:36:18PM -0700, Nicolin Chen wrote: > On Wed, Sep 30, 2020 at 05:31:31PM +0200, Thierry Reding wrote: > > On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote: > > > Previously the driver relies on bus_set_iommu() in .probe() to call >

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

2020-10-01 Thread Thierry Reding
On Thu, Oct 01, 2020 at 03:33:19AM -0700, Nicolin Chen wrote: > On Thu, Oct 01, 2020 at 11:51:52AM +0200, Thierry Reding wrote: > > > > >> ... > > > > >>>> It looks to me like the only reason why you need this new global > > > > >>&

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

2020-10-01 Thread Thierry Reding
On Wed, Sep 30, 2020 at 07:48:50PM -0700, Nicolin Chen wrote: > On Thu, Oct 01, 2020 at 05:06:19AM +0300, Dmitry Osipenko wrote: > > 01.10.2020 04:26, Nicolin Chen пишет: > > > On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote: > > >> 01.10.2020 00:32, Nicolin Chen пишет: > > >>> On

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

2020-10-01 Thread Thierry Reding
On Thu, Oct 01, 2020 at 05:06:19AM +0300, Dmitry Osipenko wrote: > 01.10.2020 04:26, Nicolin Chen пишет: > > On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote: > >> 01.10.2020 00:32, Nicolin Chen пишет: > >>> On Thu, Oct 01, 2020 at 12:24:25AM +0300, Dmitry Osipenko wrote: > ...

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

2020-10-01 Thread Thierry Reding
On Wed, Sep 30, 2020 at 06:26:30PM -0700, Nicolin Chen wrote: > On Thu, Oct 01, 2020 at 12:56:46AM +0300, Dmitry Osipenko wrote: > > 01.10.2020 00:32, Nicolin Chen пишет: > > > On Thu, Oct 01, 2020 at 12:24:25AM +0300, Dmitry Osipenko wrote: > > >> ... > > It looks to me like the only reason

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

2020-10-01 Thread Thierry Reding
On Wed, Sep 30, 2020 at 01:36:18PM -0700, Nicolin Chen wrote: > On Wed, Sep 30, 2020 at 05:31:31PM +0200, Thierry Reding wrote: > > On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote: > > > Previously the driver relies on bus_set_iommu() in .probe() to call >

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

2020-10-01 Thread Thierry Reding
On Wed, Sep 30, 2020 at 07:29:12PM +0300, Dmitry Osipenko wrote: > ... > >> Secondly, I'm already about to use the new tegra_get_memory_controller() > >> API for all the T20/30/124/210 EMC and devfreq drivers. > > > > Also, this really proves the point I was trying to make about how this > > is

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

2020-10-01 Thread Thierry Reding
On Thu, Oct 01, 2020 at 05:11:30AM +0300, Dmitry Osipenko wrote: > 30.09.2020 19:47, Thierry Reding пишет: > > On Wed, Sep 30, 2020 at 07:25:41PM +0300, Dmitry Osipenko wrote: > >> 30.09.2020 19:06, Thierry Reding пишет: > >>> On Wed, Sep 30, 2020 at 06:36:52P

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

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 07:25:41PM +0300, Dmitry Osipenko wrote: > 30.09.2020 19:06, Thierry Reding пишет: > > On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote: > >> I'... > >>>> +struct tegra_mc *mc = devm_tegra_get_memory_contro

Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 07:26:00PM +0300, Dmitry Osipenko wrote: > 30.09.2020 19:15, Thierry Reding пишет: > > On Wed, Sep 30, 2020 at 07:06:27PM +0300, Dmitry Osipenko wrote: > >> 30.09.2020 19:03, Thierry Reding пишет: > >>> On Wed, Sep 30, 2020 at 06:53:06P

Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 07:06:27PM +0300, Dmitry Osipenko wrote: > 30.09.2020 19:03, Thierry Reding пишет: > > On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote: > >> 30.09.2020 18:23, Thierry Reding пишет: > >>> On Wed, Sep 30, 2020 at 01:42:

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

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote: > I'... > >> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev); > >> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > > > It looks to me like the only reason why you need this new global API is > >

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

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 06:36:52PM +0300, Dmitry Osipenko wrote: > I'... > >> + struct tegra_mc *mc = devm_tegra_get_memory_controller(dev); > >> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev); > > > > It looks to me like the only reason why you need this new global API is > >

Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 06:53:06PM +0300, Dmitry Osipenko wrote: > 30.09.2020 18:23, Thierry Reding пишет: > > On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote: > >> From: Dmitry Osipenko > >> > >> Multiple Tegra drivers need to retrieve Memory Cont

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

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 01:42:57AM -0700, Nicolin Chen wrote: > Previously the driver relies on bus_set_iommu() in .probe() to call > in .probe_device() function so each client can poll iommus property > in DTB to configure fwspec via tegra_smmu_configure(). According to > the comments in

Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()

2020-09-30 Thread Thierry Reding
On Wed, Sep 30, 2020 at 01:42:56AM -0700, Nicolin Chen wrote: > From: Dmitry Osipenko > > Multiple Tegra drivers need to retrieve Memory Controller and hence there > is quite some duplication of the retrieval code among the drivers. Let's > add a new common helper for the retrieval of the MC. >

Re: [PATCH 4/5] iommu/tegra-smmu: Add PCI support

2020-09-28 Thread Thierry Reding
On Sat, Sep 26, 2020 at 01:07:18AM -0700, Nicolin Chen wrote: > This patch simply adds support for PCI devices. > > Signed-off-by: Nicolin Chen > --- > drivers/iommu/tegra-smmu.c | 17 - > 1 file changed, 16 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH 3/5] iommu/tegra-smmu: Use iommu_fwspec in .probe_/.attach_device()

2020-09-28 Thread Thierry Reding
On Sat, Sep 26, 2020 at 01:07:17AM -0700, Nicolin Chen wrote: > The tegra_smmu_probe_device() function searches in DT for the iommu > phandler to get "smmu" pointer. This works for most of SMMU clients > that exist in the DTB. But a PCI device will not be added to iommu, > since it doesn't have a

Re: [PATCH 3/5] iommu/tegra-smmu: Use iommu_fwspec in .probe_/.attach_device()

2020-09-28 Thread Thierry Reding
On Sat, Sep 26, 2020 at 05:48:17PM +0300, Dmitry Osipenko wrote: > 26.09.2020 11:07, Nicolin Chen пишет: > ... > > + /* NULL smmu pointer means that SMMU driver is not probed yet */ > > + if (unlikely(!smmu)) > > + return ERR_PTR(-EPROBE_DEFER); > > Hello, Nicolin! > > Please don't

Re: [PATCH 1/5] iommu/tegra-smmu: Unwrap tegra_smmu_group_get

2020-09-28 Thread Thierry Reding
On Sat, Sep 26, 2020 at 01:07:15AM -0700, Nicolin Chen wrote: > The tegra_smmu_group_get was added to group devices in different > SWGROUPs and it'd return a NULL group pointer upon a mismatch at > tegra_smmu_find_group(), so for most of clients/devices, it very > likely would mismatch and need a

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-09-24 Thread Thierry Reding
On Thu, Sep 24, 2020 at 12:41:29PM +0200, Marek Szyprowski wrote: > Hi Thierry, > > On 24.09.2020 12:16, Thierry Reding wrote: > > On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote: > >> On 24.09.2020 10:28, Joerg Roedel wrote: > >>> On Wed, Sep

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-09-24 Thread Thierry Reding
On Thu, Sep 24, 2020 at 04:23:59PM +0300, Dmitry Osipenko wrote: > 04.09.2020 15:59, Thierry Reding пишет: > > From: Thierry Reding > > > > Reserved memory regions can be marked as "active" if hardware is > > expected to access the regions during boot and bef

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-09-24 Thread Thierry Reding
On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thierry Reding wrote: > On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote: > > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Reserved memory regions c

Re: [PATCH 3/3] iommu/tegra-smmu: Allow to group clients in same swgroup

2020-09-24 Thread Thierry Reding
--- > drivers/iommu/tegra-smmu.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) Makes sense: Acked-by: Thierry Reding signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lis

Re: [PATCH 2/3] iommu/tegra-smmu: Fix iova->phys translation

2020-09-24 Thread Thierry Reding
mmu_iova_to_phys(struct > iommu_domain *domain, > > pfn = *pte & as->smmu->pfn_mask; > > - return SMMU_PFN_PHYS(pfn); > + return SMMU_PFN_PHYS(pfn) + SMMU_OFFSET_IN_PAGE(iova); > } > > static struct tegra_smmu *tegra_smmu_find(struct

Re: [PATCH 1/3] iommu/tegra-smmu: Do not use PAGE_SHIFT and PAGE_MASK

2020-09-24 Thread Thierry Reding
> - smmu->pfn_mask = BIT_MASK(mc->soc->num_address_bits - PAGE_SHIFT) - 1; > + smmu->pfn_mask = > + BIT_MASK(mc->soc->num_address_bits - SMMU_PTE_SHIFT) - 1; checkpatch no longer warns about lines longer than 80 characters. The new limit is 100, so

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-09-24 Thread Thierry Reding
On Thu, Sep 24, 2020 at 10:46:46AM +0200, Marek Szyprowski wrote: > Hi Joerg, > > On 24.09.2020 10:28, Joerg Roedel wrote: > > On Wed, Sep 23, 2020 at 08:48:26AM +0200, Marek Szyprowski wrote: > >> It allows to remap given buffer at the specific IOVA address, although > >> it doesn't guarantee

Re: [PATCH] iommu/tegra-smmu: Fix tlb_mask

2020-09-17 Thread Thierry Reding
ztof (Cc'ed for visibility) are aware of both patches. From the Tegra side: Acked-by: Thierry Reding > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c > index 84fdee473873..0becdbfea306 100644 > --- a/drivers/iommu/tegra-smmu.c > +++ b/drivers/iommu/tegra

Re: [PATCH v2 1/4] dt-bindings: reserved-memory: Document "active" property

2020-09-15 Thread Thierry Reding
On Mon, Sep 14, 2020 at 04:08:29PM -0600, Rob Herring wrote: > On Fri, Sep 04, 2020 at 02:59:57PM +0200, Thierry Reding wrote: > > From: Thierry Reding > > > > Reserved memory regions can be marked as "active" if hardware is > > expected to access the regions

[PATCH v2 2/4] iommu: Implement of_iommu_get_resv_regions()

2020-09-04 Thread Thierry Reding
From: Thierry Reding This is an implementation that IOMMU drivers can use to obtain reserved memory regions from a device tree node. It uses the reserved-memory DT bindings to find the regions associated with a given device. These regions will be used to create 1:1 mappings in the IOMMU domain

[RFC 4/4] iommu/tegra-smmu: Add support for reserved regions

2020-09-04 Thread Thierry Reding
From: Thierry Reding The Tegra DRM driver currently uses the IOMMU API explicitly. This means that it has fine-grained control over when exactly the translation through the IOMMU is enabled. This currently happens after the driver probes, so the driver is in a DMA quiesced state when the IOMMU

  1   2   3   4   5   6   >