://git.kernel.org/will/c/4a25f2ea0e03
Thanks for applying. Sorry to be late to the party, but feel free
to add my ...
Reviewed-by: Jon Hunter
Also any chance we could tag for stable? Probably the most
appropriate fixes-tag would be ...
Fixes: aab5a1c88276 ("iommu/arm-smmu: add NVIDIA implementation fo
void (*write_sctlr)(struct arm_smmu_device *smmu, int idx, u32 reg);
void (*probe_finalize)(struct arm_smmu_device *smmu, struct device
*dev);
+ void (*cfg_pgsize_bitmap)(struct arm_smmu_device *smmu);
};
#define INVALID_SMENDX -1
Reviewed
On 14/12/2021 15:38, Robin Murphy wrote:
...
IOMMU/DT folks, any thoughts about this approach? The patches that are
of interest outside of Host1x/TegraDRM specifics are patches 1, 2, 4,
and 5.
FWIW it looks fairly innocuous to me. I don't understand host1x -
neither hardware nor driver ab
Hi all,
Still no response on this :-(
On 06/12/2021 09:55, Jon Hunter wrote:
Will, Joerg, Rob,
On 08/11/2021 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom
Will, Joerg, Rob,
On 08/11/2021 10:36, Mikko Perttunen wrote:
On 9/16/21 5:32 PM, Mikko Perttunen wrote:
Hi all,
***
New in v2:
Added support for Tegra194
Use standard iommu-map property instead of custom mechanism
***
this series adds support for Host1x 'context isolation'. Since
when progr
to transition framebuffers
used by the bootloader to the kernel.
This based upon an initial patch by Thierry Reding .
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 76
1 file changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia
chema: Documentation/devicetree/bindings/iommu/arm,smmu.yaml
DTC arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dt.yaml
CHECK arch/arm64/boot/dts/nvidia/tegra186-p3509-+p3636-0001.dt.yaml
Add the missing 'nvidia,memory-controller' property to fix the above
warni
global_fault,
> IRQF_SHARED,
> "arm-smmu global fault",
> smmu);
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index fad63efa1a72..d89
ible:
> + contains:
> +enum:
> + - nvidia,tegra194-smmu
> +then:
> + properties:
> +reg:
> + minItems: 2
> + maxItems: 2
> +
> examples:
>- |+
> /* SMMU with stream matching or str
c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1943,6 +1943,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
> { .compatible = "arm,mmu-401", .data = &arm_mmu401 },
> { .compatible = "arm,mmu-500", .data = &arm_mmu500 },
> { .compatible = &
l_init(smmu);
> + if (IS_ERR(smmu))
> + return PTR_ERR(smmu);
> +
> num_irqs = 0;
> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) {
> num_irqs++;
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
__
S 128
>
> +#define TLB_LOOP_TIMEOUT 100 /* 1s! */
> +#define TLB_SPIN_COUNT 10
>
> /* Shared driver definitions */
> enum arm_smmu_arch_version {
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
__
On 01/07/2020 20:00, Krishna Reddy wrote:
> +items:
> + - enum:
> + - nvdia,tegra194-smmu
> + - const: arm,mmu-500
>>>
Is the fallback compatible appropriate here? If software treats this as a
standard MMU-500 it will only program
On 01/07/2020 19:28, Krishna Reddy wrote:
>>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
>> Hmm, there must be a better way to word that to express that it only applies
>> to the sets of SMMUs that must be programmed identically, and not any other
>> independent MMU-
On 01/07/2020 00:57, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
> on ARM MMU-500.
>
> Signed-off-by: Krishna Reddy
> ---
> .../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/
On 01/07/2020 00:57, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
> It uses two of ARM MMU-500s together to interleave IOVA accesses
> across them and must be programmed identically.
> The third SMMU instance is used as a regular ARM MMU-500 and it
> can either be
On 30/06/2020 18:16, Krishna Reddy wrote:
>> OK, well I see what you are saying, but if we intended to support all 3 for
>> Tegra194, then we should ensure all 3 are initialised correctly.
>
> The driver intend to support up to 3 instances. It doesn't really mandate
> that all three instances
On 30/06/2020 17:32, Jon Hunter wrote:
> On 30/06/2020 17:23, Krishna Reddy wrote:
>>>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>>>> +*smmu) {
>>>> + unsigned int i;
>>
>>>> + for (i = 1; i < MAX
On 30/06/2020 17:23, Krishna Reddy wrote:
>>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>>> +*smmu) {
>>> + unsigned int i;
>
>>> + for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>>> + struct resource *res;
>>> +
>>> + res = platform_get_reso
On 30/06/2020 15:53, Robin Murphy wrote:
> On 2020-06-30 09:19, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>>> IOVA accesses across them.
>>> Add NVIDIA i
On 30/06/2020 13:13, Robin Murphy wrote:
> On 2020-06-30 09:37, Jon Hunter wrote:
>>
>> On 30/06/2020 01:10, Krishna Reddy wrote:
>>> Add global/context fault hooks to allow NVIDIA SMMU implementation
>>> handle faults across multiple SMMUs.
>>
>>
On 29/06/2020 23:49, Krishna Reddy wrote:
>>> + if (!nvidia_smmu->bases[0])
>>> + nvidia_smmu->bases[0] = smmu->base;
>>> +
>>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>
>> Not critical -- just a nit: why not put the bases[0] in init()?
>
> smmu->base
On 30/06/2020 01:10, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
>
> Signed-off-by: Krishna Reddy
> ---
>
On 30/06/2020 01:10, Krishna Reddy wrote:
> Add global/context fault hooks to allow NVIDIA SMMU implementation
> handle faults across multiple SMMUs.
Nit ... this is not just for NVIDIA, but this allows anyone to add
custom global/context and fault hooks. So I think that the changelog
should be
On 30/06/2020 01:10, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
> on ARM MMU-500.
>
> Signed-off-by: Krishna Reddy
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/Document
On 30/06/2020 01:10, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
> IOVA accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
There is no description here of the 3rd SM
On 04/06/2019 07:05, Christoph Hellwig wrote:
> On Mon, Jun 03, 2019 at 08:47:57PM +0100, Jon Hunter wrote:
>> Since next-20190529 one of our tests for MMC has started failing, where
>> the symptom is that the data written to the MMC does not match the
>> source. Bisectin
On 29/04/2019 13:56, Robin Murphy wrote:
> On 22/04/2019 18:59, Christoph Hellwig wrote:
>> There is nothing really arm64 specific in the iommu_dma_ops
>> implementation, so move it to dma-iommu.c and keep a lot of symbols
>> self-contained. Note the implementation does depend on the
>> DMA_DIRE
t it first and then find a safer solution instead.
>
> Reported-by: Tony Lindgren
> Signed-off-by: Nicolin Chen
> ---
> Tony,
>
> Would you please test and verify? Thanks!
This also fixes various memory allocation failures we have seen on
32-bit Tegra as well.
T
Hi Joerg,
On 30/08/17 16:30, Joerg Roedel wrote:
> Hi Jon,
>
> On Wed, Aug 30, 2017 at 03:22:05PM +0100, Jon Hunter wrote:
>> Yes I can confirm that this fixes the crash. I assume that you will fix
>> the error path for bus_set_iommu() above as I believe no
On 30/08/17 16:30, Joerg Roedel wrote:
> Hi Jon,
>
> On Wed, Aug 30, 2017 at 03:22:05PM +0100, Jon Hunter wrote:
>> Yes I can confirm that this fixes the crash. I assume that you will fix
>> the error path for bus_set_iommu() above as I believe now it needs to
>> cal
Hi Joerg,
On 30/08/17 13:09, Joerg Roedel wrote:
> Hi Jon,
>
> On Wed, Aug 30, 2017 at 12:04:38PM +0100, Jon Hunter wrote:
>> With next-20170829 I am seeing several Tegra boards crashing [0][1] on
>> boot in tegra_smmu_probe() and the bisect is point to this commit. Looks
On 09/08/17 23:29, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Add a struct iommu_device to each tegra-smmu and register it
> with the iommu-core. Also link devices added to the driver
> to their respective hardware iommus.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/tegra-smmu.c |
33 matches
Mail list logo
