[PATCH] arm64: tegra: Add the GPU on Tegra194

Thierry Reding thierry.reding at gmail.com
Thu Jul 16 09:17:53 EDT 2020


On Thu, Jul 16, 2020 at 01:59:33PM +0100, Jon Hunter wrote:
> 
> On 16/07/2020 13:01, Thierry Reding wrote:
> > From: Thierry Reding <treding at nvidia.com>
> > 
> > The GPU found on NVIDIA Tegra194 SoCs is a Volta generation GPU called
> > GV11B.
> > 
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > ---
> >  arch/arm64/boot/dts/nvidia/tegra194.dtsi | 33 ++++++++++++++++++++++++
> >  1 file changed, 33 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > index 259e40469908..f559fe983ebe 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > @@ -1395,6 +1395,39 @@ sor3: sor at 15bc0000 {
> >  				nvidia,interface = <3>;
> >  			};
> >  		};
> > +
> > +		gpu at 17000000 {
> > +			compatible = "nvidia,gv11b";
> 
> I think we also need to add the to binding doc.

I've got a patch that converts the nvidia,gk20a.txt to the json-schema
format and then a patch on top that adds this compatible string. Since
that patch is part of a larger series that's a bit stalled, I'll add
this to the existing bindings for now.

> > +			reg = <0x17000000 0x10000000>,
> > +			      <0x18000000 0x10000000>;
> > +			interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> > +				     <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> > +			interrupt-names = "stall", "nonstall";
> > +			clocks = <&bpmp TEGRA194_CLK_GPCCLK>,
> > +				 <&bpmp TEGRA194_CLK_GPU_PWR>;
> > +			clock-names = "gpu", "pwr";
> > +			resets = <&bpmp TEGRA194_RESET_GPU>;
> > +			reset-names = "gpu";
> > +			status = "disabled";
> > +
> > +			power-domains = <&bpmp TEGRA194_POWER_DOMAIN_GPU>;
> > +			interconnects = <&mc TEGRA194_MEMORY_CLIENT_NVL1R &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL1RHP &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL1W &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL2R &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL2RHP &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL2W &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL3R &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL3RHP &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL3W &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL4R &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL4RHP &emc>,
> > +					<&mc TEGRA194_MEMORY_CLIENT_NVL4W &emc>;
> > +			interconnect-names = "dma-mem", "read-0-hp", "write-0",
> > +					     "read-1", "read-1-hp", "write-1",
> > +					     "read-2", "read-2-hp", "write-2",
> > +					     "read-3", "read-3-hp", "write-3";
> > +		};
> >  	};
> 
> I also see that for gv11b we populate 'dma-coherent' and so we should
> probably add this as well.

Do we know for certain that the GPU is DMA coherent? I've only tested
this (with local patches to Nouveau) without dma-coherent, so I have not
actually verified that it works without.

I vaguely recall reading that there are different apertures for sysmem,
one for coherent sysmem and another for non-coherent sysmem. So I'm not
sure if dma-coherent here will work without additional code in the
driver to ensure that all memory is allocated from the coherent sysmem
aperture.

I'd suggest we leave this as-is for now until we're further along with
GPU support and we can properly test this. Leaving out dma-coherent
should be harmless and in the worst case unnecessarily flushes caches.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20200716/a5ca2c88/attachment.sig>


More information about the linux-arm-kernel mailing list