From: Tony Lindgren <tony@atomide.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: "Maxime Ripard" <maxime@cerno.tech>,
"Philipp Rossak" <embed3d@gmail.com>,
"Jonathan Bakker" <xc-racer2@live.ca>,
"David Airlie" <airlied@linux.ie>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Benoît Cousson" <bcousson@baylibre.com>,
"Paul Cercueil" <paul@crapouillou.net>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Paul Burton" <paulburton@kernel.org>,
"James Hogan" <jhogan@kernel.org>,
"Kukjin Kim" <kgene@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Chen-Yu Tsai" <wens@csie.org>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-omap <linux-omap@vger.kernel.org>,
"OpenPVRSGX Linux Driver Group" <openpvrsgx-devgroup@letux.org>,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
kernel@pyra-handheld.com, linux-mips@vger.kernel.org,
arm-soc <linux-arm-kernel@lists.infradead.org>,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Date: Tue, 21 Apr 2020 10:39:38 -0700 [thread overview]
Message-ID: <20200421173938.GZ37466@atomide.com> (raw)
In-Reply-To: <D9D4D057-A73D-485F-898D-5C05E89C16B7@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [200421 17:31]:
> > Am 21.04.2020 um 16:15 schrieb Tony Lindgren <tony@atomide.com>:
> > Note that on omaps there are actually SoC module specific registers.
>
> Ah, I see. This is of course a difference that the TI glue logic has
> its own registers in the same address range as the sgx and this can't
> be easily handled by a common sgx driver.
>
> This indeed seems to be unique with omap.
>
> > And there can be multiple devices within a single target module on
> > omaps. So the extra dts node and device is justified there.
> >
> > For other SoCs, the SGX clocks are probably best handled directly
> > in pvr-drv.c PM runtime functions unless a custom hardware wrapper
> > with SoC specific registers exists.
>
> That is why we need to evaluate what the better strategy is.
>
> So we have
> a) omap which has a custom wrapper around the sgx
> b) others without, i.e. an empty (or pass-through) wrapper
>
> Which one do we make the "standard" and which one the "exception"?
> What are good reasons for either one?
The wrapper is already handled by the ti-sysc binding, the sgx
binding should be standard with optional clocks.
See for example the standard 8250 uart for am335x with:
$ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
The 8250 device configuration is described in the standard 8250
dts binding, and the am335x module in the ti-sysc binding.
The are separate devices :)
So for the sgx binding, you can just leave out TI specific
module wrapper completely from the example.
> It also allows to handle different number of clocks (A31 seems to
> need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings
> or making big lists of conditionals. This variance would be handled
> outside the sgx core bindings and driver.
Well if other SoCs implement genpd domains etc, that's then
again part of a separate binding and not part of the sgx binding.
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
"David Airlie" <airlied@linux.ie>,
"James Hogan" <jhogan@kernel.org>,
"Jonathan Bakker" <xc-racer2@live.ca>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
linux-mips@vger.kernel.org,
"Paul Cercueil" <paul@crapouillou.net>,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
"Paul Burton" <paulburton@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
linux-samsung-soc@vger.kernel.org, "Chen-Yu Tsai" <wens@csie.org>,
"Kukjin Kim" <kgene@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, "Daniel Vetter" <daniel@ffwll.ch>,
"Rob Herring" <robh+dt@kernel.org>,
"Maxime Ripard" <maxime@cerno.tech>,
linux-omap <linux-omap@vger.kernel.org>,
arm-soc <linux-arm-kernel@lists.infradead.org>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Philipp Rossak" <embed3d@gmail.com>,
"OpenPVRSGX Linux Driver Group" <openpvrsgx-devgroup@letux.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Benoît Cousson" <bcousson@baylibre.com>,
kernel@pyra-handheld.com
Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Date: Tue, 21 Apr 2020 10:39:38 -0700 [thread overview]
Message-ID: <20200421173938.GZ37466@atomide.com> (raw)
In-Reply-To: <D9D4D057-A73D-485F-898D-5C05E89C16B7@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [200421 17:31]:
> > Am 21.04.2020 um 16:15 schrieb Tony Lindgren <tony@atomide.com>:
> > Note that on omaps there are actually SoC module specific registers.
>
> Ah, I see. This is of course a difference that the TI glue logic has
> its own registers in the same address range as the sgx and this can't
> be easily handled by a common sgx driver.
>
> This indeed seems to be unique with omap.
>
> > And there can be multiple devices within a single target module on
> > omaps. So the extra dts node and device is justified there.
> >
> > For other SoCs, the SGX clocks are probably best handled directly
> > in pvr-drv.c PM runtime functions unless a custom hardware wrapper
> > with SoC specific registers exists.
>
> That is why we need to evaluate what the better strategy is.
>
> So we have
> a) omap which has a custom wrapper around the sgx
> b) others without, i.e. an empty (or pass-through) wrapper
>
> Which one do we make the "standard" and which one the "exception"?
> What are good reasons for either one?
The wrapper is already handled by the ti-sysc binding, the sgx
binding should be standard with optional clocks.
See for example the standard 8250 uart for am335x with:
$ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
The 8250 device configuration is described in the standard 8250
dts binding, and the am335x module in the ti-sysc binding.
The are separate devices :)
So for the sgx binding, you can just leave out TI specific
module wrapper completely from the example.
> It also allows to handle different number of clocks (A31 seems to
> need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings
> or making big lists of conditionals. This variance would be handled
> outside the sgx core bindings and driver.
Well if other SoCs implement genpd domains etc, that's then
again part of a separate binding and not part of the sgx binding.
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Tony Lindgren <tony@atomide.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
"David Airlie" <airlied@linux.ie>,
"James Hogan" <jhogan@kernel.org>,
"Jonathan Bakker" <xc-racer2@live.ca>,
"open list:DRM PANEL DRIVERS" <dri-devel@lists.freedesktop.org>,
linux-mips@vger.kernel.org,
"Paul Cercueil" <paul@crapouillou.net>,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
"Paul Burton" <paulburton@kernel.org>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
linux-samsung-soc@vger.kernel.org, "Chen-Yu Tsai" <wens@csie.org>,
"Kukjin Kim" <kgene@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, "Rob Herring" <robh+dt@kernel.org>,
"Maxime Ripard" <maxime@cerno.tech>,
linux-omap <linux-omap@vger.kernel.org>,
arm-soc <linux-arm-kernel@lists.infradead.org>,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
"Philipp Rossak" <embed3d@gmail.com>,
"OpenPVRSGX Linux Driver Group" <openpvrsgx-devgroup@letux.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Benoît Cousson" <bcousson@baylibre.com>,
kernel@pyra-handheld.com
Subject: Re: [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more)
Date: Tue, 21 Apr 2020 10:39:38 -0700 [thread overview]
Message-ID: <20200421173938.GZ37466@atomide.com> (raw)
In-Reply-To: <D9D4D057-A73D-485F-898D-5C05E89C16B7@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [200421 17:31]:
> > Am 21.04.2020 um 16:15 schrieb Tony Lindgren <tony@atomide.com>:
> > Note that on omaps there are actually SoC module specific registers.
>
> Ah, I see. This is of course a difference that the TI glue logic has
> its own registers in the same address range as the sgx and this can't
> be easily handled by a common sgx driver.
>
> This indeed seems to be unique with omap.
>
> > And there can be multiple devices within a single target module on
> > omaps. So the extra dts node and device is justified there.
> >
> > For other SoCs, the SGX clocks are probably best handled directly
> > in pvr-drv.c PM runtime functions unless a custom hardware wrapper
> > with SoC specific registers exists.
>
> That is why we need to evaluate what the better strategy is.
>
> So we have
> a) omap which has a custom wrapper around the sgx
> b) others without, i.e. an empty (or pass-through) wrapper
>
> Which one do we make the "standard" and which one the "exception"?
> What are good reasons for either one?
The wrapper is already handled by the ti-sysc binding, the sgx
binding should be standard with optional clocks.
See for example the standard 8250 uart for am335x with:
$ git grep -B20 -A10 uart0 arch/arm/boot/dts/am33xx-l4.dtsi
The 8250 device configuration is described in the standard 8250
dts binding, and the am335x module in the ti-sysc binding.
The are separate devices :)
So for the sgx binding, you can just leave out TI specific
module wrapper completely from the example.
> It also allows to handle different number of clocks (A31 seems to
> need 4, Samsung, A83 and JZ4780 one) without changing the sgx bindings
> or making big lists of conditionals. This variance would be handled
> outside the sgx core bindings and driver.
Well if other SoCs implement genpd domains etc, that's then
again part of a separate binding and not part of the sgx binding.
Regards,
Tony
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-04-21 17:39 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 8:35 [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more) H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 01/12] dt-bindings: add img,pvrsgx.yaml for Imagination GPUs H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 10:12 ` [PATCH v6 01/12] dt-bindings: add img,pvrsgx.yaml " Maxime Ripard
2020-04-15 10:12 ` Maxime Ripard
2020-04-15 10:12 ` Maxime Ripard
2020-04-15 12:43 ` H. Nikolaus Schaller
2020-04-15 12:43 ` [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml " H. Nikolaus Schaller
2020-04-15 12:43 ` H. Nikolaus Schaller
2020-04-15 12:54 ` Neil Armstrong
2020-04-15 12:54 ` Neil Armstrong
2020-04-15 12:54 ` Neil Armstrong
2020-04-15 13:17 ` H. Nikolaus Schaller
2020-04-15 13:17 ` H. Nikolaus Schaller
2020-04-15 13:17 ` H. Nikolaus Schaller
2020-04-15 14:21 ` Maxime Ripard
2020-04-15 14:21 ` Maxime Ripard
2020-04-15 14:21 ` Maxime Ripard
2020-04-15 15:09 ` H. Nikolaus Schaller
2020-04-15 15:09 ` H. Nikolaus Schaller
2020-04-15 15:09 ` H. Nikolaus Schaller
2020-04-15 16:21 ` Maxime Ripard
2020-04-15 16:21 ` Maxime Ripard
2020-04-15 16:21 ` Maxime Ripard
2020-04-15 16:42 ` H. Nikolaus Schaller
2020-04-15 16:42 ` H. Nikolaus Schaller
2020-04-15 16:42 ` H. Nikolaus Schaller
2020-04-15 17:13 ` Tony Lindgren
2020-04-15 17:13 ` Tony Lindgren
2020-04-15 17:13 ` Tony Lindgren
2020-04-17 10:25 ` Maxime Ripard
2020-04-17 10:25 ` Maxime Ripard
2020-04-17 10:25 ` Maxime Ripard
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-18 23:02 ` Philipp Rossak
2020-04-18 23:02 ` Philipp Rossak
2020-04-18 23:02 ` Philipp Rossak
2020-04-20 8:04 ` Maxime Ripard
2020-04-20 8:04 ` Maxime Ripard
2020-04-20 8:04 ` Maxime Ripard
2020-04-16 20:41 ` [PATCH v6 01/12] dt-bindings: add img,pvrsgx.yaml " Rob Herring
2020-04-16 20:41 ` Rob Herring
2020-04-16 20:41 ` Rob Herring
2020-04-17 12:16 ` [PATCH v6 01/12] dt-bindings: add img, pvrsgx.yaml " H. Nikolaus Schaller
2020-04-17 12:16 ` H. Nikolaus Schaller
2020-04-21 19:02 ` Rob Herring
2020-04-21 19:02 ` Rob Herring
2020-04-21 19:02 ` Rob Herring
2020-04-15 8:35 ` [PATCH v6 02/12] ARM: DTS: am33xx: add sgx gpu child node H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 03/12] ARM: DTS: am3517: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 04/12] ARM: DTS: omap34xx: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 05/12] ARM: DTS: omap36xx: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 06/12] ARM: DTS: omap4: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 07/12] ARM: DTS: omap5: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 11:38 ` Krzysztof Kozlowski
2020-04-15 11:38 ` Krzysztof Kozlowski
2020-04-15 11:38 ` Krzysztof Kozlowski
2020-04-15 11:46 ` H. Nikolaus Schaller
2020-04-15 11:46 ` H. Nikolaus Schaller
2020-04-15 11:46 ` H. Nikolaus Schaller
2020-04-15 13:47 ` Krzysztof Kozlowski
2020-04-15 13:47 ` Krzysztof Kozlowski
2020-04-15 13:47 ` Krzysztof Kozlowski
2020-04-15 14:07 ` H. Nikolaus Schaller
2020-04-15 14:07 ` H. Nikolaus Schaller
2020-04-15 14:07 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 08/12] arm: dts: s5pv210: Add G3D node H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 9:15 ` Sergei Shtylyov
2020-04-15 9:15 ` Sergei Shtylyov
2020-04-15 9:15 ` Sergei Shtylyov
2020-04-15 9:26 ` H. Nikolaus Schaller
2020-04-15 9:26 ` H. Nikolaus Schaller
2020-04-15 9:26 ` H. Nikolaus Schaller
2020-04-15 11:49 ` Krzysztof Kozlowski
2020-04-15 11:49 ` Krzysztof Kozlowski
2020-04-15 11:49 ` Krzysztof Kozlowski
2020-04-15 12:50 ` H. Nikolaus Schaller
2020-04-15 12:50 ` H. Nikolaus Schaller
2020-04-15 12:50 ` H. Nikolaus Schaller
2020-04-15 13:44 ` Krzysztof Kozlowski
2020-04-15 13:44 ` Krzysztof Kozlowski
2020-04-15 13:44 ` Krzysztof Kozlowski
2020-04-15 18:17 ` Jonathan Bakker
2020-04-15 18:17 ` Jonathan Bakker
2020-04-15 18:17 ` Jonathan Bakker
2020-04-16 8:50 ` Krzysztof Kozlowski
2020-04-16 8:50 ` Krzysztof Kozlowski
2020-04-16 8:50 ` Krzysztof Kozlowski
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-17 12:15 ` H. Nikolaus Schaller
2020-04-22 5:56 ` kbuild test robot
2020-04-22 5:56 ` kbuild test robot
2020-04-22 5:56 ` kbuild test robot
2020-04-15 8:35 ` [PATCH v6 09/12] ARM: dts: sun6i: a31: add sgx gpu child node H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 10/12] ARM: dts: sun6i: a31s: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 11/12] ARM: dts: sun8i: a83t: " H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` [PATCH v6 12/12] MIPS: DTS: jz4780: add sgx gpu node H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 8:35 ` H. Nikolaus Schaller
2020-04-15 10:10 ` [PATCH v6 00/12] ARM/MIPS: DTS: add child nodes describing the PVRSGX GPU present in some OMAP SoC and JZ4780 (and many more) Maxime Ripard
2020-04-15 10:10 ` Maxime Ripard
2020-04-15 10:10 ` Maxime Ripard
2020-04-15 12:41 ` H. Nikolaus Schaller
2020-04-15 12:41 ` H. Nikolaus Schaller
2020-04-15 12:41 ` H. Nikolaus Schaller
2020-04-15 12:46 ` Daniel Vetter
2020-04-15 12:46 ` Daniel Vetter
2020-04-15 12:46 ` Daniel Vetter
2020-04-15 13:02 ` Maxime Ripard
2020-04-15 13:02 ` Maxime Ripard
2020-04-15 13:02 ` Maxime Ripard
2020-04-15 13:04 ` H. Nikolaus Schaller
2020-04-15 13:04 ` H. Nikolaus Schaller
2020-04-15 13:04 ` H. Nikolaus Schaller
2020-04-17 12:09 ` Philipp Rossak
2020-04-17 12:09 ` Philipp Rossak
2020-04-17 12:09 ` Philipp Rossak
2020-04-20 7:38 ` Maxime Ripard
2020-04-20 7:38 ` Maxime Ripard
2020-04-20 7:38 ` Maxime Ripard
2020-04-21 9:57 ` Philipp Rossak
2020-04-21 9:57 ` Philipp Rossak
2020-04-21 9:57 ` Philipp Rossak
2020-04-21 11:21 ` Maxime Ripard
2020-04-21 11:21 ` Maxime Ripard
2020-04-21 11:21 ` Maxime Ripard
2020-04-21 14:15 ` Tony Lindgren
2020-04-21 14:15 ` Tony Lindgren
2020-04-21 14:15 ` Tony Lindgren
2020-04-21 17:29 ` H. Nikolaus Schaller
2020-04-21 17:29 ` H. Nikolaus Schaller
2020-04-21 17:29 ` H. Nikolaus Schaller
2020-04-21 17:39 ` Tony Lindgren [this message]
2020-04-21 17:39 ` Tony Lindgren
2020-04-21 17:39 ` Tony Lindgren
2020-04-21 17:46 ` Tony Lindgren
2020-04-21 17:46 ` Tony Lindgren
2020-04-21 17:46 ` Tony Lindgren
2020-04-22 6:58 ` Maxime Ripard
2020-04-22 6:58 ` Maxime Ripard
2020-04-22 6:58 ` Maxime Ripard
2020-04-22 7:10 ` H. Nikolaus Schaller
2020-04-22 7:10 ` H. Nikolaus Schaller
2020-04-22 7:10 ` H. Nikolaus Schaller
2020-04-22 15:13 ` Maxime Ripard
2020-04-22 15:13 ` Maxime Ripard
2020-04-22 15:13 ` Maxime Ripard
2020-04-22 16:09 ` H. Nikolaus Schaller
2020-04-22 16:09 ` H. Nikolaus Schaller
2020-04-22 16:09 ` H. Nikolaus Schaller
[not found] ` <MC879Q.XY9S0U9R35681@crapouillou.net>
2020-04-22 17:23 ` H. Nikolaus Schaller
2020-04-22 19:00 ` Philipp Rossak
2020-04-22 19:33 ` Tony Lindgren
2020-04-22 21:12 ` H. Nikolaus Schaller
2020-04-23 15:00 ` Neil Armstrong
2020-04-23 15:00 ` Neil Armstrong
2020-04-23 15:00 ` Neil Armstrong
2020-04-23 15:45 ` H. Nikolaus Schaller
2020-04-23 15:45 ` H. Nikolaus Schaller
2020-04-23 15:45 ` H. Nikolaus Schaller
2020-04-23 20:36 ` Maxime Ripard
2020-04-23 20:36 ` Maxime Ripard
2020-04-23 20:36 ` Maxime Ripard
2020-04-24 9:51 ` H. Nikolaus Schaller
2020-04-24 9:51 ` H. Nikolaus Schaller
2020-04-24 9:51 ` H. Nikolaus Schaller
2020-04-21 16:42 ` Philipp Rossak
2020-04-21 16:42 ` Philipp Rossak
2020-04-21 16:42 ` Philipp Rossak
2020-04-23 20:37 ` Maxime Ripard
2020-04-23 20:37 ` Maxime Ripard
2020-04-23 20:37 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200421173938.GZ37466@atomide.com \
--to=tony@atomide.com \
--cc=airlied@linux.ie \
--cc=bcousson@baylibre.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=embed3d@gmail.com \
--cc=hns@goldelico.com \
--cc=jhogan@kernel.org \
--cc=kernel@pyra-handheld.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=letux-kernel@openphoenux.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maxime@cerno.tech \
--cc=openpvrsgx-devgroup@letux.org \
--cc=paul@crapouillou.net \
--cc=paulburton@kernel.org \
--cc=ralf@linux-mips.org \
--cc=robh+dt@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=wens@csie.org \
--cc=xc-racer2@live.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.