From: Thierry Reding <thierry.reding@gmail.com> To: Dmitry Osipenko <digetx@gmail.com> Cc: "Rob Herring" <robh+dt@kernel.org>, "Jonathan Hunter" <jonathanh@nvidia.com>, "Ulf Hansson" <ulf.hansson@linaro.org>, "Viresh Kumar" <vireshk@kernel.org>, "Stephen Boyd" <sboyd@kernel.org>, "Peter De Schrijver" <pdeschrijver@nvidia.com>, "Mikko Perttunen" <mperttunen@nvidia.com>, "Peter Chen" <peter.chen@kernel.org>, "Mark Brown" <broonie@kernel.org>, "Lee Jones" <lee.jones@linaro.org>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Richard Weinberger" <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Lucas Stach" <dev@lynxeye.de>, "Stefan Agner" <stefan@agner.ch>, "Adrian Hunter" <adrian.hunter@intel.com>, "Mauro Carvalho Chehab" <mchehab@kernel.org>, "Michael Turquette" <mturquette@baylibre.com>, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node Date: Thu, 19 Aug 2021 18:31:20 +0200 [thread overview] Message-ID: <YR6HWMuYcF6NIepi@orome.fritz.box> (raw) In-Reply-To: <a5b942cb-1611-9ae1-6e89-4b68fdaf03e3@gmail.com> [-- Attachment #1: Type: text/plain, Size: 3850 bytes --] On Wed, Aug 18, 2021 at 07:57:04PM +0300, Dmitry Osipenko wrote: > 18.08.2021 19:39, Thierry Reding пишет: > >> We don't have a platform device for CaR. I don't see how it's going to > >> work. We need to create a platform device for each RPM-capable clock > >> because that's how RPM works. The compatible string is required for > >> instantiating OF-devices from a node, otherwise we will have to > >> re-invent the OF core. > > I think we do have a platform device for CAR. It's just not bound > > against by the driver because these clock drivers are "special". But > > from other parts of the series you're already trying to fix that, at > > least partially. > > > > But it doesn't seem right to create a platform device for each RPM- > > capable clock. Why do they need to be devices? They aren't, so why > > pretend? Is it that some API that we want to use here requires the > > struct device? > > The "device" representation is internal to the kernel. It's okay to me > to have PLLs represented by a device, it's a distinct h/w by itself. > > CCF supports managing of clock's RPM and it requires to have clock to be > backed by a device. That's what we are using here. > > Please see > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/clk/clk.c#L109 Looking at the implementation of __clk_register() and where that device pointer typically comes from, I don't think the way this is used here is what was intended. The way I interpret the code is that a clock is registered with a parent device (i.e. its provider) and clk_pm_runtime_get() is then used internally as a way to make sure that when a clock is prepared, it's parent device is runtime resumed. This is presumably to ensure that any registers that the driver might need to access in order to prepare and enable the clock are accessible (i.e. the CAR is not powered off or in reset). So the struct device that is passed to __clk_register() (or its callers) should be that of the CAR rather than virtual struct devices created by the CAR. And it's a bit debatable whether or not PLLs represent distinct hardware. Ultimately every transistor on a chip could be considered distinct hardware. But a platform device is a device on a platform bus, which is really just another way of saying it's a hardware block that's accessible from the CPU via a memory-mapped address. A PLL (just like other clocks) is merely a resource exposed by means of access to these registers. So I don't think they should be platform devices. Even making them struct device:s seems a bit of a stretch. Is there any reason why struct clk can't be used for this? I mean, the whole purpose of that structure is to represent clocks. Why do we need to make them special? > >>> Also, I don't think the tegra- prefix is necessary here. The parent node > >>> is already identified as Tegra via the compatible string. > >>> > >>> In the case of CAR, I'd imagine something like: > >>> > >>> clocks { > >>> sclk { > >>> operating-points-v2 = <&opp_table>; > >>> power-domains = <&domain>; > >>> }; > >>> }; > >>> > >>> Now you've only got the bare minimum in here that you actually add. All > >>> the other data that you used to have is simply derived from the parent. > >> 'clocks' is already a generic keyword in DT. It's probably not okay to > >> redefine it. > > "clocks" is not a generic keyword. It's the name of a property and given > > that we're talking about the clock provider here, it doesn't need a > > clocks property of its own, so it should be fine to use that for the > > node. > > I'm curious what Rob thinks about it. Rob, does this sound okay to you? Another alternative would be to omit that level altogether and just make sclk and siblings direct children of the CAR node. Thierry [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com> To: Dmitry Osipenko <digetx@gmail.com> Cc: "Rob Herring" <robh+dt@kernel.org>, "Jonathan Hunter" <jonathanh@nvidia.com>, "Ulf Hansson" <ulf.hansson@linaro.org>, "Viresh Kumar" <vireshk@kernel.org>, "Stephen Boyd" <sboyd@kernel.org>, "Peter De Schrijver" <pdeschrijver@nvidia.com>, "Mikko Perttunen" <mperttunen@nvidia.com>, "Peter Chen" <peter.chen@kernel.org>, "Mark Brown" <broonie@kernel.org>, "Lee Jones" <lee.jones@linaro.org>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, "Nishanth Menon" <nm@ti.com>, "Vignesh Raghavendra" <vigneshr@ti.com>, "Richard Weinberger" <richard@nod.at>, "Miquel Raynal" <miquel.raynal@bootlin.com>, "Lucas Stach" <dev@lynxeye.de>, "Stefan Agner" <stefan@agner.ch>, "Adrian Hunter" <adrian.hunter@intel.com>, "Mauro Carvalho Chehab" <mchehab@kernel.org>, "Michael Turquette" <mturquette@baylibre.com>, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-pm@vger.kernel.org, linux-usb@vger.kernel.org, linux-staging@lists.linux.dev, linux-spi@vger.kernel.org, linux-pwm@vger.kernel.org, linux-mtd@lists.infradead.org, linux-mmc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org Subject: Re: [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node Date: Thu, 19 Aug 2021 18:31:20 +0200 [thread overview] Message-ID: <YR6HWMuYcF6NIepi@orome.fritz.box> (raw) In-Reply-To: <a5b942cb-1611-9ae1-6e89-4b68fdaf03e3@gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 3850 bytes --] On Wed, Aug 18, 2021 at 07:57:04PM +0300, Dmitry Osipenko wrote: > 18.08.2021 19:39, Thierry Reding пишет: > >> We don't have a platform device for CaR. I don't see how it's going to > >> work. We need to create a platform device for each RPM-capable clock > >> because that's how RPM works. The compatible string is required for > >> instantiating OF-devices from a node, otherwise we will have to > >> re-invent the OF core. > > I think we do have a platform device for CAR. It's just not bound > > against by the driver because these clock drivers are "special". But > > from other parts of the series you're already trying to fix that, at > > least partially. > > > > But it doesn't seem right to create a platform device for each RPM- > > capable clock. Why do they need to be devices? They aren't, so why > > pretend? Is it that some API that we want to use here requires the > > struct device? > > The "device" representation is internal to the kernel. It's okay to me > to have PLLs represented by a device, it's a distinct h/w by itself. > > CCF supports managing of clock's RPM and it requires to have clock to be > backed by a device. That's what we are using here. > > Please see > https://elixir.bootlin.com/linux/v5.14-rc6/source/drivers/clk/clk.c#L109 Looking at the implementation of __clk_register() and where that device pointer typically comes from, I don't think the way this is used here is what was intended. The way I interpret the code is that a clock is registered with a parent device (i.e. its provider) and clk_pm_runtime_get() is then used internally as a way to make sure that when a clock is prepared, it's parent device is runtime resumed. This is presumably to ensure that any registers that the driver might need to access in order to prepare and enable the clock are accessible (i.e. the CAR is not powered off or in reset). So the struct device that is passed to __clk_register() (or its callers) should be that of the CAR rather than virtual struct devices created by the CAR. And it's a bit debatable whether or not PLLs represent distinct hardware. Ultimately every transistor on a chip could be considered distinct hardware. But a platform device is a device on a platform bus, which is really just another way of saying it's a hardware block that's accessible from the CPU via a memory-mapped address. A PLL (just like other clocks) is merely a resource exposed by means of access to these registers. So I don't think they should be platform devices. Even making them struct device:s seems a bit of a stretch. Is there any reason why struct clk can't be used for this? I mean, the whole purpose of that structure is to represent clocks. Why do we need to make them special? > >>> Also, I don't think the tegra- prefix is necessary here. The parent node > >>> is already identified as Tegra via the compatible string. > >>> > >>> In the case of CAR, I'd imagine something like: > >>> > >>> clocks { > >>> sclk { > >>> operating-points-v2 = <&opp_table>; > >>> power-domains = <&domain>; > >>> }; > >>> }; > >>> > >>> Now you've only got the bare minimum in here that you actually add. All > >>> the other data that you used to have is simply derived from the parent. > >> 'clocks' is already a generic keyword in DT. It's probably not okay to > >> redefine it. > > "clocks" is not a generic keyword. It's the name of a property and given > > that we're talking about the clock provider here, it doesn't need a > > clocks property of its own, so it should be fine to use that for the > > node. > > I'm curious what Rob thinks about it. Rob, does this sound okay to you? Another alternative would be to omit that level altogether and just make sclk and siblings direct children of the CAR node. Thierry [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 144 bytes --] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-08-19 16:31 UTC|newest] Thread overview: 238+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-17 1:27 [PATCH v8 00/34] NVIDIA Tegra power management patches for 5.16 Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 01/34] opp: Add dev_pm_opp_sync() helper Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 7:55 ` Viresh Kumar 2021-08-17 7:55 ` Viresh Kumar 2021-08-17 15:49 ` Dmitry Osipenko 2021-08-17 15:49 ` Dmitry Osipenko 2021-08-18 3:55 ` Viresh Kumar 2021-08-18 3:55 ` Viresh Kumar 2021-08-18 4:12 ` Dmitry Osipenko 2021-08-18 4:12 ` Dmitry Osipenko 2021-08-18 4:29 ` Dmitry Osipenko 2021-08-18 4:29 ` Dmitry Osipenko 2021-08-18 4:30 ` Dmitry Osipenko 2021-08-18 4:30 ` Dmitry Osipenko 2021-08-18 4:34 ` Viresh Kumar 2021-08-18 4:34 ` Viresh Kumar 2021-08-18 4:31 ` Viresh Kumar 2021-08-18 4:31 ` Viresh Kumar 2021-08-18 4:37 ` Dmitry Osipenko 2021-08-18 4:37 ` Dmitry Osipenko 2021-08-18 4:53 ` Viresh Kumar 2021-08-18 4:53 ` Viresh Kumar 2021-08-18 5:21 ` Dmitry Osipenko 2021-08-18 5:21 ` Dmitry Osipenko 2021-08-18 5:58 ` Viresh Kumar 2021-08-18 5:58 ` Viresh Kumar 2021-08-18 6:00 ` Viresh Kumar 2021-08-18 6:00 ` Viresh Kumar 2021-08-18 6:22 ` Dmitry Osipenko 2021-08-18 6:22 ` Dmitry Osipenko 2021-08-18 6:27 ` Viresh Kumar 2021-08-18 6:27 ` Viresh Kumar 2021-08-18 8:29 ` Ulf Hansson 2021-08-18 8:29 ` Ulf Hansson 2021-08-18 9:14 ` Viresh Kumar 2021-08-18 9:14 ` Viresh Kumar 2021-08-18 9:41 ` Ulf Hansson 2021-08-18 9:41 ` Ulf Hansson 2021-08-18 9:42 ` Ulf Hansson 2021-08-18 9:42 ` Ulf Hansson 2021-08-18 9:50 ` Viresh Kumar 2021-08-18 9:50 ` Viresh Kumar 2021-08-18 10:08 ` Ulf Hansson 2021-08-18 10:08 ` Ulf Hansson 2021-08-18 15:43 ` Dmitry Osipenko 2021-08-18 15:43 ` Dmitry Osipenko 2021-08-18 15:46 ` Dmitry Osipenko 2021-08-18 15:46 ` Dmitry Osipenko 2021-08-19 13:07 ` Ulf Hansson 2021-08-19 13:07 ` Ulf Hansson 2021-08-19 19:35 ` Dmitry Osipenko 2021-08-19 19:35 ` Dmitry Osipenko 2021-08-20 5:07 ` Viresh Kumar 2021-08-20 5:07 ` Viresh Kumar 2021-08-20 12:42 ` Ulf Hansson 2021-08-20 12:42 ` Ulf Hansson 2021-08-21 17:34 ` Dmitry Osipenko 2021-08-21 17:34 ` Dmitry Osipenko 2021-08-23 10:46 ` Ulf Hansson 2021-08-23 10:46 ` Ulf Hansson 2021-08-23 15:54 ` Dmitry Osipenko 2021-08-23 15:54 ` Dmitry Osipenko 2021-08-18 15:55 ` Dmitry Osipenko 2021-08-18 15:55 ` Dmitry Osipenko 2021-08-19 6:16 ` Viresh Kumar 2021-08-19 6:16 ` Viresh Kumar 2021-08-19 14:55 ` Ulf Hansson 2021-08-19 14:55 ` Ulf Hansson 2021-08-20 5:18 ` Viresh Kumar 2021-08-20 5:18 ` Viresh Kumar 2021-08-20 12:57 ` Ulf Hansson 2021-08-20 12:57 ` Ulf Hansson 2021-08-23 20:24 ` Dmitry Osipenko 2021-08-23 20:24 ` Dmitry Osipenko 2021-08-24 3:04 ` Viresh Kumar 2021-08-24 3:04 ` Viresh Kumar 2021-08-22 18:35 ` Dmitry Osipenko 2021-08-22 18:35 ` Dmitry Osipenko 2021-08-25 15:41 ` Dmitry Osipenko 2021-08-25 15:41 ` Dmitry Osipenko 2021-08-26 2:54 ` Viresh Kumar 2021-08-26 2:54 ` Viresh Kumar 2021-08-26 2:55 ` Viresh Kumar 2021-08-26 2:55 ` Viresh Kumar 2021-08-17 1:27 ` [PATCH v8 02/34] soc/tegra: pmc: Disable PMC state syncing Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 03/34] soc/tegra: Don't print error message when OPPs not available Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 04/34] soc/tegra: Add devm_tegra_core_dev_init_opp_table_simple() Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 05/34] soc/tegra: Use dev_pm_opp_sync() Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 06/34] dt-bindings: clock: tegra-car: Document new tegra-clocks sub-node Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-18 1:15 ` Rob Herring 2021-08-18 1:15 ` Rob Herring 2021-08-18 1:44 ` Dmitry Osipenko 2021-08-18 1:44 ` Dmitry Osipenko 2021-08-18 13:52 ` Thierry Reding 2021-08-18 13:52 ` Thierry Reding 2021-08-18 15:04 ` Dmitry Osipenko 2021-08-18 15:04 ` Dmitry Osipenko 2021-08-18 13:59 ` Thierry Reding 2021-08-18 13:59 ` Thierry Reding 2021-08-18 15:05 ` Dmitry Osipenko 2021-08-18 15:05 ` Dmitry Osipenko 2021-08-18 16:39 ` Thierry Reding 2021-08-18 16:39 ` Thierry Reding 2021-08-18 16:57 ` Dmitry Osipenko 2021-08-18 16:57 ` Dmitry Osipenko 2021-08-18 17:16 ` Dmitry Osipenko 2021-08-18 17:16 ` Dmitry Osipenko 2021-08-19 16:31 ` Thierry Reding [this message] 2021-08-19 16:31 ` Thierry Reding 2021-08-19 22:20 ` Dmitry Osipenko 2021-08-19 22:20 ` Dmitry Osipenko 2021-08-20 2:51 ` Dmitry Osipenko 2021-08-20 2:51 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 07/34] clk: tegra: Support runtime PM and power domain Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-18 14:07 ` Thierry Reding 2021-08-18 14:07 ` Thierry Reding 2021-08-18 15:05 ` Dmitry Osipenko 2021-08-18 15:05 ` Dmitry Osipenko 2021-08-18 16:42 ` Thierry Reding 2021-08-18 16:42 ` Thierry Reding 2021-08-18 17:11 ` Dmitry Osipenko 2021-08-18 17:11 ` Dmitry Osipenko 2021-08-19 16:54 ` Thierry Reding 2021-08-19 16:54 ` Thierry Reding 2021-08-19 22:09 ` Dmitry Osipenko 2021-08-19 22:09 ` Dmitry Osipenko 2021-08-20 11:42 ` Thierry Reding 2021-08-20 11:42 ` Thierry Reding 2021-08-20 13:08 ` Ulf Hansson 2021-08-20 13:08 ` Ulf Hansson 2021-08-21 17:45 ` Dmitry Osipenko 2021-08-21 17:45 ` Dmitry Osipenko 2021-08-23 14:33 ` Thierry Reding 2021-08-23 14:33 ` Thierry Reding 2021-08-23 18:54 ` Dmitry Osipenko 2021-08-23 18:54 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 08/34] dt-bindings: host1x: Document OPP and power domain properties Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 09/34] dt-bindings: host1x: Document Memory Client resets of Host1x, GR2D and GR3D Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-18 1:16 ` Rob Herring 2021-08-18 1:16 ` Rob Herring 2021-08-18 1:37 ` Dmitry Osipenko 2021-08-18 1:37 ` Dmitry Osipenko 2021-08-18 2:04 ` Dmitry Osipenko 2021-08-18 2:04 ` Dmitry Osipenko 2021-08-18 2:07 ` Dmitry Osipenko 2021-08-18 2:07 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 10/34] gpu: host1x: Add host1x_channel_stop() Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 11/34] gpu: host1x: Add runtime PM and OPP support Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 12:04 ` Ulf Hansson 2021-08-17 12:04 ` Ulf Hansson 2021-08-17 14:02 ` Thierry Reding 2021-08-17 14:02 ` Thierry Reding 2021-08-18 8:35 ` Ulf Hansson 2021-08-18 8:35 ` Ulf Hansson 2021-08-18 17:24 ` Dmitry Osipenko 2021-08-18 17:24 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 12/34] drm/tegra: dc: Support OPP and SoC core voltage scaling Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 13/34] drm/tegra: hdmi: Add OPP support Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 14/34] drm/tegra: gr2d: Support power management Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 15/34] drm/tegra: gr3d: " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 16/34] drm/tegra: vic: Support system suspend Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 17/34] usb: chipidea: tegra: Add runtime PM and OPP support Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 18/34] bus: tegra-gmi: " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 19/34] pwm: tegra: " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-19 13:21 ` Thierry Reding 2021-08-19 13:21 ` Thierry Reding 2021-08-19 14:04 ` Ulf Hansson 2021-08-19 14:04 ` Ulf Hansson 2021-08-19 16:17 ` Thierry Reding 2021-08-19 16:17 ` Thierry Reding 2021-08-17 1:27 ` [PATCH v8 20/34] mmc: sdhci-tegra: " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-19 17:03 ` Thierry Reding 2021-08-19 17:03 ` Thierry Reding 2021-08-19 22:37 ` Dmitry Osipenko 2021-08-19 22:37 ` Dmitry Osipenko 2021-08-20 11:35 ` Thierry Reding 2021-08-20 11:35 ` Thierry Reding 2021-08-25 9:45 ` Dmitry Osipenko 2021-08-25 9:45 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 21/34] mtd: rawnand: tegra: " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 8:41 ` Miquel Raynal 2021-08-17 8:41 ` Miquel Raynal 2021-08-17 1:27 ` [PATCH v8 22/34] spi: tegra20-slink: Add " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 12:22 ` Mark Brown 2021-08-17 12:22 ` Mark Brown 2021-08-17 15:53 ` Dmitry Osipenko 2021-08-17 15:53 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 23/34] media: dt: bindings: tegra-vde: Convert to schema Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-18 1:17 ` Rob Herring 2021-08-18 1:17 ` Rob Herring 2021-08-17 1:27 ` [PATCH v8 24/34] media: dt: bindings: tegra-vde: Document OPP and power domain Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-18 1:17 ` Rob Herring 2021-08-18 1:17 ` Rob Herring 2021-08-17 1:27 ` [PATCH v8 25/34] media: staging: tegra-vde: Support generic power domain and OPP Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 26/34] soc/tegra: fuse: Add OPP support Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 27/34] soc/tegra: fuse: Reset hardware Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 28/34] soc/tegra: regulators: Prepare for suspend Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 29/34] soc/tegra: pmc: Enable core domain support for Tegra20 and Tegra30 Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 30/34] ARM: tegra: Add OPP tables and power domains to Tegra20 device-trees Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 31/34] ARM: tegra: Add OPP tables and power domains to Tegra30 device-trees Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 32/34] ARM: tegra: Add Memory Client resets to Tegra20 GR2D, GR3D and Host1x Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 33/34] ARM: tegra: Add Memory Client resets to Tegra30 " Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko 2021-08-17 1:27 ` [PATCH v8 34/34] ARM: tegra20/30: Disable unused host1x hardware Dmitry Osipenko 2021-08-17 1:27 ` Dmitry Osipenko
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=YR6HWMuYcF6NIepi@orome.fritz.box \ --to=thierry.reding@gmail.com \ --cc=adrian.hunter@intel.com \ --cc=broonie@kernel.org \ --cc=dev@lynxeye.de \ --cc=devicetree@vger.kernel.org \ --cc=digetx@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jonathanh@nvidia.com \ --cc=lee.jones@linaro.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-pwm@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=linux-staging@lists.linux.dev \ --cc=linux-tegra@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mchehab@kernel.org \ --cc=miquel.raynal@bootlin.com \ --cc=mperttunen@nvidia.com \ --cc=mturquette@baylibre.com \ --cc=nm@ti.com \ --cc=pdeschrijver@nvidia.com \ --cc=peter.chen@kernel.org \ --cc=richard@nod.at \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=stefan@agner.ch \ --cc=u.kleine-koenig@pengutronix.de \ --cc=ulf.hansson@linaro.org \ --cc=vigneshr@ti.com \ --cc=vireshk@kernel.org \ /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: linkBe 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.